[Openswan Users] Natted L2TP client fails

Thu Apr 20 22:38:01 CEST 2006

Hi Paul,
    Actually I have nat_traversal=yes in my configuration and the NAT detection too happens. The tunnel is established and the traffic seems to be fine (i.e., EspinUDP - port 4500). But when L2TP is initiated, it fails. This was tested by establishing IPsec tunnel first using a IPsec client and then L2TP was tried (Windows NT box). 
   I doubt if it has got any thing to do with MTU settings. Any ways, will work on it and let you know the proceedings.

Also as a seperate issue, I have one more query (I suppose, i am not troubling you). 

I am also using two VPN test servers, Openswan v1.0.10 running on Linux 2.4.31 box. 

Following is the setup for VPN host to host configuration with pre-shared keys.
LAN1---SG1(NATTed)---Firewall=================SG2----LAN2
Where SG1 is behind the Firewall and is NATed. SG1 talks to Firewall & which in turn gets redirected to SG1.

It is observed that when the VPN tunnel is initiated for the first time, there  will not be any kind of problem & SG detects the presence of NAT. Phase-I and Phase-II get established successfully.

When the rekey is either started by SG1/SG2 i.e any direction, renegotiation fails everytime. VPN tunnel will not be back unless we restart the VPN on both SGs. 

But when the Natted server is Openswan-1.x and the other server is Openswan-2.4.X, and by making the Openswan-2.4.x as responder, the above mentioned configuration works finely.

Can you please suggest me a solution to crack this out.

(I tried to get this issue solved with the help of your latest book, but that book seems to be very useful only for Openswan-2.x).

Thanks and regards,
Arun S.

> -----Original Message-----
> From: paul at xelerance.com
> Sent: Wed, 19 Apr 2006 16:50:17 +0200 (CEST)
> To: arunhere at inbox.com
> Subject: Re: [Openswan Users] Natted L2TP client fails
> 
> On Tue, 18 Apr 2006, Arun S wrote:
> 
>> I am running a VPN server version 2.4.5rc5 on a Linux box, kernel
>> version 2.6.14. The server also runs a L2TP demon xl2tpd version 1.04.
>> This server is not behind any firewalls (so no NAT).
>> 
>> It is fine with all mobile clients that are not natted. With a mobile
>> client behind a firewall (i.e., peer is natted), IPsec gets established.
>> But L2TP fails.
>> 
>> I have attached "ipsec barf" with this.
> 
> From the barf:
> 
>> 1          192.168.1.127/32   -> 192.168.3.100/32   =>
>> tun0x1006 at 192.168.1.153
>> 0          192.168.50.0/24    -> 192.168.100.0/24   =>
>> tun0x1002 at 192.168.1.129
> 
>> KLIPS detected, checking for NAT Traversal support          	[FAILED]
> 
> This might be wrong in the verify command.
> 
>> config setup
>> 	interfaces="ipsec0=eth1"
>> 	nat_traversal=yes
>> 	strictcrlpolicy=no
>> 	forwardcontrol=yes
>> 	uniqueids=yes
>> 	nocrsend=no
> 
> You have no nat_traversal=yes and virtual_private= entries, so NAT-T is
> disabled.
> 
>> conn mobile
>> 	right=%any
>> 	rightsubnetwithin=0.0.0.0/0
> 
> Don't use rightsubnetwithin. Just use rightsubnet=vhost:%no,%priv.
> 
>> 	left=192.168.1.127
>> 	leftsubnet=192.168.1.127/255.255.255.255
>> 	leftnexthop=192.168.1.2
>> 	dpddelay=30
>> 	dpdtimeout=60
>> 	dpdaction=clear
>> 	esp=3des-md5
>> 	type=tunnel
>> 	authby=secret
> 
> NAT-T and authby=secret is not recommended.
> 
>> conn mobile-wxp
>> 	rightprotoport=17/%any
>> 	leftprotoport=17/0
> 
> use 17/1701 for leftprotoport.
> 
>> 	also=mobile
>> 	pfs=no
>> conn mobile-wxp2
>> 	rightprotoport=17/%any
>> 	leftprotoport=17/1701
>> 	also=mobile
>> 	pfs=no
> 
> Oh. jsut remove mobile-wxp entirely
> 
>> + egrep '^' all/rp_filter default/rp_filter eth0/rp_filter
>> eth1/rp_filter ipsec0/rp_filter lo/rp_filter
>> all/rp_filter:0
>> default/rp_filter:1
>> eth0/rp_filter:1
>> eth1/rp_filter:0
>> ipsec0/rp_filter:1
> 
> Ensure rp_filter is fully disabled.
> 
>> Red Hat Linux release 9 (Shrike)
> 
>> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>  pkts bytes target     prot opt in     out     source
>> destination
>>     0     0 ACCEPT     udp  --  eth1   ipsec0  0.0.0.0/0
>> 0.0.0.0/0          udp dpt:4500
>>     0     0 ACCEPT     all  --  ipsec0 *       0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  *      ipsec0  0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  ppp+   *       0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  *      ppp+    0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  *      eth0    0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  *      eth1    0.0.0.0/0
>> 0.0.0.0/0
>>     0     0 ACCEPT     all  --  eth1   *       0.0.0.0/0
>> 0.0.0.0/0
> 
> This table looks overly complex. I would just allow all FORWARD, and
> depend on
> the INPUT and OUTPUT firewall rules to block undesired packets.
> 
>> # CONFIG_IP_ADVANCED_ROUTER is not set
> 
> You should enable advanced routing in your kernel
> 
>> CONFIG_IP_FIB_HASH=y
>> # CONFIG_IP_PNP is not set
>> # CONFIG_IP_MROUTE is not set
>> CONFIG_IPSEC_NAT_TRAVERSAL=y
>> CONFIG_INT_AH=m
>> CONFIG_INET_ESP=m
>> CONFIG_INET_IPCOMP=m
>> CONFIG_INET_TUNNEL=m
> E
> Having AH/ESP/IPCOMP without hacing CONFIG_NETKEY makes no sense. I am
> surprised it compiled.
> 
>> # The authpriv file has restricted access.
>> authpriv.*						/var/log/secure
> 
> I am not sure why all the logs are missing, since they should be where we
> expect them. Perhaps you deleted/cleaned the logfile and did not restart
> syslogd so it still logged to the deleted logfile?
> 
> It would probably tell you "nat traversal disabled"
> 
> Paul
> 
> --
> Building and integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155