On Wed, 14 Nov 2012, Stephen Clark wrote: > On 11/14/2012 03:08 AM, Jozsef Kadlecsik wrote: > > On Tue, 13 Nov 2012, Stephen Clark wrote: > > > > > On 11/13/2012 02:24 PM, Jozsef Kadlecsik wrote: > > > > On Tue, 13 Nov 2012, Stephen Clark wrote: > > > > > > > > > On 11/13/2012 10:25 AM, Jozsef Kadlecsik wrote: > > > > > > On Tue, 13 Nov 2012, Stephen Clark wrote: > > > > > > > > > > > > > A similar problem exists in the following scenario: > > > > > > > You have two upstream isp that you are doing load balancing by > > > > > > > having > > > > > > > multiple > > > > > > > default routes: > > > > > > > default > > > > > > > nexthop via 66.xxx.xxx.xxx dev eth1 weight 1 > > > > > > > nexthop via 205.xxx.xxx.xxx dev eth2 weight 1 > > > > > > > On one of the external interface you have a DNAT to > > > > > > > an internal server on a private address. The DNAT makes > > > > > > > a conntrack entry that is going to in effect do a SNAT on reponses > > > > > > > from the internal server back out to the internet, but the load > > > > > > > balancing > > > > > > > decision on routing happens before this implicit SNAT so you have > > > > > > > packets > > > > > > > trying to go out an interface where the source address does not > > > > > > > fall > > > > > > > in > > > > > > > the > > > > > > > subnet of that interface. > > > > > > In my opinion this is a broken network design. The DNAT should not > > > > > > depend > > > > > > on the external interface, problem solved. > > > > > > > > > > > Hmmm... what does this mean ^^^ ? > > > > > Say you have the follwoing: > > > > > eth1 with ips 66.xxx.xxx.1 and 66.xxx.xxx.2 > > > > > eth2 with ip 205.xxx.xxx.xxx > > > > > eth0 with ip 10.0.1.254/24 > > > > > with a server at 10.0.1.253. > > > > > > > > > > iptables -A PREROUTING -i eth1 -d 66.xxx.xxx.2 -j DNAT > > > > > --to-destination > > > > > 10.0.1.253 > > > > > > > > > > How else would you access an internal server at a private address > > > > > without using a DNAT from an external public ip? Is there some other > > > > > way > > > > > to do this that I am not aware of? > > > > Everything depends on your backup provider: does it route the network > > > > 66.xxx.xxx.xxx/y to you or not? > > > > > > > > - If the answer is no, then the rule above is correct but the internal > > > > server cannot be reached when the backup line is up. So it does not > > > > matter what's in the conntrack table, no answer is sent over the > > > > backup > > > > link to you. > > > > - If the answer is yes, then the rule should not contain the "-i eth1" > > > > part and your internal server could be reached as 66.xxx.xxx.2, > > > > independent of the uplinks. > > > There is no intent for backup of the incoming connection to 66.xxx.xxx.2 - > > > only load balancing outgoing > > > traffic. > > Then I don't understand, what is the problem. When the reply packet is > > sent out over the backup line, why should the source address fall into > > the subnet of the outgoing interface? Unless, of course if you yourself or > > your backup provider prevents it by egress filtering. > > > A lot of ISPs in the U.S. do reverse path filtering and drop packets that > could not originate from their provided subnet. > If they did not do this then of course there would be no problem. But then this traffic is not load balanced at all and the reply packets must be sent out over eth1 only. So you have to add a routing rule which forces routing over eth1. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
