[Openswan dev] [PATCH] Openswan 2.2.0/2.3.0dr4 NAT-T source port other than 500/4500

[Tuomo Soini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ilia.sotnikov at asstra.by wrote:
| Case 1. NAT box between peers could also do port translation. It's
obvious
| and could
| happen in real world. In this case, Main mode will reach responder with
| source port other
| than 500/4500.
|
| draft-ietf-ipsec-nat-t-ike states that "... The NAT may change the IKE
UDP
| source port,
| and recipients MUST be able to process IKE packets whose source port is
| different than 500. ..."
|
| Pluto behaves different: it logs "initial Main Mode message received on
| <host>:<port> but no
| connection has been authorized" and stops handling Main mode from that
| peer. The reason of
| this is when NAT-T is activated the function
find_host_pair_connections ()
| tries to find a connection
| with exact source:source_port and destination:destination_port match. In
| this situation the match
| fails with the above result.

Yep. That's old problem. I's been discussed several times since
super-freeswan days without fix.

| Case 2. When both peers confirm that one of them (or both) is NATed and
| port floating is enabled
| they update their correponding connections to have ports to be 4500 (or
| other if port translation
| occured) as described in draft. Then, if initiator, for example, reboots
| or the connection is replaced,
| it can't complete its initiation because responder waits for
connection on
| port 4500, not on 500.

Hah! That might explain problems I've seen with ipsec-gatways on both
ends being natted and pluto not being able to bring connection back
after dpd kicking in.

| This situation also mentioned in draft-ietf-ipsec-nat-t-ike as "... Once
| port change has occurred, if
| a packet is received on port 500, that packet is old. If the packet is an
| informational packet, it MAY
| be processed if local policy allows. If the packet is a Main Mode or
| Aggressive Mode packet (with
| same cookies than previous packets), it SHOULD be discarded. If the
packet
| is new Main Mode or
| Aggressive exchange then it is processed normally (the other end might
| have rebooted, and this is
| starting new exchange). ...".
|
| In this case the reason is that patch sumbitted by Andreas Steffen tries
| to find such connection only
| when a packet is received on port 4500 (when md->iface->ike_float is set)
| and fails because of
| destination port 500.
|
| Case 3. When both peers confirmed NAT and switched to port 4500 and then
| you manual down the
| connection on one of them, port information is preserved. It is optimal
| because both peers know that
| NAT will happen and there is no need to exchange over port 500.
| Considering above mentioned 2nd
| case, this will prevent connection to be finished successfully when
| responder, for example, rebooted
| or Openswan restarted.

Exactly.

- --
Tuomo Soini <tis at foobar.fi>
Linux and network services
+358 40 5240030
Foobar Oy <http://foobar.fi/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCCMISTlrZKzwul1ERAuJyAJ93DHi6qjqpIYPItYk27Uvkz0JZ/gCeK3+e
Xx1wD/lnTSIFykEXdN0cU6o=
=cntb
-----END PGP SIGNATURE-----