[Openswan Users] About NAT-T on Openswan

[Zheng Chuanbo]

Thanks for help. I checked the code and found that nat_traversal was 
not enabled by default. (It's strange that by config nat_traversal
in ipsec.conf, nat-t was not enabled. I changed the script _realsetup
and it worked.)

I now tested with winXP and openswan. With the configuration below 
NAT-T worked fine. 

conn cert
        authby=rsasig
        left=10.0.0.137
        leftrsasigkey=%cert   
        leftcert=zcb.pem
        right=%any
        rightsubnet=192.168.1.113/32
        rightrsasigkey=%cert
        auto=add 


But in this config, before a user was able to connect to the gateway,
the VPN has to be configured to a specific host (192.168.1.113). And
Only one user can connect at the same time.(openswan has such a limitation,
is that right?)

So I did another test. I removed the line "rightsubnet=192.168.1.113/32"
from the config above. I also tried  virtual_private network as below.
With this configuration, I got an error of "cannot respond to IPsec 
SA request because no connection is known". Below is the detailed 
messages.  Is there any way to avoid such a problem?


192.168.1.113	 192.168.1.197	10.0.0.195		 10.0.0.137
(winxp)               (redhat 9.0)                (openswan2.3)
NAT client=====>       NAT device          ======> NAT server

config setup
        interfaces="ipsec0=eth0"
        klipsdebug=all
        plutodebug=all
        nat_traversal=yes
        virtual_private=%v4:192.168.1.0/24
conn cert   
        authby=rsasig 
        left=10.0.0.137
        leftrsasigkey=%cert
        leftcert=zcb.pem
        right=%any
        rightsubnet=vhost:%no,%priv
        rightrsasigkey=%cert
        auto=add

Jun 14 20:24:22 swytest1 pluto[26116]: | NAT-T: new mapping 10.0.0.196:500/4500)
Jun 14 20:24:22 swytest1 pluto[26116]: | processing connection cert[2] 10.0.0.196
Jun 14 20:24:22 swytest1 pluto[26116]: | NAT-T: updating local port to 4500
Jun 14 20:24:22 swytest1 pluto[26116]: | NAT-T connection has wrong interface definition 10.0.0.137:4500 vs 10.0.0.137:500
Jun 14 20:24:22 swytest1 pluto[26116]: | NAT-T: using interface eth0:4500
Jun 14 20:24:22 swytest1 pluto[26116]: "cert"[2] 10.0.0.196 #1: sent MR3, ISAKMP SA established
Jun 14 20:24:22 swytest1 pluto[26116]: | processing connection cert[2] 10.0.0.196
Jun 14 20:24:22 swytest1 pluto[26116]: "cert"[2] 10.0.0.196 #1: cannot respond to IPsec SA request because no connection is known for 10.0.0.137[CERTINFO]...10.0.0.196[CERTINFO]===192.168.1.113/32
Jun 14 20:24:22 swytest1 pluto[26116]: "cert"[2] 10.0.0.196 #1: sending encrypted notification INVALID_ID_INFORMATION to 10.0.0.196:4500
Jun 14 20:24:22 swytest1 pluto[26116]: "cert"[2] 10.0.0.196 #1: failed to build notification for spisize=0 
Jun 14 20:24:23 swytest1 pluto[26116]: | processing connection cert[2] 10.0.0.196
Jun 14 20:24:23 swytest1 pluto[26116]: "cert"[2] 10.0.0.196 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x9bb2fdbe (perhaps this is a duplicated packet)




>On Sun, 12 Jun 2005, Zheng Chuanbo wrote:
>
>> 10.0.0.183		10.0.0.1	192.168.0.183		192.168.0.137
>> (openswan2.3)        (redhat 9.0)                (openswan2.3)
>> NAT client=====>       NAT device       ======> NAT server
>>
>> The nat translations is on a redhat9.0, the command is as follows,
>> 	iptables -I POSTROUTING -t nat -s 10.0.0.0/24 -j SNAT --to 192.168.0.183
>
>add -d \! 192.168.0.0/16 just to be safe?
>
>> During the setup of the connection, the tcpdump output is as follows,
>
>that does not give us any information. log files are more useful
>
>> On 10.0.0.183 'ipsec spi' also gave a similar result as above. When run ping
>> from 10.0.0.183 to 192.168.0.137, on 192.168.0.137 with tcpdump I got,
>> 	21:07:38.823063 192.168.0.183 > 192.168.0.137: ESP(spi=0x9f38491f,seq=0x1)
>ESP packets, so no NAT was detected or supported.
>
>> So my questions is,
>> 1) Is the ipsec connection really setup? But why there are no responds?
>
>Use ipsec eroute (if using klips) to see if it  is really up, but seeing that
>you get ESP packets it seems to be the case.
>
>> 2) According to rfc3947, the port of ISAKMP should be changed from 500 to 4500
>> if NAT was detected. But from the tcpdump output, it seemed that the port was
>> not changed. So is nat-t really happened on the connection above?
>
>right. check the logs why. Probably one of the machines does not support NAT-T
>and nat-t was disabled?
>
>Paul
>