Project

General

Profile

Issue #3242

About when the NAT-T will happen

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

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

Description

Despite I have set

forceencaps=no

Some times the site-to-site IPsec communication adds a UPD header (8 bytes), other times not. What determines this phenomenon? I have conserve the space for the 8 bytes UDP header, however, it seems that this couple of days, it did not add a UDP header.

Tom

History

#1 Updated by Tobias Brunner 9 months ago

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

Some times the site-to-site IPsec communication adds a UPD header (8 bytes), other times not.

I don't think that's the case. If it was, there would be something seriously wrong. But check the log and the actual SAs in the kernel and perhaps the actual data, if a NAT is detected (even a faked one), there MUST be UDP encapsulation.

I have conserve the space for the 8 bytes UDP header

What does that mean?

#2 Updated by Tom Hsiung 9 months ago

I just captured the packets for several times. The earlier capture shows that there was no UDP encapsulation. Pay attention these non-UDP-encapsulated are between site-to-site tunnel. At the time of capture, there was no SNAT rule at the nat table OUTPUT chain. But there was indeed a SNAT rule at the nat table POSTROUTING chain. Maybe the strongswan though the two IPsec terminates were not behind NAT devices, so no UDP-encapsulation was needed.

Later, I add some additional DNAT rules to modify the communication ports. And captured packets again. This time, UDP-encapsulation happened.

What does that mean?

For example, with a physical MTU of 1500, with UDP-encapsulation, the remaining space is 1492 (subtracting this UDP header from MTU). Without UDP-encapsulation, the remaining space is still 1500. But I chose a space of 1492, no matter whether UDP-encapsulation is enabled or not.

Tom

#3 Updated by Tom Hsiung 9 months ago

And it is strange that, few packets could reach the maximum frame size.

After some research about the captured frame data, it seems that few packets reached 1516 bytes. Within this 1516 bytes, 16 bytes are frame header, so actual packet size should be 1500 byte. But these packets were so little in number.

Most frame (playing some YouTube streaming video) were fragmented, into a frame called IPv4 fragmentation protocol of 1508 byte (frame header included), with another fragmentation of 44 bytes (frame header included). Note that my system will add a frame header of 16 bytes to packets.

So, the 1508 frame equals 1492 bytes packet, and the 44-byte frame is equivalent to 28 bytes packet. And by combining these two fragments, the whole packet size is accurately 1500 bytes.

So, in conclusion, the maximum frame size is 1508, not 1516. But there were indeed some frame reached 1516. Just don't now why. But fortunately, with a target maximum frame size of 1508, there is no fragmentation at all.

Tom

Also available in: Atom PDF