Re: Tie UDP reply to incoming interface
- From: David Schwartz <davids@xxxxxxxxxxxxx>
- Date: Wed, 16 Sep 2009 05:46:47 -0700 (PDT)
On Sep 16, 4:23 am, pk <p...@xxxxxxxxxx> wrote:
It's not clear that you are fully aware, because you seem to be
confusing the ARP issue (which only occurs with two interfaces in the
same subnet) with the end system model issue issue here (which has
nothing to do with ARP).
Of course. Where did I say otherwise? My claim was that an upstream router
will never ARP for the IP address assigned to the ethernet interface that
connects to the other provider.
Right, but that has nothing to do with the issue. This issue has
nothing to do with ARP.
ISP A ROUTER ISP B ROUTER
| |
| /
\ /
eth1 eth2
linux firewall/router
What I was saying is that eth1 will never get an ARP request for eth2's IP
address, and viceversa. Of course when ISP A router has a packet for some
destination behind the linux firewall, it will arp for eth1's IP address,
and so will ISP B router for eth2, which is what you said.
Right, so even though each ISP will only ARP for the IP address facing
it, it does not follow that eth1 will never receive a packet whose
destination is assigned to eth2. The reason that will never happen is
that the ISP routers simply don't know enough to do that.
Consider:
ISP A core <-> ISP A access <-> eth1 <-> you <-> eth2 <-> ISP B access
<-> ISP B core
Suppose, ISP B buys ISP A and suddenly these two routers start talking
to each other. The ISP A core router may learn that its ISP A access
router is the best route to your eth2 address. In that case, the ISP A
access router will receive packets with the destination of your eth2
address and they will arrive on eth1.
Of course, this is very unlikely to happen. But nothing about your
topology compels it -- it's just that the two routers don't exchange
information on that level. If isn't your setup that compels it, but
your ISP's.
In this case, however, you do need to deal with the fact that your
ISPs are probably going to drop packets with the other ISP's source
address thinking it's spoofed even though it's not. In that case, you
need to filter packets based on the *origin* *IP* *address*.
Note that doing it based on the receive interface won't work --
because there's no way to unambiguously map an outbound packet to the
inbound packet that "caused" it.
It can be done with commands like:
/sbin/ip route add table 4 default via <ISP_B_default_route_IP>
/sbin/ip rule add fwmark 4 table 4
And in the 'mangle' table:
-A OUTPUT -s <ISP_B_IP> ! -d <local_IPs> -j MARK --set-mark 4
You can eliminate the '! -d <local_IPs>' if you add routes for local
IPs to the extra table.
DS
.
- Follow-Ups:
- References:
- Tie UDP reply to incoming interface
- From: pk
- Re: Tie UDP reply to incoming interface
- From: David Schwartz
- Re: Tie UDP reply to incoming interface
- From: pk
- Re: Tie UDP reply to incoming interface
- From: Rick Jones
- Re: Tie UDP reply to incoming interface
- From: pk
- Re: Tie UDP reply to incoming interface
- From: David Schwartz
- Re: Tie UDP reply to incoming interface
- From: pk
- Tie UDP reply to incoming interface
- Prev by Date: Re: Tie UDP reply to incoming interface
- Next by Date: Re: Tie UDP reply to incoming interface
- Previous by thread: Re: Tie UDP reply to incoming interface
- Next by thread: Re: Tie UDP reply to incoming interface
- Index(es):
Relevant Pages
|
