MTU size on SYN packets

PeterUK

The USG can and does modify the TCP SYN, ACK MSS if on a interface set to 1000 MTU so it be no small feet to modify the TCP SYN MSS try it and find out for yourself on a interface.

The phone say at 192.168.254.132 without a VPN sends to the gateway at 192.168.254.129 the routing rule is from LAN1 to next hop tunnel0 at this point the USG and modify the TCP SYN MSS before it goes down the tunnel.

I also know other ISP like my 4G to O2 modify the MSS and see this when it gets to my server broadband.

tonygibbs16

Hello @PeterUK

Could you document what you think that the protocol stack diagram is in the 4G to O2 scenario you mention?
     - I think that the MSS/MTU would get changed in that scenario by the TCP layer in the phone.

I think that if a product like the USG had to de-encapsulate every segment passing through it in order to re-encapsulate it in smaller segments, then it would be really CPU intensive and slow.

I think that Path MTU discovery was intended to avoid that, by making the end hosts use MSS/MTU size that passes along the path without CPU intensive de-encapsulation and re-encapsulation at every intermediate router.

Kind regards,
     Tony

PeterUK

Their would be no de-encapsulate needed I posted above about the MSS what the phone sends to the LAN1 gateway before it goes down the tunnel its just two packets that need to be modified then each end sends the right size packets to each other and fits down the tunnel.

https://us.v-cdn.net/6029482/uploads/editor/he/u3yn21hjct08.png

tonygibbs16

Hello @PeterUK

I have found this really helpful Cisco explanation of what I think we are discussing, see https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

Thoughts?

Kind regards,
      Tony

tonygibbs16

Hello @PeterUK

Thanks for the Wireshark capture.

What it is showing is a TCP conversation between a phone and USG, where TCP is involved in each device.

But when there are intermediate routers involved and the USG is not the endpoint, then I think that the scenario is more complex, because TCP is not involved in those intermediate routers along a tunnel.
      - the intermediate routers can only fragment or say ICMP 'fragmentation needed but DF set' if the DF flag is set.
            - or there is a setting whereby when a segment that is going down a tunnel has its DF bit cleared and then fragmentation takes place. The USG in this case could clear the DF bit on the segments and do fragmentation.

Kind regards,
     Tony

PeterUK

tonygibbs16 said:

Thanks for the Wireshark capture.

What it is showing is a TCP conversation between a phone and USG, where TCP is involved in each device.

Yes AND THEN the SYN goes down the tunnel and SYN, ACK comes out of the tunnel

The solution is very simple why is it hard for you to see it?

Maybe you think Wireshark showing the MSS is not in the packet? well it is you just change it for the given tunnel MTU! 

tonygibbs16

Hello @PeterUK

Maybe I am not understanding, but what happens when the endpoints use an MSS is bigger than the MTU of the tunnel in that scenario?

How do the endpoint hosts find out what the MTU of the tunnel is?

And what happens after the 3 way handshake?
          - The endpoint hosts start sending segments with MSS bigger than the MTU of the tunnel.
          - The routers along the tunnel either:
                  a) drop the segment and reply with ICMP.
                  b) clear the DF flag and fragment the segments.
                  c) fragment segments with DF already clear.

In a) no data gets through until the endpoint hosts reduce their MSS to be smaller than the smallest MTU along the tunnel.
           - even TCP window retries will fail.

In b) and c), data gets through.

Kind regards,
     Tony

tonygibbs16

Hello @PeterUK

Figure 2 in the MSc thesis at http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf illustrates my scenario a)

Kind regards,
     Tony

PeterUK

packet 

tonygibbs16 said:

Hello @PeterUK

Maybe I am not understanding, but what happens when the endpoints use an MSS is bigger than the MTU of the tunnel in that scenario?

For TCP by modifying the MSS in packet their be no packets that are bigger then the set MSS the USG modified (just the SYN and SYN, ACK nothing else) and it can do this before going down the tunnel and adding GRE and after it comes out of the tunnel removing the the GRE.

It be like this

client > USG >tunnel >USG > internet > remote end

The client send TCP SYN with MSS of 1460 to goes to the USG the USG changes this in the packet to MSS 1436 (if that's correct) goes down the tunnel to the USG and out to the internet to the remote end its at this point the remote end knows to send packets upto MSS 1436 to the client then the remote end sends a SYN, ACK of 1460 the USG then changes this in the packet to MSS 1436 goes down the tunnel to the USG and to the client its at this point the client knows to send packets upto MSS 1436 to the remote end.

tonygibbs16

Hello @PeterUK

Thanks very much for your post.

But in this scenario, does the client know that the USG has changed the MSS in the client's SYN ?
     - I think that it does not, and so the client could still attempt to send segments upto its original MSS in size.
             - that could still be too big.

What am I missing please?

Kind regards,
     Tony