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 <r...@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp