[Openswan Users] Openswan IPsec, l2tpd, pppd
Paul Wouters
paul at xelerance.com
Tue Feb 20 10:51:43 EST 2007
On Tue, 20 Feb 2007, Denis Stepanenko wrote:
> There are 3 remote LAN is present.
>
> This LANs connected between using VPN, also each VPN gateway running
> l2tpd for win XP "roadwarriors".
> .
> Configuration of OS and software for VPN are identical.
>
> But on one of VPN gateways (configs and logs listed below) after IPSec
> tunnel is on (Windows XP *L2TP* client) ppp connection NOT given up
> (connection *l2tp*-cert-org).
you mean to say that the ipsec tunnel establishes, but the l2tp/ppp tunnel
inside it does not? In general that is caused by path mtu / packet size
issues. Try decreasing your gateways' external interface mtu to 1480 or 1400.
> Certificate exchange passed ??, eroute shows that tunnel is up, but
> after 20-30 seconds connection go down.
Probably l2tp packets don't survive, and after 30 seconds XP hangs up the
ipsec connection.
> Version of Openswan: openswan-2.4.5
> Add. patches:
> openswan-2.4.5.kernel-2.4-klips.patch.gz
> openswan-2.4.5.kernel-2.4-natt.patch.gz
Upgrading to openswan 2.4.7 would be recommended (or 2.4.8 which is about to
get released)
> conn host1-host
> auto=start
> left=123.456.788
> left...<http://groups.google.com.ua/groups/unlock?msg=4b6d10d49bae1a73&hl=uk&_done=/group/comp.os.linux.networking/browse_thread/thread/2ade0da0216204b1/4b6d10d49bae1a73%3Flnk%3Dst%26q%3Dl2tp%2Bslackware%26rnum%3D2%26hl%3Duk>
> @host1.domain1.com
I am assuming that got mangled in posting and says leftid=@host1.domain1.com
> leftnexthop=123.456.789
> leftrsasigkey=0sA....
> leftsubnet=192.168.0.0/24
> right=789.654.322
> right...<http://groups.google.com.ua/groups/unlock?msg=4b6d10d49bae1a73&hl=uk&_done=/group/comp.os.linux.networking/browse_thread/thread/2ade0da0216204b1/4b6d10d49bae1a73%3Flnk%3Dst%26q%3Dl2tp%2Bslackware%26rnum%3D2%26hl%3Duk>
> @host.domain.com
> rightnexthop=789.654.321
> rightrsasigkey=0sA.....
> rightsubnet=192.168.1.0/24
> type=tunnel
the name host1-host is a mid misleading as this is a subnet-subnet tunnel.
> conn host-host2
> auto=start
> left=789.654.322
> left...<http://groups.google.com.ua/groups/unlock?msg=4b6d10d49bae1a73&hl=uk&_done=/group/comp.os.linux.networking/browse_thread/thread/2ade0da0216204b1/4b6d10d49bae1a73%3Flnk%3Dst%26q%3Dl2tp%2Bslackware%26rnum%3D2%26hl%3Duk>
> @host.domain.com
> leftnexthop=789.654.321
> leftrsasigkey=0slf......
> leftsubnet=192.168.1.0/24
> right=159.357.752
> right...<http://groups.google.com.ua/groups/unlock?msg=4b6d10d49bae1a73&hl=uk&_done=/group/comp.os.linux.networking/browse_thread/thread/2ade0da0216204b1/4b6d10d49bae1a73%3Flnk%3Dst%26q%3Dl2tp%2Bslackware%26rnum%3D2%26hl%3Duk>
> @host2.domain.com
> rightnexthop=159.357.751
> rightrsasigkey=0sA....
> type=tunnel
>
> -----------------------------------------------------
> *l2tp*-cert-org.conf ("roadwarriors" ) connection config
> ------------------------------------------------------
>
> root at host:~# cat /etc/ipsec.d/connections/*l2tp*-cert-org.conf
> conn *l2tp*-cert-org
> #
> #Configuration for one user with the non-updated Windows
> 2000/XP.
> #
> #
> # Use a certificate. Disable Perfect Forward Secrecy.
> #
> authby=rsasig
> pfs=no
> auto=add
> # we cannot rekey for %any, let client rekey
> rekey=no
> # Do not enable the line below. It is implicitely used, and
> # specifying it will currently break when using nat-t.
> # type=transport. See http://bugs.xelerance.com/view.php?id=466
> type=tunnel
If this is for l2tp clients, this should be type=transport. If your openswan
gives you a problem for type=transport with rightsubnet=vhost:%priv,%no, then
comment out the type=transport and it will be used implicitely.
> #
> left=789.654.322
> # or you can use: left=YourIPAddress
> leftrsasigkey=%cert
> leftcert=/etc/ipsec.d/certs/mordor.siliciosolar.es.pem
> # Work-around for original (non-updated) Windows 2000/XP
> clients,
> # to support all clients, use leftprotoport=17/%any
> leftprotoport=17/0
Change this to 17/1701, as openswan correctly uses port 1701 only.
> #
> # The remote user.
> #
> right=%any
> rightca=%same
> rightrsasigkey=%cert
> rightprotoport=17/1701
change this to 17/%any to support clients not using 1701 (pre XP SP2 and OSX)
> rightsubnet=vhost:%priv,%no
> ----------------------------------------------------
> l2tpd config
> ---------------------------------------------------
>
> root at host:~# cat /etc/l2tpd/l2tpd.conf
> [global]
> ;listen-addr =
>
> [lns default]
> ip range = 192.168.1.140-192.168.1.150
> local ip = 192.168.10.202
> require chap = yes
> refuse pap = yes
> require authentication = yes
> name = VPNserver
> ppp debug = yes
> pppoptfile = /etc/ppp/options.l2tpd
> length bit = yes
Should be fine, though you might want to upgrade to xl2tpd instead.
It fixes many issues over l2tpd 0.69/0.70 versions.
> --------------------------------------------------------
>
> root at host:~# cat /etc/ppp/options.l2tpd
> ipcp-accept-local
> ipcp-accept-remote
> ms-dns 192.168.1.3
> ms-wins 192.168.1.3
> noccp
> auth
> crtscts
> idle 1800
> mtu 1410
> mru 1410
Try an mru/mtu of 1360 here?
> nodefaultroute
> debug
> lock
> proxyarp
> connect-delay 5000
>
> ----------------------------------------------------------
> iptables rules
> ---------------------------------------------------------
>
> ###################################################
> #
> # IPSec VPN section starting here
> #
> #Allow IPSec connections
> iptables -A INPUT -p udp -m udp -s 0/0 --sport 500 --dport 500 -j
> ACCEPT
> iptables -A OUTPUT -p udp -m udp -d 0/0 --sport 500 --dport 500 -j
> ACCEPT
> iptables -A INPUT -p udp -m udp -s 0/0 --sport 4500 --dport 4500 -j
> ACCEPT
> iptables -A OUTPUT -p udp -m udp -d 0/0 --sport 4500 --dport 4500 -j
> ACCEPT
> iptables -A INPUT -p 50 -s 0/0 -j ACCEPT
> iptables -A OUTPUT -p 50 -d 0/0 -j ACCEPT
> iptables -A INPUT -p 51 -s 0/0 -j ACCEPT
> iptables -A OUTPUT -p 51 -d 0/0 -j ACCEPT
> iptables -A INPUT -s 0/0 -i $OPEN_SWAN_VIRT -j ACCEPT
> iptables -A OUTPUT -d 0/0 -o $OPEN_SWAN_VIRT -j ACCEPT
> #
> #Ports for l2tpd
> iptables -A INPUT -p udp -m udp -s 0/0 --dport 1701 -i $OPEN_SWAN_VIRT
> -j ACCEPT
> iptables -A OUTPUT -p udp -m udp -d 0/0 --sport 1701 -o $OPEN_SWAN_VIRT
> -j ACCEPT
> iptables -t nat -A PREROUTING -p udp -m udp -i $OPEN_SWAN_VIRT --sport
> 1701 --dport 1701 -j DNAT --to-destination $LAN_IP
I guess this is forwarding l2tp packets from outside ip to inside ip? But your
l2tpd.conf listens on all ip's i think because it did not specify a single ip.
With klips, you can just use a firewall rule that drops udp port 1701 on the ethX
interface, but allows udp port 1701 on the ipsecX interface. Then the l2tp port
can only be reached over IPsec, which is why Jacco used his "port forwarding hack".
> # Make nat a for "road warriors" network (ppp interface)
> iptables -t nat -A POSTROUTING -s $LAN_SUBNET -d $RW1 -j SNAT
> --to-source $PPP_IP
> iptables -t nat -A POSTROUTING -s $PPP_IP -d $RW1 -j SNAT --to-source
> $LAN_IP
> iptables -t nat -A POSTROUTING -s $LAN_SUBNET -d $RW2 -j SNAT
> --to-source $PPP_IP
I have no idea what these are doing. You should not be NAT'ing any
ipsec traffic or any traffic that will get tunneled through ipsec.
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[17] 951.753.852 #112: end
> certificate with identical subject and issuer not accepted
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[17] 951.753.852 #112:
> X.509 certificate rejected
And this is your biggest problem. You have issued a Certificate CA and a
computer certificate with the SAME NAME (common name). This would allow
the computer certificate to impersonate the Certificate CA, and therefor
openswan rejects the certificate. create a new certificate for this computer
using a different Common Name (CN=).
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112:
> deleting connection "l2tp-cert-org" instance with peer
> 951.753.852{isakmp=#0/ipsec=#0}
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112: I
> am sending my cert
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112:
> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
> cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #113:
> responding to Quick Mode {msgid:6bf34503}
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #113:
> transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #113:
> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #113:
> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> Feb 19 20:32:46 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #113:
> STATE_QUICK_R2: IPsec SA established {ESP=>0x1f8aa8cd <0x26a293c4
> xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}
Either, the previous error caused a delete of the wrong connection, which
then got re-established, or this is a very interesting bug where the
certificate was rejected but you can still connect using it after the initial
rejection. That would be a serious bug. But I think it is more likely that
this is a bug in deleting the wrong connection and that connection just
re-establishes itself. It is hard to tell because of your rewriting the IP's
and the limited logging in this case.
Can you test this identical setup on openswan 2.4.7? If it still happens,
could you temporarilly enable plutodebug=all and have that same roadwarrior
connect with the initial failure and then the success, and mail me the logs.
Note that it will contain a LOT of identifying email, so don't sent it to
the list.
> Feb 19 20:33:21 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112:
> received Delete SA(0x1f8aa8cd) payload: deleting IPSEC State #113
> Feb 19 20:33:21 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112:
> received and ignored informational message
> Feb 19 20:33:21 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852 #112:
> received Delete SA payload: deleting ISAKMP State #112
> Feb 19 20:33:21 host pluto[12966]: "l2tp-cert-org"[18] 951.753.852: deleting
> connection "l2tp-cert-org" instance with peer 951.753.852{isakmp=#0/ipsec=#0}
Paul
--
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