When you set-up your virtual-instance, was your ISP2 interface a member of that instance? I have a working setup that ran on a J-series running 9.6 something.
This is a Juniper guide I used but it was a little bit different and didn't work for me. http://www.juniper.net/us/en/local/pdf/day-one-guides/7100110-en.pdf I used below: --Routing instance: routing-instances { DSL { instance-type virtual-router; interface ge-0/0/1.0; // <-- Most important part - ISP2 Interface must be a member to get correct incoming context. routing-options { static { route 0.0.0.0/0 next-hop 172.24.1.1; // ISP2 next hop } } } } --Firewall filter: firewall { filter DSL { term DSL { from { address { 192.0.1.210/32; // This is the address that will go into the virtual router (ISP2 addresses should go here) } } then { count source-route; log; routing-instance DSL; } } term default { // Everything else uses default routing table. then { count defualt-counter; log; accept; } } } } Jensen Tyler Network Engineer Fiberutilities Group, LLC -----Original Message----- From: Joe Maimon [mailto:jmai...@ttec.com] Sent: Friday, May 28, 2010 9:14 AM To: Ken Gilmour Cc: nanog@nanog.org Subject: Re: Junos Asymmetric Routing Firewalls that can route and service properly multiple "untrusts"? Good luck. Hit or miss. Constant flux. Place a router in front of it and that will get you a ways there. Ken Gilmour 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 > >
