[j-nsp] J/SRX ICMP handling

[Per Westerlund]

In the context of this conversation it is implicit that IPsec is used, with st0.x interfaces. They have nowhere to attach filters!

To be able to use filters with st0.x interfaces, you have to wrap one more layer of interface. GRE is one obvious solution (can have attached filters), can probably use IP-IP instead, but I haven't thought that one through really.

Adds complexity (GRE/IPsec must terminate at different points, different IP addresses, not as easy as with Cisco), but should work.

/Per

25 apr 2013 kl. 16:50 skrev Tim Eberhard <xmin0s at gmail.com>:

> Selective packet services is always an option assuming you're in a branch srx (650 and below).
> 
> Basically just write a firewall filter that allows icmp with a then action of packet mode. Keeping track of icmp may not add any value but be aware with SPS you now lose NAT, screens and IDP (which you said you don't use already) but those may not be an issue in your environment.
> 
> Hope this helps,
> Tim Eberhard
> 
> On Apr 24, 2013, at 10:23 PM, Dale Shaw <dale.shaw+j-nsp at gmail.com> wrote:
> 
>> Hi all,
>> 
>> This post relates to a previous post of mine on asymmetrically routed
>> UDP traffic:
>> https://puck.nether.net/pipermail/juniper-nsp/2012-December/024878.html
>> 
>> It seems as though a J/SRX in flow mode will drop ICMP packets such as
>> unreachable and ttl-exceeded if, after consulting the session table,
>> an entry corresponding to the header embedded in the ICMP packet is
>> not found. In other words, "I'm gonna drop any ICMP packets[1] I see
>> if I didn't handle the associated conversation".
>> 
>> Assume I send a UDP packet between hosts "A" and "D" and it's routed
>> outbound via SRX "B", and for whatever reason an ICMP unreachable or
>> ttl-exceeded is generated (think traceroute). If that ICMP packet is
>> sent towards host "D" not via SRX "B" but via SRX "C", SRX "C" drops
>> it:
>> 
>> (src/dst IPs replaced with "A" and "D")
>> Jan 23 14:53:45 14:53:44.938394:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
>> st0.1033:"D"->"A", icmp, (3/3)
>> Jan 23 14:53:45 14:53:44.938424:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
>> find flow: table 0x63ce7688, hash 494060(0x7ffff), sa "D", da "A", sp
>> 33438, dp 47488, proto 17, tok 7
>> Jan 23 14:53:45 14:53:44.938483:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
>> packet dropped, no session found for embedded icmp pak
>> Jan 23 14:53:45 14:53:44.938495:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT:
>> flow find session returns error.
>> 
>> Seems like perfectly reasonable behaviour for a firewall, right?
>> Right, except when it's not :-)
>> 
>> Can this behaviour be modified without fully or selectively running in
>> packet mode? I'm running JUNOS 10.4R11.
>> 
>> Cheers,
>> Dale
>> 
>> [1] Well, any ICMP packets that include a copy of the original
>> datagram's header: echo request/reply are forwarded (subject to being
>> permitted by security policy, of course).
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp