[j-nsp] J/SRX and ip fragmentation

[Richard A Steenbergen]

Perhaps somebody with some experience on these platforms can help answer
this one. I have an SRX210 running 10.0R2 at my house, running an IPSEC 
ESP'd GRE tunnel over my trusty home connectivity to a J2300 on the 
other end (running 9.3R4, the last real junos image made for 'em). The 
network in the middle is of course some clunky old 1500-byte-only, so of 
course I have to dial down my MTU on the tunnel to something in the 1420 
dept. Now, for ordinary tcp traffic this isn't a problem because I can 
just adjust the mss and avoid fragmentation in the first place, but I 
happen to have some non-tcp traffic which is breaking because of the 
restricted MTU.

On the J-series I've configured every option I can find for fragmenting, 
including clear-df-bit, allow-fragmentation, and path-mtu-discovery on 
the tunnel interface, and system internet-options gre-path-mtu-discovery 
globally. The J appears to be neither fragmenting the packet as it goes 
into the ipsec tunnel, nor returning an icmp needfrag for pmtud to work 
correctly (though it's hard to tell exactly what is going on because I 
can't sniff or capture the traffic on the gr- interface on either side).

On the SRX side, it fragments the packets correctly as it transmits into 
the IPSEC tunnel (I can see the fragmented packets making their way 
out), but it seems to be silently eatting the fragments that are coming 
in, despite my having absolutely no configuration telling it to do so. 
Of course this might actually be what is causing the problem on the 
J->SRX side too, but again I can't manage to sniff either side on the 
gre interface so it's hard to tell what's happening. The quick and dirty 
way I'm generating a fragment that should fit is to do a ping -s 1800 
from a 1500 byte connected host, to an endpoint before the SRX. This 
generates a 1500 byte and a 300some byte fragment, but neither makes it 
to the end host. The documentation is a little vague on what you can or 
can't do with fragmentation and/or reassembly on the SRX, but the only 
options I can find to block frags would occur under the "security screen 
ids-options" level, and I don't have any screens configured (and every 
security policy is a straight permit all).

Is there some default filter which eats orphaned fragments on the SRX 
side? Does anybody know any more about the fragment handling 
capabilities on the SRX? Any techniques for sniffing the packets on the 
gre interface to see if they're even being correctly received by the SRX 
in the first place? For some reason a monitor interface on the gr- 
interface isn't picking up even simple pings to the local interface on 
the tunnel, and a packet-capture is only picking up invalid packets from 
the st0 interface instead of anything from the gre. Obviously it's hard 
to look in the middle to see whats happening, what with the IPSEC and 
all. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)