[j-nsp] J/SRX ICMP handling

[Dale Shaw]

Hi all,

Just tying up a loose end here --

After lots of to-and-fro with the JTAC (partially due to me getting
sidetracked with other things), I confirmed with them that the SRX
will drop ICMP response packets if the SRX did not forward the packet
that ultimately triggered the ICMP response. This behaviour can not be
influenced by security policy.

Reference PRs:

PR881586 (not public; relates to the "set security idp
sensor-configuration flow allow-icmp-without-flow" command)
PR818695

There is a VTY command that can influence this behaviour:

 start shell user root
 vty fwdd
 set usp flow allow-embed-icmp enable

I'm told that the command can apply on J-series, SRX branch and SRX
high-end but I'm assuming the syntax might be different in some cases.
Requires JUNOS 10.4R13, 11.4R7, 12.1R5, or 12.1X44-D10

I did not test the workaround as it is not persistent across reboots
and therefore isn't really manageable in my environment. As a result,
I didn't push the JTAC for a thorough explanation of what the command
actually does.

JTAC suggested working with my SE to get an Enhancement Request (ER)
raised, if we decided we really needed a config knob for this. I must
say I find it strange that commands like "set security flow
allow-dns-reply" exist while similar commands for ICMP handling do
not.

Cheers,
Dale

On Thu, Apr 25, 2013 at 3: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).