[Openswan Users] Fw: l2tp Linux client again..
Paul Wouters
paul at xelerance.com
Sun Sep 30 18:01:47 EDT 2007
On Sun, 30 Sep 2007, Gbenga wrote:
> Just wondering if something is wrong with either the way I asked my question above or the question itself. I posted it about a week now and there has been no one with opnion on it. I thought I had it all set up right and since it working for win xp/2k, I thought there might be something I didn't do right for Linux.
In openswan 2.5.x in the testing/pluto/ directory should be the testcase
and example on how to use xl2tpd as a client
Paul
> Thank you,
> Gbenga
>
> --------------------------------
>
>
>
> Hi All,
>
> I will be grateful if someone more knowledgeable could assist me with my query. I have a L2TP/Openswan server that work well with Windows xp/2k, but I have tried to configure a linux l2tp client with limited success.
>
> The vpn server is behind nat with a single nic. The address on the single nic is on the network I am trying to provide access to 10.10.x.x, xlt2pd is version 1.1.05-1 on the server. IPSec connect ok and xl2tpd start up fine.
>
> Linux Openswan U2.4.7/K2.6.18 (netkey)
>
> On the iptables/firewall [nat device], I have the following rules that basically allow non-rfc 1918 through on proto 50, port 500 & 4500, then mark esp packet with dst 1701 and forward to vpn server.
>
> firewall rule:
> osogbetun at robbob:~$ sudo iptables -nL SYSENG-VPN
> Chain SYSENG-VPN (2 references)
> target prot opt source destination
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 MARK match 0x32 udp dpt:1701
> ACCEPT all -- !10.0.0.0/8 10.10.1.57 state RELATED,ESTABLISHED
> ACCEPT all -- !192.168.0.0/16 10.10.1.57 state RELATED,ESTABLISHED
> ACCEPT all -- !172.16.0.0/12 10.10.1.57 state RELATED,ESTABLISHED
> ACCEPT all -- 10.10.1.57 !10.0.0.0/8 state RELATED,ESTABLISHED
> ACCEPT all -- 10.10.1.57 !192.168.0.0/16 state RELATED,ESTABLISHED
> ACCEPT all -- 10.10.1.57 !172.16.0.0/12 state RELATED,ESTABLISHED
> ACCEPT udp -- !10.0.0.0/8 10.10.1.57 udp dpt:500 state NEW
> ACCEPT udp -- !192.168.0.0/16 10.10.1.57 udp dpt:500 state NEW
> ACCEPT udp -- !172.16.0.0/12 10.10.1.57 udp dpt:500 state NEW
> ACCEPT udp -- 10.10.1.57 !10.0.0.0/8 udp dpt:500 state NEW
> ACCEPT udp -- 10.10.1.57 !192.168.0.0/16 udp dpt:500 state NEW
> ACCEPT udp -- 10.10.1.57 !172.16.0.0/12 udp dpt:500 state NEW
> ACCEPT udp -- !10.0.0.0/8 10.10.1.57 udp dpt:4500 state NEW
> ACCEPT udp -- !192.168.0.0/16 10.10.1.57 udp dpt:4500 state NEW
> ACCEPT udp -- !172.16.0.0/12 10.10.1.57 udp dpt:4500 state NEW
> ACCEPT udp -- 10.10.1.57 !10.0.0.0/8 udp dpt:4500 state NEW
> ACCEPT udp -- 10.10.1.57 !192.168.0.0/16 udp dpt:4500 state NEW
> ACCEPT udp -- 10.10.1.57 !172.16.0.0/12 udp dpt:4500 state NEW
> ACCEPT esp -- !10.0.0.0/8 10.10.1.57 state NEW
> ACCEPT esp -- !192.168.0.0/16 10.10.1.57 state NEW
> ACCEPT esp -- !172.16.0.0/12 10.10.1.57 state NEW
> ACCEPT esp -- !10.0.0.0/8 10.10.1.57 state NEW
> ACCEPT esp -- !192.168.0.0/16 10.10.1.57 state NEW
> ACCEPT esp -- !172.16.0.0/12 10.10.1.57 state NEW
> LOGDROP all -- 0.0.0.0/0 0.0.0.0/0
>
> PREROUTING rules:
>
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> DNAT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1701 MARK match 0x32 to:
> 10.10.1.57
> DNAT udp -- !10.0.0.0/8 $PUB_INT udp dpt:500 to:10.10.1.57
> DNAT udp -- !192.168.0.0/16 $PUB_INT udp dpt:500 to:10.10.1.57
> DNAT udp -- !172.16.0.0/12 $PUB_INT udp dpt:500 to:10.10.1.57
> DNAT udp -- !10.0.0.0/8 $PUB_INT udp dpt:4500 to:10.10.1.57
> DNAT udp -- !192.168.0.0/16 $PUB_INT udp dpt:4500 to:10.10.1.57
> DNAT udp -- !172.16.0.0/12 $PUB_INT udp dpt:4500 to:10.10.1.57
>
> MANGLE rules:
>
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> MARK udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 MARK set 0x32
> MARK esp -- 0.0.0.0/0 0.0.0.0/0 MARK set 0x32
> MARK udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:500 MARK set 0x32
>
>
> tail -f /var/log/deamon.log on the vpn server shows this:
>
> Sep 23 21:16:47 laptop xl2tpd[6431]: Forked by Scott Balmos and David Stipp, (C) 2001
> Sep 23 21:16:47 laptop xl2tpd[6431]: Inherited by Jeff McAdams, (C) 2002
> Sep 23 21:16:47 laptop xl2tpd[6431]: Forked again by Xelerance (www.xelerance.com) (C) 2006
> Sep 23 21:16:47 laptop xl2tpd[6431]: Listening on IP address 0.0.0.0, port 1701
> Sep 23 21:16:52 laptop xl2tpd[6431]: Connecting to host 10.10.1.57, port 1701
> Sep 23 21:16:57 laptop xl2tpd[6431]: Maximum retries exceeded for tunnel 19621. Closing.
> Sep 23 21:16:57 laptop xl2tpd[6431]: Connection 0 closed to 10.10.1.57, port 1701 (Timeout)
> Sep 23 21:17:02 laptop xl2tpd[6431]: Unable to deliver closing message for tunnel 19621. Destroying anyway.
>
>
> tcpdump on he vpn server shows that the packets are hitting the vpn server.
>
> 21:10:00.627047 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x5f), length 180
> 21:10:01.627156 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x60), length 180
> 21:10:02.627647 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x61), length 180
> 21:10:03.630092 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x62), length 180
> 21:10:03.709360 IP 194.125.35.110.10001 > 10.10.1.57.4500: isakmp-nat-keep-alive
> 21:10:03.711540 IP 194.125.35.110.10001 > 10.10.1.57.4500: isakmp-nat-keep-alive
> 21:10:04.630602 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x63), length 180
> 21:10:05.633054 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x64), length 116
> 21:10:06.636862 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x65), length 116
> 21:10:07.637026 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x66), length 116
> 21:10:08.640782 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x67), length 116
> 21:10:09.639813 IP 194.125.35.110.10001 > 10.10.1.57.4500: UDP-encap: ESP(spi=0xe4cd0758,seq=0x68), length 116
>
> route on the vpn server:
>
> 0.0.0.0 via 10.10.1.240 dev eth1
> 10.9.181.32/29 via 10.10.1.3 dev eth1
> 172.23.233.0/24 via 10.10.1.3 dev eth1
> 10.9.32.0/24 via 10.10.1.66 dev eth1
> 10.10.0.0/16 dev eth1 proto kernel scope link src 10.10.1.57
> 10.11.0.0/16 via 10.10.1.3 dev eth1
> 10.9.0.0/16 via 10.10.1.3 dev eth1
> default via 10.10.1.240 dev eth1
>
> One thing I notice is that when I am connected via windows xp, there an explicit route back to the remote peer in ip route list, there is none when I try with linux which I think might be the source of the issue.
>
> This same configuration works very well for windows xp/2k.
>
> Linux client details are: Openswan v2.4.9/xl2tpd v1.1.11 [Linux Openswan U2.4.9/K2.6.20-16-generic (netkey)]
>
> Apologies for the long email, I thought if I provide enough info at the beginning it will save requests for more down the troubleshooting line.
>
> Rgds,
> Gbenga
>
>
>
> ___________________________________________________________
> Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
>
> ___________________________________________________________
> Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
--
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
More information about the Users
mailing list