[j-nsp] Information for expected fragmentation behavior on IPsec tunnel
Wayne Tucker
wayne at tuckerlabs.com
Fri Aug 10 16:59:21 EDT 2012
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.jones at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list