Project

General

Profile

Issue #3369

Possible to set size limit for UDP packet because of double encapsulation

Added by Tom Hsiung 5 months ago. Updated 5 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
network / firewall
Affected version:
5.6.2
Resolution:

Description

Dear, everyone

The native IKEv2 IPsec kernel would use an MTU of 1400 bytes. So after first layer of encapsulation (via roadwarrior mode), the packet size is approximately 1464 bytes. Now the encapsulated would be encoded again at the gateway (via site-to-site mode). This would add another 64 bytes, resulting in a final packet size of 1528 bytes, which exceed the default MTU of the gateway (ethernet, MTU 1500 bytes).

This issue for TCP packets could be solved via tcp-mss rules defined in iptables kernel. However, what about the solutions for UDP packets? Thank you.

Tom

History

#1 Updated by Tobias Brunner 5 months ago

  • Category set to network / firewall
  • Status changed from New to Feedback

However, what about the solutions for UDP packets?

The proper solution is PMTUD. If that doesn't work and you can't fix it, try lowering the MTU of the outgoing interface or route, or use virtual interfaces as a crutch.

#2 Updated by Tom Hsiung 5 months ago

Yep, lowering the MTU of the outgoing interface is a good method. But I have macOS and iOS native IKEv2 clients software. It seems that they by default have a MTU of 1400 bytes for the virtual ipsec interface.

Name       Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
ipsec 1400  <Link#15>                       696969     0   543742     0     0
ipsec 1400  10            x.x.x.x         696969     -   543742     -     -

#3 Updated by Tobias Brunner 5 months ago

But I have macOS and iOS native IKEv2 clients software. It seems that they by default have a MTU of 1400 bytes for the virtual ipsec interface.

Usually, that probably works out fine. But for "double-tunneling" it's definitely not ideal. If you can't fix the MTU on the clients (manually or via PMTUD), you maybe can avoid tunneling their IKE/ESP packets again (if the client's can directly reach the VPN server).

#4 Updated by Tom Hsiung 5 months ago

Thanks. But I intend to use two-layer encapsulation, just for fun. Yep, I fixed the issue for TCP packets, quite easy. But recently, I found that Chrome explorer use UDP packets to transfer data between YouTube and clients. So. I don't know why Google use UDP protocol to communicate between Chrome and YouTube service. It seems that Google YouTube service end determines the UDP packet size. They don't reserve packet space for encapsulation, maybe.

Tom

#5 Updated by Tobias Brunner 5 months ago

I don't know why Google use UDP protocol to communicate between Chrome and YouTube service.

That's probably QUIC. You can disable it via chrome://flags/#enable-quic.

Also available in: Atom PDF