SRX

Hi Guys,

Quick basic quesiton here.  Picture this simple setup.

The User @ 10.11.11.2 initiates a conversation to the server @ 192.168.1.2.

The SRX has a satic route that says traffic to 10.11.11.2 next-hop is 172.16.1.2

All other routing is correct (routing to get from the host to the server).

My question is will the return path use the session that was started by the user and thus work properly flowing traffic back out the way it came in, or will the SRX drop the traffic trying to route the reply packets out a bad interface?

I know that if the server tries to talk to the user then this will DEFINITELY not work as the first packets will get sent the wrong way.

The return traffic should flow just fine. The inbound packet from the 1.2 server will have a session lookup done and just be pushed through. Their won't be a route lookup on the return, only on the initiating.

Thanks, this is was I assumed.

Hi Kevin ,

SRX do re-route lookup for return traffic .

was this behaviour chnaged & it is now sending traffic back to where traffic was originated from ( like netscreen ) ?

Hello,

During session creation, the SRX will look up the route back to the source. Two things can happen that I can think of:

* If the static route is going to a next-hop in a different zone, you will get a zone mismatch, per KB21363:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB21363&smlogin=true

In the diagram in the KB, packets from source 10.3.3.1 (represented by SRX C) are entering zone U2 (on SRX A) but SRX A has determined that the route back to 10.3.3.1 is out of zone U1, thus a zone mismatch occurs and according to the KB the packet is dropped. I believe in this case the session won't inititate in the first place as the error has occured in the first-packet-path phase during the route lookup.

* if the static route is going to a next-hop in the same zone, there shouldn't be any errors, but keep in mind that a reverse route lookup does indeed occur, as also implied in KB21256, during the summary at the bottom where it says "Before creating the session, during the reverse route lookup stage..."

https://kb.juniper.net/InfoCenter/index?page=content&id=KB21256&cat=SRX_SERIES&actp=LIST

Even if your static route is going out a different interface in the same zone, your routing still need to ensure the return packets make it to the originating host, as you'd guess. Also if you have ip-spoofing (screen options) enabled in that zone, the router will incorrectly believe the source-host has a spoofed IP and drop its packets.

Kind Regards,

Alshan

Hi.

I have make a test like this lab, but I see the result is vice verse.  After createing a seesion ( by telnet from 10.11.11.2 to 192.168.1.2), if I add more a static route 10.11.11.2/32 and with a bad next-hop, I cannot make anything at my telnet session. So, I think the route look up will be processed before session table. Please correct me if I'm wrong

Not sure I follow your question 100% but here are my comments.

The route lookup is only done once - it is done prior to establishing an entry in the session table when a new packet comes in. It is done after destination / static NAT and before the zone lookup is performed. No other route lookups are performed once the session is established.

Packets for existing sessions go through "fast path" and no route lookup is done.

Hey Guys,

I was doing a job with a customer the other day where this came into question as well - after doing a quick lab just now, I'm convinced that there is a route/forwarding table lookup for return traffic, which is contrary to all the Junos docs I've ever read (including the latest Juniper SRX Book).

Here's the topology I'm working with (SRX210, 12.1X45D10):

My PC (172.16.10.27)<------>(.254)SRX<------Internet------>8.8.8.8-Google
                                                ^
                                                 |---------st0.0-------->some other site

If I run continuos ping to 8.8.8.8 from my PC then commit a host route for my PC via st0.0, the pings stop immediately.  That says to me that the routing table is still being consulted for return traffic. 

The session table shows a whole bunch of one-way flow sessions outbound, so this "lookup" seems to be happening prior to any existing flow matching.  

Also, no new sessions are created from the Internet zone to the VPN zone (even though I've added an allow all policy), but this is probably due to the traffic coming in being "unsolicited" ICMP-Responses.

Weird.  Might be a good one to discuss over a beer in October Kevin 😉

Hey Guys,

Some interesting points being brought up here.  Here is my current production example.

I am using the fxp0 interface on my SRX to manage them out of band. I have a static route pointing to my NMS via the fxp0 interface.  

If a device tries to communicate with the NMS it fails since the packet tries to cross from data plane to control plane ( Enters a transit interfaces and tries to go out the FXP0 interface).

When my NMS system communicates with a device behind the Firewall, the traffic works great (Traffic enters the FW via a regular transit interface).  If a re-route did occur my NMS system would not work at all, the re-route would have a zone mismatch and the packet would be dropped.

Perhaps this is a unique case where re-route to the fxp0 is ignored?  Either way it saves me from doing NAT's and works fantastic as is since the NMS only polls and never needs to get spoken to other then by other systems on the OOB MGMT network.

Well fxp0 is very unique in that it does not (by design) route through the box. Nice twist on your part. 

Ok - so I was going to let this one lie. Darn you Ben - I will now go and do some testing cause this is a very interesting topic! Looking forward to meeting you and the rest of the gang in October. 

BTW - your comments in the other SRX thread about the routing instances descriptions in the Ambassador Day One NAT recipe are spot on. It is now my "go to" reference for my customers when they have questions. I just tell them "read this" and they love it.