I am configuring a Juniper SRX 300 Series to establish an IPSEC tunnel to Azure.

The Azure Vnet range is

The local range is

The configuration: (relevant bits with sensitive parts replaced with $PART)

​security {
    ike {
        proposal ike-proposal-azure {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm aes-256-cbc;
            lifetime-seconds 28800;
        policy ike-policy-azure {
            mode main;
            proposals ike-proposal-azure;
            pre-shared-key ascii-text "$PSK";
        gateway ike-gate-azure {
            ike-policy ike-policy-azure;
            address $AZUREGWPUBLICIP
            external-interface ge-0/0/0.0;
            version v2-only;
    ipsec {
        vpn-monitor-options {
            interval 10;
            threshold 10;
        proposal ipsec-proposal-azure {
            protocol esp;
            authentication-algorithm hmac-sha1-96;
            encryption-algorithm 3des-cbc;
            lifetime-seconds 27000;
        policy ipsec-policy-azure {
            proposals ipsec-proposal-azure;
        vpn ipsec-vpn-azure {
            bind-interface st0.0;
            vpn-monitor {
            ike {
                gateway ike-gate-azure;
                ipsec-policy ipsec-policy-azure;
            establish-tunnels immediately;
    flow {
        tcp-mss {
            all-tcp {
                mss 1350;
            ipsec-vpn {
                mss 1350;

​ There are also security rules/policies to allow traffic to/from the vpn and a route for 192,168.10.0/23 pointing to st0.0. ​ The Problem:

PS C:\windows\system32> ping -l 1500

Pinging with 1500 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for
    Packets: Sent = 4 Received = 0, Lost = 4 (100% loss),
PS C:\windows\system32> ping -l 1400

Pinging with 1400 bytes of data:
Reply from bytes=1400 time=8ms TTL=127
Reply from bytes=1400 time=7ms TTL=127

Ping statistics for
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 8ms, Average = 7ms

SMB traffic to Azure hosts is also affected. ​ When running wireshark on the azure host I see a bunch of fragments and fragment reassembly time exceeded. https://i.imgur.com/3c2c6uE.png

  • I have also now set "set security ipsec vpn ipsec-vpn-azure df-bit copy"
    – Aaron Tate
    Aug 31, 2018 at 0:59
  • That change appears to have resolved the issue.
    – Aaron Tate
    Aug 31, 2018 at 2:51
  • Bear in mind that you cannot test TCP MSS clamping with Ping/ICMP, because ICMP is, well... not TCP. By df-bit copy, you enable Path MTU Discovery to work. Almost all modern IP stacks do PMTUd, but it is notorious for its unreliability, because it depends on ICMP unreachable messages ("fragmentation needed, but df-bit set") making it back to the host. Aug 31, 2018 at 4:06
  • Testing if TCP MSS clamping is actually functional must be done on both involved TCP speakers, by capturing and analyzing the first two SYN and SYN-ACK packets, as they leave the initiator AND as they enter the responder. There is a field in the TCP header for MSS, and this field gets tampered with by MSS clamping: The router, firewall or VPM gateway lowers the value. Aug 31, 2018 at 4:15
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin
    Dec 25, 2018 at 9:24

1 Answer 1

set security ipsec vpn ipsec-vpn-azure df-bit copy

This resolves the above described issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.