Project

General

Profile

Feature #625

Add option to force the use of NAT-T port via charon-nm

Added by Raphael Geissert over 5 years ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
networkmanager (charon-nm)
Target version:
Start date:
25.06.2014
Due date:
Estimated time:
Resolution:

Description

RFC5996 allows for the initiator to communicate to port 4500, even at the beginning of the connection. Attached patch adds a new "natt" option to charon-nm and nm-strongswan that makes charon-nm create the connection to the gateway on port 4500 - aka "check the box to force NAT-T port".

This is useful when traffic is blocked or messed around by firewalls and/or too broken NATs.

History

#1 Updated by Raphael Geissert over 3 years ago

Attached patch has been revisited for version 1.3.1 of the plugin.

#2 Updated by Tobias Brunner over 3 years ago

  • Status changed from New to Feedback

Wouldn't it be much more flexible to just make the remote server port configurable? (Default: 500)

And could you please base the patches on the nm-1.2 branch?

#3 Updated by Raphael Geissert over 3 years ago

Tobias Brunner wrote:

Wouldn't it be much more flexible to just make the remote server port configurable? (Default: 500)

The idea was that from a user perspective she would just mark the checkbox if the connection fails to be established.
OTOH, I do see an interest in being able to configure the port.

Perhaps the NAT-T checkbox and a port configuration box could be added, and the logic of the checkbox be handled directly by the GUI.
Ex. modifying the value of the port box, and greying it while the checkbox is marked.

What do you think?

#4 Updated by Tobias Brunner over 3 years ago

Perhaps the NAT-T checkbox and a port configuration box could be added, and the logic of the checkbox be handled directly by the GUI.
Ex. modifying the value of the port box, and greying it while the checkbox is marked.

What do you think?

I suppose that's a possibility. Using a custom port is not directly related to NAT-T, though. If there is no NAT detected, or randomized NAT-D payloads are used to force it, no UDP encapsulation is used even if a custom port is used (however, messages to that port will usually have to be sent with the non-ESP marker, refer to this recent response on the mailing list for the reasoning, which some implementations will only do/expect on the "NAT-T" port).

#5 Updated by Tobias Brunner about 1 month ago

  • Target version set to 5.8.3

I pushed changes to configujre a custom server port to the 625-nm-server-port branch.

Also available in: Atom PDF