LARTC - Nov 2003 - routing for split multiple uplinks/providers with port forwarding

The fine document:

  http://lartc.org/howto/lartc.rpdb.multiple-links.html

works nicely to make sure that answers to packets incoming to the
Linux router from a particular provider go back out again over the
same provider.

It doesn''t work as given for connections that are port forwarded from
the
Linux router to machines inside the local network (e.g. to a web server).

With port forwarding in the mix, packets arriving from the Internet to a
particular port on the Linux router have DNAT applied so that they pass
transparently on to the internal web server; but, the answer packets from
the web server arrive back at the Linux router and do not necessarily
go out by the same gateway/provider by which they came in.

I suspect the fix is somehow to mark the port forwarded packets with
a flag indicating on which interface they arrived at the Linux router,
and then preserve this flag into the answer packets on the web server.
On the Linux router I can then make sure that appropriately flagged
answer packets go out the correct interface.

Am I on the right track here?

-- 
-IAN!  Ian! D. Allen   Ottawa, Ontario, Canada
       EMail: idallen@idallen.ca   WWW: http://www.idallen.com/
       College professor via: http://teaching.idallen.com/
       Board Member, TeleCommunities CANADA  http://www.tc.ca/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

The fine document:

  http://lartc.org/howto/lartc.rpdb.multiple-links.html

works nicely to make sure that answers to packets incoming to the
Linux router from a particular provider go back out again over the
same provider.

It doesn''t work as given for connections that are port forwarded from
the
Linux router to machines inside the local network (e.g. to a web server).

With port forwarding in the mix, packets arriving from the Internet to a
particular port on the Linux router have DNAT applied so that they pass
transparently on to the internal web server; but, the answer packets from
the web server arrive back at the Linux router and do not necessarily
go out by the same gateway/provider by which they came in.

I suspect the fix is somehow to mark the port forwarded packets with
a flag indicating on which interface they arrived at the Linux router,
and then preserve this flag into the answer packets on the web server.
On the Linux router I can then make sure that appropriately flagged
answer packets go out the correct interface.

Or, perhaps I could add a network alias (e.g. eth1:0) for the local
network interface on the router and somehow use ip routing to arrange that
packets arriving from each of the two Internet interfaces get assigned
to exit the router using only one of the two network card aliases, with
reply packets coming back the to the same alias and returning by the same
Internet interface by which they arrived.  Or maybe use two network cards.

Am I on the right track here?

-- 
-IAN!  Ian! D. Allen   Ottawa, Ontario, Canada
       EMail: idallen@idallen.ca   WWW: http://www.idallen.com/
       College professor via: http://teaching.idallen.com/
       Board Member, TeleCommunities CANADA  http://www.tc.ca/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Ian! D. Allen wrote:
> I suspect the fix is somehow to mark the port forwarded packets with
> a flag indicating on which interface they arrived at the Linux router,
> and then preserve this flag into the answer packets on the web server.
> On the Linux router I can then make sure that appropriately flagged
> answer packets go out the correct interface.
> Am I on the right track here?
Is the same track I went along a week or so ago and seems to work fine.
Mark them as they come in, then make the PREROUTING table direct them to the 
appropriate routing table to get back out.

regards

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear ---                           ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Ian,

 : It doesn''t work as given for connections that are port forwarded
from
 : the Linux router to machines inside the local network (e.g. to a web
 : server).

True, the multiple uplinks is for exactly that, uplinks!  Or, in other
words, outbound connectivity, only.

 : With port forwarding in the mix, packets arriving from the Internet to
 : a particular port on the Linux router have DNAT applied so that they
 : pass transparently on to the internal web server; but, the answer
 : packets from the web server arrive back at the Linux router and do not
 : necessarily go out by the same gateway/provider by which they came in.

Also true.  The conventional solution is to have an end-to-end unique
path, and perform DNAT (or NAT) based on each public/private pair. [0]
Although, you might consider using connection tracking to do the heavy
lifting for you. [1]

 : I suspect the fix is somehow to mark the port forwarded packets with a
 : flag indicating on which interface they arrived at the Linux router,
 : and then preserve this flag into the answer packets on the web server.
 : On the Linux router I can then make sure that appropriately flagged
 : answer packets go out the correct interface.

Yes, you can mark the packets....the trick is to take advantage of the
DNAT connection tracking entry in the PREROUTING table as the packet
enters the firewall from the internal network.  This allows you to mark
the packet before routing based on the original (public) destination IP
address.  Observe the use of "--ctorigdst" in this iptables command.

-Martin

 [0] 
http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-inbound
 [1]  http://mailman.ds9a.nl/pipermail/lartc/2003q2/008090.html

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/