Hi,
Based on the reading that I've done so far, my understanding of the SRX1 behaviour when the df-bit setting on an IPsec VPN is left at default (ie. "clear) is that the SRX won't send the ICMP type 3, code 4 response to the sender, it will simply do the fragmentation needed before putting the encrypted packet into the VPN tunnel. This setting is identical on both SRX1 and SRX2, therefore I would be very suprised to see any ICMP type 3, code 4 packets being used.
-> Sender here is the app client and the ingress packets can be fragmented by the SRX, so ICMP Type 3 Code 4 not required to be sent back to sender
What I now think is happening is that SRX2 is picking up the SYN-ACK packet being returned to the app client and adjusting the MSS in that packet to 1350, since that what the tcp-mss ipsec-vpn setting is on that SRX. This is why the SYN-ACK packet in the capture I've seen shows the adjusted MSS value, rather than the typical value of 1460.
-> Agree. Also, SRX2 may be fragmenting return ingress packets from the app server [Default df-bit clear behavior] as both SRXs have tunnel mtu of 1400.
I could possibly affect this behaviour by changing the df-bit setting on the specific IPsec tunnel to "copy" to force SRX1 to send the ICMP type 3, code 4 response back to app client. That may be one solution that could work. However, I'm hoping to convince the other end to do the MSS adjust on the SYN-ACK packet.
-> Not sure this would definitely resolve the issue as it seems to me its large return packets that are probably being dropped. If IPSec tunnel MTUs are assymentrical on Cisco v/s SRX [Cisco being larger than SRX], and if large return encapsulated packets from app-server have outer DF-bit set, the packet would be dropped by SRX and I think ICMP Type 3 Code 4 would need to be sent back to app-server.
Two additional things that you could verify/change:
1. Use same tunnel MTUs on both sides of tunnel
2. Ensure ICMP Type 3 Code 4 is allowed through to app server for PMTUD
Hope this helps.
Cheers,
Ashvin