It should be dependent on the "df-bit" setting on the VPN. I don't remember which behavior is default, but setting it to "clear" may do what you want.
:w On Fri, Aug 10, 2012 at 12:36 PM, Terry Jones <terry.jo...@war-eagle.me> wrote: > Greetings All, > > > > Could someone please point me in the direction of some good information for > a current setup I have and would like to know what the expected behavior is. > > > > I have a site-to-site VPN setup between two SRX's. I'm in a development lab > that has a static NAT out to the internet through the corporate network. > (The other lab I'm connecting to is not local). Our connection to the > corporate network is to an ASA that DOES NOT support jumbo frames. I have > jumbo frames configured on the st0 interface and all interfaces all the way > back to the hosts on my side of the network. Same goes for the lab on the > other side of the tunnel. So I have 9000 bytes configured end-to-end, > however the transport the tunnel is configured across only supports std 1500 > bytes frames. > > > > The developers are sending 2000+ bytes sized packets that have the DF bit > set (and it has to be as such for now). > > > > I am trying to determine the expected behavior. I've been told that the > IPsec tunnel will fragment the traffic b/c it will not copy the DF bit from > the original packet once it is encapsulated, however, I cannot ping through > the tunnel with large packet sizes and the DF bit set. I've found a lot of > information and have worked a lot with fragmentation, but can't find > anything on this exact type of scenario. > > > > Thanks in advance for any input or information. > > > > Sincerely, > > Terry > > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp