openswan on ubuntu 14.04 LTS #75
Comments
|
the same problem as me |
|
Can you try to add this to the ppp options file: refuse-chap |
|
it works: ipsec.confversion 2.0 config setup conn l2tp-psk xl2tpd.conf[global] [lns default] optionsms-dns 8.8.8.8 chap-secretszhangxxxx * "_" 192.168.0.1/24 ipsec.secrets106.186.127.xxx 0.0.0.0: PSK "*******" |
|
I observe exactly the same: installing via a script I wrote works 100% of the times in 12.04, for OSX and iOS clients. With the same script/resulting setup under a fresh 14.04, the connection negotiation from the same clients that worked perfectly under 12.04 fails/stops at the exact same spot as the OP showed. It appears that xl2tpd does not get the connection request (?) from openswan, and just sits there. How can I help to debug this? |
|
To elaborate on this: the only difference I can spot is that under 12.04 we have (note the "NATOA=none" in the last line!) whereas on 14.04 we don't have the explicit workaround and accept the peer's proposal (note the "NATOA=192.168.8.14" on the last line) and we do not enter into the L2TP-PSK-noNAT connection. Again, exact same configuration as under 12.04 where this works: Below I include the complete logs for both 12.04 and 14.04 with the exact same configuration (in fact, I updated from that 12.04 instance to 14.04 keeping the openswan/xl2tpd configuration). |
|
And just to top this off: I downgraded from openswan 1:2.6.38-1 in 14.04 to the default openswan 1:2.6.37-1 in 12.04 (from here: http://www.ubuntuupdates.org/package/core/precise/universe/base/openswan) and upon connecting, it immediately works, going as expected into the noNat connection: |
|
On Sat, 9 Aug 2014, fortiko wrote:
That is a bug with transport mode using the wrong IP address. I don't
Upstream openswan is dead. While I maintain openswan in RHEL6 (which Paul |
|
Thanks for the clarifications. I was not aware that upstream openswan was dead, so I guess I have to wait for the libreswan packages to arrive and then adapt my script! |
|
thank for zhangping. |
|
I've got the same problem. |
|
In the @zhangping's config, the real part which make it works is he merge two while his is: As @fortiko pointed out, the only different in the log is: 12.04 14.04: Don't know why it receiverd Delete SA after transport mode is established, and didn't try the Can someone explain for me? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
i have install xl2tp over openswan in ubuntu 12.04_amd64 LTS, and it is runing. The last week ubuntu 14.04_amd64 LTS was released, so i try to install xl2tp over openswan in ubuntu 14.04.
The install way is same as what i did in ubuntu 12.04 LTS. But it cannot running. The difference between them maybe is the following:
(1) the kernel version( kernel 3.8.0-29 vis kernel 3.13.0-24)
(2) the openswan version( openswan 2.6.37 on ubuntu 12.04, and openswan 2.6.38 on ubuntu 14.04)
anybody can help me resolve this problem?
the attachment is following:
(1)/var/log/auth.log
(2)the packets catched be wireshake
(3) the configuration of openswan and xl2tpd
# /etc/ipsec.conf - Openswan IPsec configuration file # This file: /usr/share/doc/openswan/ipsec.conf-sample # # Manual: ipsec.conf.5 version 2.0 # conforms to second version of ipsec.conf specification # basic configuration config setup # Do not set debug options to debug configuration issues! # plutodebug / klipsdebug = "all", "none" or a combation from below: # "raw crypt parsing emitting control klips pfkey natt x509 dpd private" # eg: # plutodebug="control parsing" # Again: only enable plutodebug or klipsdebug when asked by a developer # # enable to get logs per-peer # plutoopts="--perpeerlog" # # Enable core dumps (might require system changes, like ulimit -C) # This is required for abrtd to work properly # Note: incorrect SElinux policies might prevent pluto writing the core dumpdir=/var/run/pluto/ # # NAT-TRAVERSAL support, see README.NAT-Traversal nat_traversal=yes # exclude networks used on server side by adding %v4:!a.b.c.0/24 # It seems that T-Mobile in the US and Rogers/Fido in Canada are # using 25/8 as "private" address space on their 3G network. # This range has not been announced via BGP (at least upto 2010-12-21) virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v6:fd00::/8,%v6:fe80::/10 # OE is now off by default. Uncomment and change to on, to enable. oe=off # which IPsec stack to use. auto will try netkey, then klips then mast protostack=netkey # Use this to log to a file, or disable logging on embedded systems (like openwrt) #plutostderrlog=/dev/null # Add connections here # sample VPN connection # for more examples, see /etc/ipsec.d/examples/ #conn sample # # Left security gateway, subnet behind it, nexthop toward right. # left=10.0.0.1 # leftsubnet=172.16.0.0/24 # leftnexthop=10.22.33.44 # # Right security gateway, subnet behind it, nexthop toward left. # right=10.12.12.1 # rightsubnet=192.168.0.0/24 # rightnexthop=10.101.102.103 # # To authorize this connection, but not actually start it, # # at startup, uncomment this. # #auto=add conn L2TP-PSK-NAT rightsubnet=vhost:%priv also=L2TP-PSK-noNAT conn L2TP-PSK-noNAT authby=secret pfs=no auto=add keyingtries=3 # we cannot rekey for %any, let client rekey rekey=no # Apple iOS doesn't send delete notify so we need dead peer detection # to detect vanishing clients dpddelay=10 dpdtimeout=90 dpdaction=clear # Set ikelifetime and keylife to same defaults windows has ikelifetime=8h keylife=1h # l2tp-over-ipsec is transport mode type=transport # left=162.243.136.115 # # For updated Windows 2000/XP clients, # to support old clients as well, use leftprotoport=17/%any leftprotoport=17/1701 # # The remote user. # right=%any # Using the magic port of "%any" means "any one single port". This is # a work around required for Apple OSX clients that use a randomly # high port. rightprotoport=17/%any conn passthrough-for-non-l2tp type=passthrough left=162.243.136.115 leftnexthop=162.243.136.115 right=0.0.0.0 rightsubnet=0.0.0.0/0 auto=routeThe text was updated successfully, but these errors were encountered: