Hi Jian, 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 the same.
Regards, Ken On 27 May 2010 23:46, Jian Gu <guxiaoj...@gmail.com> wrote: > Wouldn't simply configure source NAT on firewall 2.2.2.1 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 2.2.2.1 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.gilm...@gmail.com> > wrote: > > 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 > phone > > to the Juniper Devs after about 4 hours with no result. They understand > the > > problem but can't seem to think of a working solution (last solution led > to > > 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 - 1.1.1.0/24 > > ISP2 - 2.2.2.0/24 > > > > ISP1 is the default gateway, ISP2 is a backup provider but which is > always > > active. Client comes in on ISP1's link, traffic goes back out on ISP1s > link. > > 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 3.3.3.3 aimed at 2.2.2.2, packet is received by > the > > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > > TCPDump, the firewall at 2.2.2.1 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 3.3.3.3 > *orig > > 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 > was > > 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 > then > > intercept the packets if they are destined for the wrong interface and > send > > them out the right one based on a bunch of boolean. > > > > We've tried setting up a virtual instance on the offending interface and > a > > firewall filter, but this had little to no effect (at one point it > stopped > > 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 > rely > > on someone else. > > > > Thanks! > > > > Ken > > >
