Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 1018 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Two External Interfaces - I'm lost

danitaz
I've decided that I just really don't know what I'm doing, and I'm throwing myself on the mercy of the Astaro community.

Here's what I've done.  I have two internet connections - one DSL on eth1 and one Cable on eth2.

I can't seem to figure out the "gateway" issues for getting anything to go out the non-default interface (for now the cable).  I wanted to leave just about everything the way it was with the DSL until I figured out what I was doing and got the routing done.  I thought it was working - and indeed I managed to get HTTP and HTTPS traffic to go out the cable, but I kept having it stop on me, and in trying to investigate that I think I've just broken it!

My IP block starts at 75.151.85.9/29 with a next hop gateway for the block at 75.151.85.14.

What I have tried to do is get http and https to start going out 75.151.85.14.  It seems that I should have to define 75.151.85.14 as a host and then use this as the gateway for the policy host - so that would be like this:

Route Type: Gateway Route
Source Interface:  Any
Source Network:  Internal (Network)
Service: HTTP
Destination Network: Any
Gateway:      Comcast Gateway (75.151.85.14)

But then I have to set up a static route to 75.151.85.14 right?  When I try to do this I think that's where I'm lost.

I've tried both an interface route and a gateway route and neither seem to work.  I'm confused as to what "host" should be in the gateway route, because I would assume it would be the IP address of the NIC (75.151.85.9), but I can't select that object for the route.  Oddly enough, I DID have it working at one time, as evidenced by going to whatsmyip.org and seeing the proper IP, but it would stop working periodically, and then come back, and now I can't get it to work at all!

I realize it's got to be a really dumb mistake, but I can't find it/figure it out.

Any help greatly appreciated!

Danita


This thread was automatically locked due to age.
  • 0
    I'm having similar issues. I want to send some traffic out one interface and the rest through the default gateway. 

    I also want to let in some traffic using DNAT rules on the non default gw interface, but what happens is, the server behind the fw tries to respond and the traffic gets sent through the default gw, and so it gets lost.

    Would be nice if the Astaro knew that the traffic coming in on that interface should be sent back out that interface. There has to be a way to tell it.
  • 0 in reply to tdm4
    I'm having similar issues. I want to send some traffic out one interface and the rest through the default gateway. 

    I also want to let in some traffic using DNAT rules on the non default gw interface, but what happens is, the server behind the fw tries to respond and the traffic gets sent through the default gw, and so it gets lost.

    Would be nice if the Astaro knew that the traffic coming in on that interface should be sent back out that interface. There has to be a way to tell it.


    Add me to the list on the DNAT rules returning traffic out the wrong interface. Anyone have idea's to or suggestions?
  • 0 in reply to jaredclarke
    Bumped for attention.. hopefully?

    I would imagine it would be something to do with NAT since, the traffic has to go back out through the Astaro gateway from the internal server. Surely, it would know which interface to send it back out on?
  • 0 in reply to tdm4
    I think the DNAT rules in the nat table don't use conntrack. Only NAT/IP Masq from the internal network outbound uses conntrack. That would explain that, if you have default gw set to ppp1, if a packet comes in on ppp0 to go to the internal server, once that internal server sent the packet back out.. the Astaro GW wouldn't know that it was supposed to go out ppp0.. ppp1 is the default gw, and so it tries to send it out that way, which of course leads to the packet being lost.
  • 0 in reply to tdm4
    Something akin to this:

    http://securepoint.com/lists/html/LARTC/2007-03/msg00012.html

    Involves marking packets coming in so it knows how to route them back out.