Project

General

Profile

Feature #625

Add option to force the use of NAT-T (or any other) port via charon-nm

Added by Raphael Geissert over 6 years ago. Updated 7 months ago.

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

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.

Associated revisions

Revision 1157d3e0
Added by Tobias Brunner 7 months ago

Merge branch 'nm-server-port'

Adds the option to use a custom server port in the NM plugin.

Fixes #625.

History

#1 Updated by Raphael Geissert about 4 years ago

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

#2 Updated by Tobias Brunner about 4 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 about 4 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 about 4 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 9 months ago

  • Target version set to 5.8.3

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

#6 Updated by Tobias Brunner 7 months ago

  • Subject changed from Add option to force the use of NAT-T port via charon-nm to Add option to force the use of NAT-T (or any other) port via charon-nm
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Also available in: Atom PDF