On 11/14/2012 03:15 PM, Jozsef Kadlecsik wrote:
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.
You are correct and that is what we do. But it would be nice if the linux kernel was
smart enough to make sure the packet went out the correct interface without having
to add additional rules.
But I guess one could argue this gives the user more control.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
--
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
