Re: [Ipsec-tools-devel] patch supporting individual natt ports for each remote connection

[Wolfgang S. <wol...@di...>]

Timo,

please find attached Version 2 of my 'individual natt port' patch. 

I was unsure if I could disclaim the individual natt port feature and now
finally came to the conclusion that I need it, and it could makes sense for
anybody else as well. I will need it especially for the configuration
proposal which you gave me to address multiple vpn gateways behind a natt
router. I will come to this in a separate email.

Version 1 of this patch was very confusing, because I tried to prepare
already my succeeding 'destination' patch. I could drop my 'destination'
approach based on your feedback, and my revised V2 of my 'individual natt
port' approach could be streamlined dramatically; everything is straight
forward now. The syntax could be simplified as well and the man page is also
updated accordingly.

This is the Syntax extension:
========================================
remote address [[port]] { 
...
	nat_traversal [[port]] (on|off|force);
...
}

The patch is based on my previous patch p4b-p4a_anonymous_port.patch. It
particularly requires the ike_port_natt extension
from my V2_p4a-p3b_default_natt_port_in_listen_block.patch.


Thanks and Regards
	Wolfgang

P.S.: Sorry for giving you so much work.

-----Ursprüngliche Nachricht-----
Von: Timo Teräs [mailto:tim...@gm...] Im Auftrag von Timo Teräs
Gesendet: Samstag, 12. November 2011 13:33
An: Wolfgang Schmieder
Cc: ips...@li...
Betreff: Re: [Ipsec-tools-devel] patch supporting individual natt ports for
each remote connection

Hi,

On 11/07/2011 10:17 PM, Wolfgang Schmieder wrote:
> please find attached a patch which will allow to specify individual natt
> ports for each remote connection in the racoon configuration file. The
patch
> is based on a CVS trunk snapshot from yesterday evening:
> an...@an...:/cvsroot at 2011-11-06 22:00h MEZ plus my
> previous patch p2-p1_memory_leak_fixes_parser.patch.tar.bz2.
> 
> 
> The configuration file syntax examples are as follows:
> remote 199.16.4.17 [501],[4501] { ... # use port 501 and natt port 4501
...
> }
> 
> Alternative syntax:
> remote "remote site" { ...
>     remote_address 199.16.4.17 [501],[4501] ...
> }

I'm slightly confused what this should do. Where the manpage patch that
describes this new feature?

It seems that the general idea is to specify the *remotes* ports, but
this seems to also affect the choice of local ports.

This seems to at least affect the port choices when being initiator for
a connection. Does this also afffect responder mode (that is the
incoming request does not match remote block unless ports match)?

In either case, this seems to be a tricky option, as most NAT gateways
just can go and change your port numbers, which makes this not work
properly. You'd need to have a lot of control over how the NAT box
behaves. In that case it'd probably be just easier to have separate IPs.

In addition of understanding the how this works, and why it's useful, I
also have some implementation details I'm not uncomfortable with. Mostly
to do with the "enum RMCONF_ERR", "rmconf_errinfo_t" and related error
handling. These could be simplified.

- Timo