SRX Services Gateway
Highlighted
SRX Services Gateway

Resizing doen't stop

[ Edited ]
‎08-30-2019 04:15 AM

hi people,

Why fregmentation is still occurred even assigning 1300 mss value to encrypted vpn traffic....?

4 REPLIES 4
Highlighted
SRX Services Gateway

Re: Resizing doen't stop

‎08-30-2019 04:53 AM
Hello,

Are you seeing encrypted traffic going into the tunnel or received from the other end?

A capture on the client and server would be ideal to see if the MSS is taking effect or something else in the path is re-writing the MSS value.

Best Regards,

Vikas



Juniper Business Use Only
Highlighted
SRX Services Gateway

Re: Resizing doen't stop

‎08-30-2019 05:07 AM

 

Are you seeing encrypted traffic going into the tunnel or received from the other end?
========>no,  it is outgoing direction intoext interface on junos device to adsl internet---->to another end -terminates encrypted vpn traffic.
A capture on the client and server would be ideal to see if the MSS is taking effect or something else in the path is re-writing the MSS value. 

==========>at the begining fragmentation happens

Highlighted
SRX Services Gateway

Re: Resizing doen't stop

‎08-30-2019 05:48 AM
Hi,

We will need to see the entire pcap to see what is the MSS received in the TCP handshake and what packet client (towards SRX) is sending.

Fragmentation would happen mostly when data is exchanged after the 3-way handshake. So we need to see the entire session to understand.

Best Regards,

Vikas



Juniper Business Use Only
Highlighted
SRX Services Gateway

Re: Resizing doen't stop

[ Edited ]
‎09-01-2019 05:55 PM

Hi all,

My topology is:

4500ex-------->650SRX/Ipsec_spoke-------internetoverADSL---------->1400SRX/Ipsec_hub------>4500ex---->9200ex---->3300ex---->Host/server(10.10.10.15)

When destination ip address of 10.10.10.15 was constantly pinging on 4500ex, cocurrently fragmentation number has been observed below. Each time statistics were cleared manually.


4500ex> ping 10.10.10.15 rapid count 1000 size 1472--------->during the constant pinging, there are 4000 packet fregmentated on the 650srx/spoke from > sh sec sta | mat Frag |ref 1
4500ex> ping 10.10.10.15 rapid count 1000 size 1400--------->during the constant pinging, there are 2000 packet fregmentated on the 650srx/spoke from > sh sec sta | mat Frag |ref 1

4500ex> ping 10.10.10.15 rapid count 1000 size 1395--------->during the constant pinging, there are 2000 packet fregmentated on the 650srx/spoke from > sh sec sta | mat Frag |ref 1

4500ex> ping 10.10.10.15 rapid count 1000 size 1394--------->during the constant pinging, there is no any fregmantation on the 650srx/spoke from > sh sec sta | mat Frag |ref 1
4500ex> ping 10.10.10.15 rapid count 1000 size 1393--------->during the constant pinging, there is no any fregmantation on the 650srx/spoke from > sh sec sta | mat Frag |ref 1
...
.....
and so on

 

This traffic goes into ipsec tunnel at spoke device....I checked this on 650srx>sh sec flo des-pre 10.10.10.15 prot 1... Anyway..

Which one is the best mss over icmp work above?
     Of course mss value of 1394....If am not I correct, please give explaination enough and properly!

 

mss + IPheader+Icmpheader+Esp header+ext IP
1394+ 20 + 8 + 38 + 20------------>So final packet size is 1480byte .Physical interface mtu is 1512

1394byte-12byte? Why? because normal tcp header(20byte) instead of icmp header....So 1382byte is the mss for the tcp ipsec outgoing traffic on srx650....

Can you tell me please why ridiculous fragmentation still happening as 1328 value is assigned which is more and more less value than 1382? Or is this software bug?


Current conf on spoke:
650SRX> sh conf | di se | mat ms
set security flow tcp-mss all-tcp mss 1450
set security flow tcp-mss ipsec-vpn mss 1328

 

Current conf on hub:
1400SRX> sh conf | di se | mat ms
set security flow tcp-mss ipsec-vpn mss 1328

 

Secondly why 4000 packets were fragmentated over icmp with mss 1472 as with mss 1400 has only 2000. Over size packet must be fragmentated into 2 pieces not more than 2? If yes this is Junos faulty.

 

Last question,  can UDP traffic go to into IPsec tunnel? If yes how we can handle the udp mtu size? 

thx
A.

Feedback