[Openswan Users] openswan 2.6.35rc1 and xl2tpd-1.3.0rc1 pre-releases - please test
Curu Wong
prinbra at gmail.com
Thu Jul 28 04:13:04 EDT 2011
Now I am testing ipsec/l2tp with the server itself behind NAT. here's the
new network topology:
clientA(192.168.9.106)----->clientGWA(A.111.111.111)-------->Server
GW(S.111.111.111)------>l2tp/ipsec GW(192.168.11.19)
the l2tp/ipsec GW only have one internal interface eth1:192.168.11.19(eth0
is disabled)
and here's my ipsec.conf
==============================================
config setup
dumpdir=/var/run/pluto/
nat_traversal=yes
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,%v4:!192.168.6.0/24
oe=off
protostack=mast
conn l2tp-ipsec
left=192.168.11.19
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
rightsubnet=vhost:%no,%priv
pfs=no
rekey=no
sareftrack=yes
overlapip=yes
dpddelay=30
dpdtimeout=120
dpdaction=clear
type=transport
authby=secret
auto=add
===============================================
/etc/ipsec.secrets
============================================
192.168.11.19 %any : PSK "test"
============================================
shorewall rule for NAT
================================================================
DNAT net loc:192.168.11.19 udp
ipsec-nat-t - S.111.111.111
DNAT net loc:192.168.11.19 udp
isakmp - S.111.111.111
=================================================================
with this setup, clientA can connect, I can see that ipsec tunnel is up
========================================================
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: ignoring
Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: received
Vendor ID payload [RFC 3947] method set to=109
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already
using method 109
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: ignoring
Vendor ID payload [FRAGMENTATION]
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: ignoring
Vendor ID payload [MS-Negotiation Discovery Capable]
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: ignoring
Vendor ID payload [Vid-Initial-Contact]
Jul 28 15:16:48 tvpn pluto[3311]: packet from A.111.111.111:500: ignoring
Vendor ID payload [IKE CGA version 1]
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
responding to Main Mode from unknown peer A.111.111.111
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
OAKLEY_GROUP 20 not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
OAKLEY_GROUP 19 not supported. Attribute OAKLEY_GROUP_DESCRIPTION
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
STATE_MAIN_R1: sent MR1, expecting MI2
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1:
STATE_MAIN_R2: sent MR2, expecting MI3
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1: Main
mode peer ID is ID_IPV4_ADDR: '192.168.9.106'
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[1] A.111.111.111 #1: switched
from "l2tp-ipsec" to "l2tp-ipsec"
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1: deleting
connection "l2tp-ipsec" instance with peer A.111.111.111
{isakmp=#0/ipsec=#0}
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1: new NAT
mapping for #1, was A.111.111.111:500, now A.111.111.111:4500
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=aes_256 prf=oakley_
sha group=modp2048}
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1: Dead
Peer Detection (RFC 3706): not enabled because peer did not advertise it
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1: the peer
proposed: S.111.111.111/32:17/1701 -> 192.168.9.106/32:17/0
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1:
NAT-Traversal: received 2 NAT-OA. using first, ignoring others
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2:
responding to Quick Mode proposal {msgid:01000000}
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2: us:
192.168.11.19<192.168.11.19>[+S=C]:17/1701
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2: them:
A.111.111.111[192.168.9.106,+S=C]:17/1701===192.168.9.106/32
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2: Dead
Peer Detection (RFC 3706): not enabled because peer did not advertise it
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #2:
*STATE_QUICK_R2:
IPsec SA established transport mode {ESP=>0x718743b1 <0x43d05450
xfrm=AES_128-HMAC_SHA1 NATOA=192.168.9.106 NATD=A.111.111.111:4500 DPD=none}
*
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1: the peer
proposed: S.111.111.111/32:17/1701 -> 192.168.9.106/32:17/1701
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #1:
NAT-Traversal: received 2 NAT-OA. using first, ignoring others
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3:
responding to Quick Mode proposal {msgid:02000000}
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3: us:
192.168.11.19<192.168.11.19>[+S=C]:17/1701
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3: them:
A.111.111.111[192.168.9.106,+S=C]:17/1701===192.168.9.106/32
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3: keeping
refhim=1 during rekey
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul 28 15:16:48 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jul 28 15:16:49 tvpn pluto[3311]: "l2tp-ipsec"[2] A.111.111.111 #3: Dead
Peer Detection (RFC 3706): not enabled because peer did not advertise it
==================================================================
but, there's nothing happen to xl2tpd. the log just stops at this line:
======================================================
Jul 28 14:38:13 tvpn xl2tpd[1660]: Listening on IP address 0.0.0.0, port
1701
======================================================
seems client never contact the xl2tpd.
rp_filter, ip_forward are all setup correctly, I just don't know why.
also, tcpdump on mast0 shows no traffic.
2011/7/23 Paul Wouters <paul at xelerance.com>
> On Sat, 23 Jul 2011, Curu Wong wrote:
>
> Thanks for the feedback Curu!
>
>
> I used to setup l2tp-ipsec tunnels using x509, and I thought that with
>> PSK, only one connection can up at the same time, so I used two connection
>> xl2tp-gw1 and xl2tp-gw2 for
>> test. In fact, I was wondering, if we can not use PSK with multiple client
>> at the same time, how can microsoft's vpn server accomplish that?
>>
>
> By having right=%any you can, except that all roadwarriors have to use the
> same PSK. You can work
> around some of that with aggressive mode, but not when you want to use
> l2tp.
>
>
> But I have a suggestion, can we add the check of rp_filter to "ipsec
>> verify" when running with klips/mast stack? Because that may help some
>> newbies who can't/doesn't find a
>> proper doc/guide for their initial config.
>>
>
> Yes, I'll add it. We used to just change it and therefor not bug the user,
> but I
> think we might only do that for ipsecX and not mastX.
>
>
> the l2tp/ipsec gateway's internal IP 192.168.6.18 is not involved here!
>> Then I change /etc/xl2tpd/xl2tpd.conf on centos, set
>> listen-addr = S.S.S.S
>> restart xl2tpd, then everything works fine, just like the ubuntu one.
>>
>
> Yeah, that's a bug in xl2tpd. It is not properly using the HAVE_UDPFROMTO
> code like openswan does, so it is not
> using the source ip it received the packet on for reply packets when bound
> to ANY.
>
>
> One more thing, no matter with ubuntu or CentOS, there's always this
>> error message whenever ipsec service restarted
>> I don't know if it matters:
>> ==============================**======================
>> Jul 23 11:27:34 tvpn pluto[13271]: ERROR: PF_KEY K_SADB_X_PLUMBIF response
>> for configure_mast_device included errno 17: File exists
>>
>
> We should probably suppress that error. It just means there is a mast0
> interface already.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110728/62fdb266/attachment-0001.html
More information about the Users
mailing list