2

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

The Azure Vnet range is 192.168.10.0/23

The local range is 10.49.236.0/24.

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 {
                optimized;
            }
            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 192.168.10.20

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

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

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

Ping statistics for 192.168.10.20:
    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.sstatic.net/fS2ua.png ​

Improve this question
5
  • I have also now set "set security ipsec vpn ipsec-vpn-azure df-bit copy"
    – Aaron Tate
    Commented Aug 31, 2018 at 0:59
  • That change appears to have resolved the issue.
    – Aaron Tate
    Commented 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.
    – Marc 'netztier' Luethi
    Commented 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.
    – Marc 'netztier' Luethi
    Commented 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 ♦
    Commented Dec 25, 2018 at 9:24

1 Answer 1

Reset to default
2 
set security ipsec vpn ipsec-vpn-azure df-bit copy

This resolves the above described issue.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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