Expand all | Collapse all


Jump to Best Answer
  • 1.  no-syn-check

    Posted 07-14-2019 17:32

    Hi all,

    What does the following statements say under the flow stanza? Is it for ipsec tunnel? What is purpose of no-syn-check-in-tunnel there? Lastly when adding a new more reduced mss value statement(set security flow tcp-mss ipsec-vpn mss 1350) for ipsec, is there any thing is going to be wrong or miss config? 

    set security flow tcp-mss all-tcp mss 1470
    set security flow tcp-session no-syn-check
    set security flow tcp-session no-syn-check-in-tunnel
    set security flow tcp-session no-sequence-check




  • 2.  RE: no-syn-check

    Posted 07-14-2019 18:27
    All those flow options are global options except no-syn-check-in-tunnel. SRX supports disabling TCP SYN checks for tunneled traffic separate from the global clear-text values. This can be useful when you have asymmetric routing with IPsec tunnels or for IPsec session failover. Normally, default tcp-mss value will be 1460 (MTU-(IP + TCP header)). But in your case it is increased to 1470. If you are using standard MTU of 1500, it may cause fragmentation.
    Because of encryption overhead, setting ipsec tcp-mss to 1350 is safe to avoid fragmentation for ipsec traffic.

    Juniper Business Use Only

  • 3.  RE: no-syn-check

    Posted 07-14-2019 20:51

    Thanks Nellikka....

    Yes, you are right...mss is high...typically it is 1460....

    Can I ask about when generating icmp traffic throught ipsec tunnel on the box, typically I use 1460-28=1432 to determine whether or not resizing is happening...I know 1460 is still quite high size for ipsec but I want to double check with you about  is this math is correct to making normal final pakets size to ipsec tunnel in order to troubleshooting purpose?


    And also can you give a simple example/explaination for asymmetric routing for ipsec tunnel? It is unusual for me.... For instanse current situation is that there are 2 secure tunnel hubs (2X650srx). And each has 45 secure tunnels to connect to the their remote sites... each remote site has a 3rd party ISP(mpls) to conncet to the 650srx hub on my mpls backbone...where can be asymmetric routing happening?

    appreciate your ideas...


  • 4.  RE: no-syn-check

    Posted 07-14-2019 21:07

    That math is not right. Please go through this URL to understand about ipsec overhead.

    When you have multiple tunnels assymtric routing may happen if it is not properly designed. You have to ensure that incoming and outgoing traffic are going through via same tunnel. 


  • 5.  RE: no-syn-check

    Posted 07-15-2019 03:21


    According to the link that you provided...

    My icmp packet throught ipsec tunnel should be


    1460+orgIP 20B+org ICMP 8+ESP 38B+ExtIP 20B+ADSL 8B =1554B. ipsec sits on adsl int on spoke srx.

    Now is it okay or?


  • 6.  RE: no-syn-check

    Posted 07-15-2019 04:01

    Normally, ICMP payload will be very small in size. 64 bytes or less. In SRX it is 56 bytes by default. Remaining calcuation is ok. You can find out working packet size (without fragmentation) using "do-not-fragment" option in SRX ping command. In windows, use -f flag.  In Linux, it is -M flag. Example are given below. Decrease the packet size gradually to find out a working packet size like below:



    root> ping size 1500 do-not-fragment

    PING ( 1500 data bytes
    ping: sendto: Message too long
    ping: sendto: Message too long

    root> ping size 1472 do-not-fragment
    PING ( 1472 data bytes
    1480 bytes from icmp_seq=0 ttl=64 time=0.966 ms
    1480 bytes from icmp_seq=1 ttl=64 time=0.942 ms



    C:\Users\Nellikka>ping -f -l 1490

    Pinging with 1490 bytes of data:
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.

    Ping statistics for
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    C:\Users\Nellikka>ping -f -l 1400

    Pinging with 1400 bytes of data:
    Reply from bytes=68 (sent 1400) time=21ms TTL=50
    Reply from bytes=68 (sent 1400) time=36ms TTL=50
    Reply from bytes=68 (sent 1400) time=11ms TTL=50
    Reply from bytes=68 (sent 1400) time=11ms TTL=50

    Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),


    Nellikka@linx01:~$ ping -M do -s 1500 -c 2
    PING ( 1500(1528) bytes of data.
    From icmp_seq=1 Frag needed and DF set (mtu = 1500)
    From icmp_seq=1 Frag needed and DF set (mtu = 1500)

    --- ping statistics ---
    0 packets transmitted, 0 received, +2 errors

    Nellikka@linx01:~$ ping -M do -s 1472 -c 2
    PING ( 1472(1500) bytes of data.
    76 bytes from icmp_req=1 ttl=55 (truncated)
    76 bytes from icmp_req=2 ttl=55 (truncated)

    --- ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1002ms
    rtt min/avg/max/mdev = 1.922/1.929/1.937/0.044 ms



  • 7.  RE: no-syn-check

    Posted 07-15-2019 04:39

    The response from is 1480B. Is this perfect mss value? can we say or?



    root> ping size 1500 do-not-fragment

    PING ( 1500 data bytes
    ping: sendto: Message too long
    ping: sendto: Message too long

    root> ping size 1472 do-not-fragment 
    PING ( 1472 data bytes
    1480 bytes from icmp_seq=0 ttl=64 time=0.966 ms
    1480 bytes from icmp_seq=1 ttl=64 time=0.942 ms


  • 8.  RE: no-syn-check

    Posted 07-15-2019 04:55

    Yo have to check from your end system/srx as you are using IPsec. My example was without IPsec. 1350 bytes is safe and recommended size in your case for tunnel considering ESP and ADSL overhead. You may try with different packet size to find out working packet size.

    Calculation from my ping example with 1472 payload: 

    Payload size = 1472 bytes

    ICMP Header = 8 bytes

    IP Header = 20 bytes

    Total packet size = 1500 bytes = default interface MTU







  • 9.  RE: no-syn-check

    Posted 07-15-2019 05:12

    I do understand what you are pointing about determining the proper packet size for ipsec vpn and having some experiment about 1350 or 1328 to see frag happens or not etc.... Thats fine...


    What I was asking previously is that response "1480" ? What  Is this typically called?  is this size accepted ferfect size by both ends over the network path or?

  • 10.  RE: no-syn-check
    Best Answer

    Posted 07-15-2019 07:02

    It is known as IP Payload length. 1480+20=1500 is the packet size (MTU) supported/accepted by the network path between source and destination (end to end) without fragmentation. To find out TCP MSS (TCP payload length) from this, deduct TCP header size 20 from the IP payload length (1480-20=1460)




  • 11.  RE: no-syn-check

    Posted 07-15-2019 17:02

    Thanks Nellikka...Now it is clear....Really appreciated....

  • 12.  RE: no-syn-check

    Posted 09-12-2019 08:31

    Hey @Arix , it looks like @Nellikka last response provided the right solution for you. I'm going to go ahead and mark his last post as an Accepted Solution!