ROS 5.0RC2 IPSec NAT-T with different clients

I decided to create this topic for MT community members to respond about changes in IPSec and the results with different clients.

I’m going to do the first post with results I got using Windows XP Pro client with the same settings that worked with real IP address and didn’t when client was behind NAT and VPN access was provided by ROS 4.11 router. This is what I got from logs wit new ROS release:
(n.n.n.n - IP address of my MikroTIK 5.0RC2)
(c.c.c.c - IP address of router that NATs my Windows XP Pro client)

Oct/28/2010 23:15:27 ipsec,debug respond new phase 1 negotiation: n.n.n.n[500]<=>c.c.c.c[35270]
Oct/28/2010 23:15:27 ipsec,debug begin Identity Protection mode.
Oct/28/2010 23:15:27 ipsec,debug received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
Oct/28/2010 23:15:27 ipsec,debug received Vendor ID: FRAGMENTATION
Oct/28/2010 23:15:27 ipsec,debug received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Oct/28/2010 23:15:27 ipsec,debug 
Oct/28/2010 23:15:27 ipsec,debug Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02
Oct/28/2010 23:15:27 ipsec,debug 
Oct/28/2010 23:15:30 ipsec,debug Hashing n.n.n.n[500] with algo #2 
Oct/28/2010 23:15:30 ipsec,debug NAT-D payload #0 verified
Oct/28/2010 23:15:30 ipsec,debug Hashing c.c.c.c[35270] with algo #2 
Oct/28/2010 23:15:30 ipsec,debug NAT-D payload #1 doesn't match
Oct/28/2010 23:15:30 ipsec,debug NAT detected: PEER
Oct/28/2010 23:15:30 ipsec,debug Hashing c.c.c.c[35270] with algo #2 
Oct/28/2010 23:15:30 ipsec,debug Hashing n.n.n.n[500] with algo #2 
Oct/28/2010 23:15:30 ipsec,debug Adding remote and local NAT-D payloads.
Oct/28/2010 23:15:30 ipsec,debug the packet is retransmitted by c.c.c.c[35270].
Oct/28/2010 23:15:31 ipsec,debug the packet is retransmitted by c.c.c.c[35270].
Oct/28/2010 23:15:31 ipsec,debug NAT-T: ports changed to: c.c.c.c[40782]<->n.n.n.n[4500]
Oct/28/2010 23:15:31 ipsec,debug KA list add: n.n.n.n[4500]->c.c.c.c[40782]
Oct/28/2010 23:15:31 ipsec,debug Expecting IP address type in main mode, but FQDN.
Oct/28/2010 23:15:31 ipsec,debug invalid ID payload.
Oct/28/2010 23:15:32 ipsec,debug Expecting IP address type in main mode, but FQDN.
Oct/28/2010 23:15:32 ipsec,debug invalid ID payload.
Oct/28/2010 23:15:35 ipsec,debug Expecting IP address type in main mode, but FQDN.
Oct/28/2010 23:15:35 ipsec,debug invalid ID payload.
Oct/28/2010 23:15:38 ipsec,debug Expecting IP address type in main mode, but FQDN.
Oct/28/2010 23:15:38 ipsec,debug invalid ID payload.
Oct/28/2010 23:15:46 ipsec,debug Expecting IP address type in main mode, but FQDN.
Oct/28/2010 23:15:46 ipsec,debug invalid ID payload.
Oct/28/2010 23:16:02 ipsec,debug Expecting IP address type in main mode, but FQDN.
Oct/28/2010 23:16:02 ipsec,debug invalid ID payload.
Oct/28/2010 23:16:30 ipsec,debug phase1 negotiation failed due to time up. 20c44c2c03059ed6:edd4926f7282f202
Oct/28/2010 23:16:30 ipsec,debug KA remove: n.n.n.n[4500]->c.c.c.c[40782]
Oct/28/2010 23:16:34 ipsec,debug unknown Informational exchange received.

It seems that both sides can now negotiate about using NAT-T but they still get stuck somewhere.

Try v5rc2

*) ipsec - supports NAT-T drafts

That’s what I was using.

Now I had a chance to test it with Windows Vista and I was able to successfully establish VPN link using the same settings and Internet connection that I used for testing Windows XP client. Probably ROS needs some minor quickfix to be able to communicate with XP too.