SRX

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

 

thx.

Ar

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

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...

 

That math is not right. Please go through this URL to understand about ipsec overhead. https://packetpushers.net/ipsec-bandwidth-overhead-using-aes/

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. 

 

Thanks Nellikka,

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?

 

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:

SRX:

+++++++++

root> ping 192.168.1.10 size 1500 do-not-fragment

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

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

Windows:

++++++++++

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

Pinging 8.8.8.8 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 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

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

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

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

Linux:-
++++++++

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

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

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

--- 8.8.8.8 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

 

 

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

SRX:

+++++++++

root> ping 192.168.1.10 size 1500 do-not-fragment

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

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

 

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

 

 

 

 

 

 

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?

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)

 

 

 

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

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!