[Openswan Users] Natted L2TP client fails
arunhere at inbox.com
Thu Apr 20 22:38:01 CEST 2006
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.
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,
> -----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
> You have no nat_traversal=yes and virtual_private= entries, so NAT-T is
>> conn mobile
> Don't use rightsubnetwithin. Just use rightsubnet=vhost:%no,%priv.
> NAT-T and authby=secret is not recommended.
>> conn mobile-wxp
> use 17/1701 for leftprotoport.
>> conn mobile-wxp2
> 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
> 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
>> 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 ACCEPT all -- * ipsec0 0.0.0.0/0
>> 0 0 ACCEPT all -- ppp+ * 0.0.0.0/0
>> 0 0 ACCEPT all -- * ppp+ 0.0.0.0/0
>> 0 0 ACCEPT all -- * eth0 0.0.0.0/0
>> 0 0 ACCEPT all -- eth0 * 0.0.0.0/0
>> 0 0 ACCEPT all -- * eth1 0.0.0.0/0
>> 0 0 ACCEPT all -- eth1 * 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_PNP is not set
>> # CONFIG_IP_MROUTE is not set
> 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"
> Building and integrating Virtual Private Networks with Openswan:
More information about the Users