[Openswan Users] NAT Problem?

Paul Wouters paul at xelerance.com
Wed Mar 9 12:13:57 CET 2005


On Wed, 9 Mar 2005, Miguel Ángel Domínguez Durán wrote:

This looks like the NAT-OA bug in XP. Someone posted a patch that seemed
to fix this, which is still being reviewed by us. You can try out the patch,
which should be someone in the archive of the dev list.

Paul

> The log at /var/secure is:
> Mar  9 11:40:12 vpn ipsec__plutorun: Starting Pluto subsystem...
> Mar  9 11:40:13 vpn pluto[2086]: Starting Pluto (Openswan Version 2.3.0 
> X.509-1.5.4 PLUTO_USES_KEYRR)
> Mar  9 11:40:13 vpn pluto[2086]: Setting port floating to on
> Mar  9 11:40:13 vpn pluto[2086]: port floating activate 1/1
> Mar  9 11:40:13 vpn pluto[2086]:   including NAT-Traversal patch (Version 
> 0.6c)
> Mar  9 11:40:13 vpn pluto[2086]: ike_alg_register_enc(): Activating 
> OAKLEY_AES_CBC: Ok (ret=0)
> Mar  9 11:40:13 vpn pluto[2086]: starting up 1 cryptographic helpers
> Mar  9 11:40:13 vpn pluto[2086]: started helper pid=2133 (fd:6)
> Mar  9 11:40:13 vpn pluto[2086]: Using Linux 2.6 IPsec interface code
> Mar  9 11:40:14 vpn pluto[2086]: Changing to directory 
> '/etc/ipsec.d/cacerts'
> Mar  9 11:40:14 vpn pluto[2086]:   loaded CA cert file 'cacert.pem' (1334 
> bytes)
> Mar  9 11:40:14 vpn pluto[2086]: Could not change to directory 
> '/etc/ipsec.d/aacerts'
> Mar  9 11:40:14 vpn pluto[2086]: Could not change to directory 
> '/etc/ipsec.d/ocspcerts'
> Mar  9 11:40:14 vpn pluto[2086]: Changing to directory '/etc/ipsec.d/crls'
> Mar  9 11:40:14 vpn pluto[2086]:   loaded crl file 'crl.pem' (536 bytes)
> Mar  9 11:40:14 vpn pluto[2086]:   loaded host cert file 
> '/etc/ipsec.d/certs/vpncert.pem' (3605 bytes)
> Mar  9 11:40:14 vpn pluto[2086]:   loaded host cert file 
> '/etc/ipsec.d/certs/windowsxp.pem' (3557 bytes)
> Mar  9 11:40:14 vpn pluto[2086]: added connection description "windows"
> Mar  9 11:40:14 vpn pluto[2086]: listening for IKE messages
> Mar  9 11:40:14 vpn pluto[2086]: adding interface eth1/eth1 10.9.200.10
> Mar  9 11:40:14 vpn pluto[2086]: adding interface eth1/eth1 10.9.200.10:4500
> Mar  9 11:40:14 vpn pluto[2086]: adding interface eth0/eth0 213.9.234.19
> Mar  9 11:40:14 vpn pluto[2086]: adding interface eth0/eth0 
> 213.9.234.19:4500
> Mar  9 11:40:14 vpn pluto[2086]: adding interface lo/lo 127.0.0.1
> Mar  9 11:40:14 vpn pluto[2086]: adding interface lo/lo 127.0.0.1:4500
> Mar  9 11:40:14 vpn pluto[2086]: adding interface lo/lo ::1
> Mar  9 11:40:14 vpn pluto[2086]: loading secrets from "/etc/ipsec.secrets"
> Mar  9 11:40:14 vpn pluto[2086]:   loaded private key file 
> '/etc/ipsec.d/private/vpnkey.pem' (1643 bytes)
> Mar  9 11:41:36 vpn pluto[2086]: packet from 213.9.234.24:500: ignoring 
> Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
> Mar  9 11:41:36 vpn pluto[2086]: packet from 213.9.234.24:500: ignoring 
> Vendor ID payload [FRAGMENTATION]
> Mar  9 11:41:36 vpn pluto[2086]: packet from 213.9.234.24:500: received 
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
> Mar  9 11:41:36 vpn pluto[2086]: packet from 213.9.234.24:500: ignoring 
> Vendor ID payload [Vid-Initial-Contact]
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: responding to 
> Main Mode from unknown peer 213.9.234.24
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: transition 
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: 
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: transition 
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: next payload 
> type of ISAKMP Hash Payload has an unknown value: 232
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: malformed 
> payload in packet
> Mar  9 11:41:36 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: sending 
> notification PAYLOAD_MALFORMED to 213.9.234.24:500
> Mar  9 11:42:46 vpn pluto[2086]: "windows"[1] 213.9.234.24 #1: max number of 
> retransmissions (2) reached STATE_MAIN_R2
> Mar  9 11:42:46 vpn pluto[2086]: "windows"[1] 213.9.234.24: deleting 
> connection "windows" instance with peer 213.9.234.24 {isakmp=#0/ipsec=#0}
> 
> Hope you can throw some light into this.
> Thank you very much.
> 
> UN CORDIAL SALUDO
> 
> Miguel Ángel Domínguez Durán.
> Departamento Técnico.
> Cherrytel Comunicaciones, S.L.
> mdominguez at cherrytel.com
> http://www.cherrytel.com/
> Tlf. 902 115 673
> Fax 952218170
> ----- Original Message ----- 
> From: "Paul Wouters" <paul at xelerance.com>
> To: "Miguel Ángel Domínguez Durán" <mdominguez at cherrytel.com>
> Cc: <users at openswan.org>
> Sent: Tuesday, March 08, 2005 1:47 PM
> Subject: Re: [Openswan Users] NAT Problem?
> 
> 
> > On Tue, 8 Mar 2005, Miguel Ángel Domínguez Durán wrote:
> >
> >>       nat_traversal=yes
> >
> > you might want virtual_private= ?
> >
> >> conn windows
> >>       auto=add
> >>       auth=rsasig
> >>       left=213.9.x.x
> >>       leftcert=vpncert.pem
> >>       leftid="C=ES, ST=MALAGA, L=MALAGA, O=CHERRYTEL COMUNICACIONES S.L.,
> >> CN=vpn"
> >>       right=%any
> >>       rightcert=windowsxp.pem
> >>       rightid="C=ES, ST=MALAGA, L=MALAGA, O=Prueba, CN=prueba"
> >>       pfs=yes
> >>       keyingtries=0
> >
> > this is a tunnel to 1 IP only, since there is no leftsubnet.
> >
> >> The ipsec.conf in the windows machine contains the following:
> >> conn windows
> >>       left=%any
> >>       leftid="C=ES, ST=MALAGA, L=MALAGA, O=Prueba, CN=prueba"
> >>       right=213.9.x.x
> >>       rightsubnet=*
> >
> > this implies the server should have leftsubnet=0.0.0.0/0
> >
> > If you want ALL traffic to go to the server, use the leftsubnet line.
> > If you don't, remove the rightsubnet line.
> > If you meant to connect top just some ip network at the server, use that
> > as right/leftsubnet and exlude it from NAT in virtual_private.
> >
> > Paul 
> 



More information about the Users mailing list