[Openswan dev] NAT-T bug on 1.0.1

[Tuomo Soini]

Following bugs are known to be in NAT-T code in 1.0.x series of openswan:



Port floating disabled won't work.

With disable_port_floating=yes nat-t connections won't work at all.



Connections on both end are jammed as %trap erouted when _both_ ends are 
behind nat:

ipsec auto --down conn

won't clear connection states correctly. ipsec auto --up conn won't 
bring it correctly back without ipsec auto --delete conn ; ipsec auto 
--add conn first.

When this problem is hit, remote end's log is full of this kind of logging:

Mar 15 23:03:03 gw pluto[20417]: packet from 192.0.2.5:500: initial Main 
Mode message received on 10.22.4.6:500 but no connection has been authorized

or:

Mar 13 22:09:12 gw pluto[20417]: packet from 192.0.2.5:4500: received 
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Mar 13 22:09:12 gw pluto[20417]: packet from 192.0.2.5:4500: ignoring 
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Mar 13 22:09:12 gw pluto[20417]: packet from 192.0.2.5:4500: ignoring 
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Mar 13 22:09:12 gw pluto[20417]: packet from 192.0.2.5:4500: received 
Vendor ID payload [Dead Peer Detection]
Mar 13 22:09:12 gw pluto[20417]: packet from 192.0.2.5:4500: initial 
Main Mode message received on 10.22.4.6:4500 but no connection

Problem seems to be in natted end only, if there is static tunnel and 
other end is not behind nat, non-natted end can negotiate tunnel up, 
natted end can't initiate connection without first removing natted 
connection.


mcr: Could this be that one thing you couldn't find which caused assert 
failure in pre-1.0.0 openswan code. That assert was then removed and it 
seemed like all worked?

-- 
Tuomo Soini <tis at foobar.fi>
Linux and network services
+358 40 5240030
Foobar Oy <http://foobar.fi/>