SRX

Hi,

I'm investigating a fragmentation issue for a VPN on a SRX running JunOS 12.1X46-D40.2.

The remote host says that it's fragmented.

I have set the: set security flow tcp-mss ipsec-vpn mss 1300

Still fragmented.

So I was thinking, there must be a way to check if the SRX is fragmenting the data before putting it out the st interface?

No info is found via show interfaces st0.x extensive.

Tried to run monitor traffic without success, no data is beeing captured.

Does anyone have the skills to put me in the right direction on this?

Any show commands or other traceoptions that I can use to see that the box is fragmenting the packages?!

Best regards

Rob

Hi R_J

As you have mentioned that the remote peer complains that the packet received are fragmented , I should assume that the packets are fragnmented post encryption. So if tghis is the case SRX would be fragmenting the data on the egress interface not on st0.

In order to test of SRX is fragmenting it , please issue the command to copy the df bit from ineer ip header to outer ip header and send the ICMP packets across tunnels with df bit on and with various packet size to identify the PMTU.

This will not allow the traffic to reach remote end if it has to be fragmented by SRX and ICMP error message will be sent with correct MTU. ( Apply filter on egress interface to count number of packets sent out)

Another option is to  apply the flow trace on srx for the ESP packet ( with local and remote peer ip) as filter to see if same ipid is seen more than once for the same filter.

Regards

Hemant

Hi,

Could the packets be fragmented by an intermediate device/router as well, since TCP MSS has already been set to 1300 and assuming MTU on the SRX egress interface is default?

Also, just to confirm the fragmented packets seen on the remote side are TCP?

Setting the IPSec DF bit to copy may indicate which hop cannot pass the packet size provided ICMP Type 3 Code 4 is not filtered.

Useful links:

http://rtoodtoo.net/ipsec-tcp-mss-df-bit-and-fragmentation-in-srx/

http://kb.juniper.net/InfoCenter/index?page=content&id=KB25625&actp=search

Cheers,

Ashvin

Hi Ashvin,

Please find the answers below for the queries you had:

Could the packets be fragmented by an intermediate device/router as well, since TCP MSS has already been set to 1300 and assuming MTU on the SRX egress interface is default?

Hemant:Yes , the packets (ESP in this case) can be fragmented by intermediate router/L3 device.

Also, just to confirm the fragmented packets seen on the remote side are TCP?

Hemant: So can you please let me know is it the fragmented ESP packets seen on remote end or is it the plain text fragmneted packet? where exactly the pcap has been applied to check the fragmneted packets.

In order to look into the details firsdt you need to identify is it the packet fragmented post encryption or is it before encryption?

Let me know the details.

regards

Hemant

Hi Hemant,

Hemant:Yes , the packets (ESP in this case) can be fragmented by intermediate router/L3 device.

--> From the Intermediate routers point of view, its just an IP packet.

Also, just to confirm the fragmented packets seen on the remote side are TCP?

--> By this I meant that MSS would have no impact on ICMP or UDP packets. Thus, for instance if after ESP encapsulation, a UDP packet size exceeds the egress MTU, fragmentation would still happen whereas in case of TCP this would already be taken care of by window sizing.

Essentially, although TCP MSS 1300 is configured, other non-TCP packets could still be fragmented.

I guess the other questions are addressed to R_J 🙂