[Openswan Users] NAT-T on ports != [500,4500] (fwd)

[Ronald Moesbergen]

I gathered some more info on this:

I have now confirmed that when using 2.3.0-plain all clients can connect
without trouble, but get disconnected after 2 hours and then can't
reconnect. If I use 2.3.0-cvs, 2 clients can still connect without
problems and even for more than 2 hours, but the third one has the
problem described below and can't connect at all (endless 'IPSec SA
Established' loop). I also tried using KLIPS with kernel 2.4.29 en
2.3.0-cvs, but then the exact same problem occurs, the other 2 clients
can still connect without trouble, the one client still cannot. I also
noticed that when using 2.3.0-plain I get:

IPsec SA established {ESP/NAT=>0x61c59236 <0xb104023a NATOA=10.0.0.157}
(Connection works)

when using CVS I get:

IPsec SA established {ESP=>0x946eee0a <0x8b4c0373 NATD=82.136.251.70}
(Connection fails)

Hope this helps to narrow it down. Thanks,
Ronald.
 

> > 
> > >>>>> "Paul" == Paul Wouters <paul at xelerance.com> writes:
> >     Paul> I donot know the answer to this. Anyone?
> > 
> >     Paul> I thought it would be either to or from 4500, 
> with the other
> >     Paul> end using a random port?
> > 
> >   Correct.
> >   The "server" (public IP, not moving) end should be 500, and then 
> > 4500.
> >   The "client" (box behind NAT, possibly moving around), 
> will pick a 
> > random source port, although many NAT boxes try to pick the 
> same port 
> > as the client used, so for the first client behind a NAT, it will 
> > often be 500/4500.
> > 
> 
> Thanks for the quick answer. So the server is fixed on port 
> 4500, and the client can pick a random port. I've now read 
> the source and can see that the two ports mentioned are the 
> 'from' port of the client and the 'to' port on the client, so 
> the server ports are not printed there. Then I guess this is 
> not the problem and there's something else going wrong. This 
> is a piece of the log file:
> 
> 20:57:25  packet from 82.136.251.70:12091: ignoring Vendor ID 
> payload [MS NT5 ISAKMPOAKLEY 00000004]
> 20:57:25  packet from 82.136.251.70:12091: ignoring Vendor ID 
> payload [FRAGMENTATION]
> 20:57:25  packet from 82.136.251.70:12091: received Vendor ID 
> payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
> 20:57:25  packet from 82.136.251.70:12091: ignoring Vendor ID 
> payload [Vid-Initial-Contact]
> 20:57:25  "dialup"[11] 82.136.251.70 #528: responding to Main 
> Mode from unknown peer 82.136.251.70
> 20:57:25  "dialup"[11] 82.136.251.70 #528: transition from 
> state STATE_MAIN_R0 to state STATE_MAIN_R1
> 20:57:26  "dialup"[11] 82.136.251.70 #528: NAT-Traversal: 
> Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
> 20:57:26  "dialup"[11] 82.136.251.70 #528: transition from 
> state STATE_MAIN_R1 to state STATE_MAIN_R2
> 20:57:26  "dialup"[11] 82.136.251.70 #528: Main mode peer ID 
> is ID_DER_ASN1_DN: '***'
> 20:57:26  "dialup"[12] 82.136.251.70 #528: deleting 
> connection "dialup" instance with peer 82.136.251.70 
> {isakmp=#0/ipsec=#0}
> 20:57:26  "dialup"[12] 82.136.251.70 #528: I am sending my cert
> 20:57:26  "dialup"[12] 82.136.251.70 #528: transition from 
> state STATE_MAIN_R2 to state STATE_MAIN_R3
> 20:57:26  | NAT-T: new mapping 82.136.251.70:12091/12092)
> 20:57:26  "dialup"[12] 82.136.251.70 #528: sent MR3, ISAKMP 
> SA established
> 20:57:26  "dialup"[12] 82.136.251.70 #529: responding to 
> Quick Mode {msgid:55b95e1f}
> 20:57:26  "dialup"[12] 82.136.251.70 #529: transition from 
> state STATE_QUICK_R0 to state STATE_QUICK_R1
> 20:57:26  "dialup"[12] 82.136.251.70 #529: transition from 
> state STATE_QUICK_R1 to state STATE_QUICK_R2
> 20:57:26  "dialup"[12] 82.136.251.70 #529: IPsec SA 
> established {ESP=>0xb120db61 <0x73189476 NATD=82.136.251.70}
> 20:57:26  packet from 82.136.251.70:12091: ignoring Vendor ID 
> payload [MS NT5 ISAKMPOAKLEY 00000004]
> 20:57:26  packet from 82.136.251.70:12091: ignoring Vendor ID 
> payload [FRAGMENTATION]
> 20:57:26  packet from 82.136.251.70:12091: received Vendor ID 
> payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
> 20:57:26  packet from 82.136.251.70:12091: ignoring Vendor ID 
> payload [Vid-Initial-Contact]
> 20:57:26  "dialup"[13] 82.136.251.70 #530: responding to Main 
> Mode from unknown peer 82.136.251.70
> 20:57:26  "dialup"[13] 82.136.251.70 #530: transition from 
> state STATE_MAIN_R0 to state STATE_MAIN_R1
> 20:57:27  "dialup"[13] 82.136.251.70 #530: NAT-Traversal: 
> Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
> 20:57:27  "dialup"[13] 82.136.251.70 #530: transition from 
> state STATE_MAIN_R1 to state STATE_MAIN_R2
> 20:57:27  "dialup"[13] 82.136.251.70 #530: Main mode peer ID 
> is ID_DER_ASN1_DN: '***'
> 20:57:27  "dialup"[12] 82.136.251.70 #530: deleting 
> connection "dialup" instance with peer 82.136.251.70 
> {isakmp=#0/ipsec=#0}
> 20:57:27  "dialup"[12] 82.136.251.70 #530: I am sending my cert
> 20:57:27  "dialup"[12] 82.136.251.70 #530: transition from 
> state STATE_MAIN_R2 to state STATE_MAIN_R3
> 20:57:27  | NAT-T: new mapping 82.136.251.70:12091/12092)
> 20:57:27  "dialup"[12] 82.136.251.70 #530: sent MR3, ISAKMP 
> SA established
> 20:57:27  "dialup"[12] 82.136.251.70 #531: responding to 
> Quick Mode {msgid:386ccd73}
> 20:57:27  "dialup"[12] 82.136.251.70 #531: transition from 
> state STATE_QUICK_R0 to state STATE_QUICK_R1
> 20:57:27  "dialup"[12] 82.136.251.70 #531: transition from 
> state STATE_QUICK_R1 to state STATE_QUICK_R2
> 20:57:27  "dialup"[12] 82.136.251.70 #531: IPsec SA 
> established {ESP=>0x97225186 <0x9b636c79 NATD=82.136.251.70}
> 
> 
> And this goes on and on for a few minutes (approx. 100 
> times). The client is behind a standard DSL router doing NAT 
> (Alcatel Speedtouch 510) and used to be able to connect with 
> plain 2.3.0 (this is cvs) but then the connection would drop 
> after 2 hours due to a rekeying with nat-t problem. I also 
> have an oakley log when this happens, available on request. 
> Note that two other users (myself included) can connect just 
> fine. The clients that work print 'new mapping 
> x.x.x.x:500/4500' whereas this client prints '12091/12092'. 
> Any idea what's wrong here? Thanks.
> 
> Regards,
> Ronald.
> 	
>