Junos Asymmetric Routing
ken.gilmour at gmail.com
Fri May 28 15:09:58 UTC 2010
Yes sir that's what I thought too. The packets are being NATted (and I also
used a bit of DNAT for port forwarding to test the theory) but the result is
On 27 May 2010 23:46, Jian Gu <guxiaojian at gmail.com> wrote:
> Wouldn't simply configure source NAT on firewall 188.8.131.52 resolve the
> problem gracefully? when connection requests coming in through ISP2,
> source NAT the incoming traffic's source IP with IPs on firewall
> inside interface, that way when server replies, firewall 184.108.40.206 will
> guarantee to receive the ACK because ACK traffic won't follow default
> routing to ISP1.
> On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour <ken.gilmour at gmail.com>
> > Hi all,
> > I have a very peculiar situation here that i seem to have difficulty
> > explaining in such a way for people to understand. I just got off the
> > to the Juniper Devs after about 4 hours with no result. They understand
> > problem but can't seem to think of a working solution (last solution led
> > the primary firewall hard crashing and then failing over after a commit
> > (which also makes me wonder what made the primary crash and not the
> > secondary)). I am wondering if there is anyone "creative" on the list who
> > has encountered and worked around this problem before...
> > Here goes *sigh*
> > ISP1 - 220.127.116.11/24
> > ISP2 - 18.104.22.168/24
> > ISP1 is the default gateway, ISP2 is a backup provider but which is
> > active. Client comes in on ISP1's link, traffic goes back out on ISP1s
> > Client comes in on ISP2's link (non default gateway) but for some reason,
> > the packets seem to be going back out through the link for ISP1.
> > So look at it this way:
> > SYN comes from client at 22.214.171.124 aimed at 126.96.36.199, packet is received by
> > firewall. Firewall sends a SYN/ACK but the firewall at 188.8.131.52 sees it in
> > TCPDump, the firewall at 184.108.40.206 never sees it.
> > Here's a log snippet (I can send you more if you need:
> > May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 220.127.116.11
> > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3
> > You will see that the orig and out zones are the same zone, however this
> > a last ditch effort (putting both interfaces into one zone, effectively
> > creating a swamp).
> > Our current (non-preferred) solution is to put match-all rules on our
> > Catalyst 6513s and put both providers into a swamp and the switch will
> > intercept the packets if they are destined for the wrong interface and
> > them out the right one based on a bunch of boolean.
> > We've tried setting up a virtual instance on the offending interface and
> > firewall filter, but this had little to no effect (at one point it
> > passing the packets to the end machine altogether). We're using small SRX
> > 650ies. Why do we want to do it this way you ask? In the event of a BGP
> > session failure we need to be able to use our statically routed IPs and
> > on someone else.
> > Thanks!
> > Ken
More information about the NANOG