[j-nsp] Information for expected fragmentation behavior on IPsec tunnel

[Terry Jones]

The default is actually to clear the df-bit, which I have verified on the
srx, however, if this is case, then the traffic should be fragmenting when I
ping with large packets setting the df-bit. This setting should stay within
the encapsulated packet and then the outer ipsec packet is set to clear and
the packet should be fragmenting, which is it not.

I've opened a JTAC case, so we'll see what they say.

tjones at srx1-net04> show security ipsec security-associations index 131073
node0:
--------------------------------------------------------------------------
  ID: 131073 Virtual-system: root, VPN Name: Denver-CN
  Local Gateway: a.a.a.a, Remote Gateway: b.b.b.b
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.3

    Direction: inbound, SPI: 7075d78, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 3529 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2973 seconds
    Mode: Tunnel(10 10), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 2acb634b, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 3529 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2973 seconds
    Mode: Tunnel(10 10), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

Thanks,
Terry 

-----Original Message-----
From: Wayne Tucker [mailto:wayne at tuckerlabs.com] 
Sent: Friday, August 10, 2012 1:59 PM
To: Terry Jones
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Information for expected fragmentation behavior on
IPsec tunnel

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