[Openswan Users] l2tp answers unencrypted
Ritter, Daniel
daniel.ritter at block-systems.de
Mon May 26 12:54:24 EDT 2008
Hello,
we try to establish 2 concurrent connections from windows clients behind
a nat to our vpn-server.
All goes well... the tunnel gets established, some l2tp packets are
arriving over the tunnel and the l2tpd answers.
But the answer from the l2tpd goes unencryted over the network interface
and NOT over the ipsec0 interface.
What are we do wrong?
Thanks for your help...
Daniel Ritter
OS: Centos 5.1 with kernel 2.6.18 (self compiled, including NAT-T patch)
Openswan 2.5.17
[root at BG00-VPN03 src]# ipsec verify
Checking your system to see if IPsec got installed and started
correctly:
Version check and ipsec on-path [OK]
Linux Openswan 2.5.17 (klips)
Checking for IPsec support in kernel [OK]
KLIPS detected, checking for NAT Traversal support [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing
Checking tun0x1001 at 213.144.XXX.XXX from 10.10.0.48/29 to
172.27.65.57/32Checking for 'ip' command
[OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption DNS checks:
Looking for TXT in forward dns zone: BG00-VPN03
[MISSING]
Does the machine have at least one non-private address? [OK]
Looking for TXT in reverse dns zone: XXX.XXX.159.193.in-addr.arpa.
[MISSING]
***********************************************************
This is our ipsec.conf:
***********************************************************
# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual: ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
interfaces="ipsec0=eth1"
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:
!10.40.0.0/24
OE=off
protostack=klips
conn client-xp
left= 193.159.XXX.YYY
leftprotoport= 17/1701
right= %any
rightsubnet= vhost:%no,%priv
rightprotoport= 17/1701
pfs= no
auto= route
authby= secret
type= transport
***********************************************************
Connection log
***********************************************************
May 26 08:49:09 BG00-VPN03 pluto[4720]: packet from 84.142.YYY.ZZZ:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
May 26 08:49:09 BG00-VPN03 pluto[4720]: packet from 84.142.YYY.ZZZ:500:
ignoring Vendor ID payload [FRAGMENTATION]
May 26 08:49:09 BG00-VPN03 pluto[4720]: packet from 84.142.YYY.ZZZ:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
to=106
May 26 08:49:09 BG00-VPN03 pluto[4720]: packet from 84.142.YYY.ZZZ:500:
ignoring Vendor ID payload [Vid-Initial-Contact]
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: responding to Main Mode from unknown peer 84.142.YYY.ZZZ
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: STATE_MAIN_R1: sent MR1, expecting MI2
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer
is NATed
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: STATE_MAIN_R2: sent MR2, expecting MI3
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: Main mode peer ID is ID_FQDN: '@wks-se-test01.BLOCK-Gruppe.de'
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[1] 84.142.YYY.ZZZ
#4: switched from "client-xp" to "client-xp"
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: deleting connection "client-xp" instance with peer 84.142.YYY.ZZZ
{isakmp=#0/ipsec=#0}
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
May 26 08:49:09 BG00-VPN03 pluto[4720]: "servit-seeburger1" #1: new NAT
mapping for #1, was 213.144.25.3:500, now 84.142.YYY.ZZZ:4500
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: new NAT mapping for #4, was 84.142.YYY.ZZZ:500, now
84.142.YYY.ZZZ:4500
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp2048}
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: peer client type is FQDN
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: Applying workaround for MS-818043 NAT-T bug
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: IDci was FQDN: \301\237\257\270, using NAT_OA=192.168.1.219/32 as
IDci
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#4: the peer proposed: 193.159.XXX.YYY/32:17/1701 ->
192.168.1.219/32:17/1701
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#5: responding to Quick Mode {msgid:64249f6c}
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#5: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
May 26 08:49:09 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#5: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
May 26 08:49:10 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#5: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
May 26 08:49:10 BG00-VPN03 pluto[4720]: "client-xp"[2] 84.142.YYY.ZZZ
#5: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x53711541
<0x78b20028 xfrm=3DES_0-HMAC_MD5 NATD=84.142.YYY.ZZZ:4500 DPD=none}
***********************************************************
tcpdump of ipsec0
***********************************************************
[root at BG00-VPN03 src]# tcpdump -nn -i ipsec0
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on ipsec0, link-type EN10MB (Ethernet), capture size 96 bytes
08:50:57.473608 IP 84.142.YYY.ZZZ.1701 > 193.159.XXX.YYY.1701:
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
*BEARER_CAP() |...
08:50:58.448842 IP 84.142.YYY.ZZZ.1701 > 193.159.XXX.YYY.1701:
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
*BEARER_CAP() |...
08:51:00.438896 IP 84.142.YYY.ZZZ.1701 > 193.159.XXX.YYY.1701:
l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S)
*BEARER_CAP() |...
***********************************************************
tcpdump of eth1
***********************************************************
08:52:25.250723 IP 84.142.YYY.ZZZ.500 > 193.159.XXX.YYY.500: isakmp:
phase 1 I ident
08:52:25.252348 IP 193.159.XXX.YYY.500 > 84.142.YYY.ZZZ.500: isakmp:
phase 1 R ident
08:52:25.669288 IP 84.142.YYY.ZZZ.500 > 193.159.XXX.YYY.500: isakmp:
phase 1 I ident
08:52:25.683199 IP 193.159.XXX.YYY.500 > 84.142.YYY.ZZZ.500: isakmp:
phase 1 R ident
08:52:25.847035 IP 84.142.YYY.ZZZ.4500 > 193.159.XXX.YYY.4500:
NONESP-encap: isakmp: phase 1 I ident[E]
08:52:25.848270 IP 193.159.XXX.YYY.4500 > 84.142.YYY.ZZZ.4500:
NONESP-encap: isakmp: phase 1 R ident[E]
08:52:25.930708 IP 84.142.YYY.ZZZ.4500 > 193.159.XXX.YYY.4500:
NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
08:52:25.933527 IP 193.159.XXX.YYY.4500 > 84.142.YYY.ZZZ.4500:
NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
08:52:25.995459 IP 84.142.YYY.ZZZ.4500 > 193.159.XXX.YYY.4500:
NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
08:52:26.009172 IP 84.142.YYY.ZZZ.4500 > 193.159.XXX.YYY.4500:
UDP-encap: ESP(spi=0x78b2002a,seq=0x1), length 164
08:52:26.019773 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
08:52:26.088270 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 135
08:52:27.000766 IP 84.142.YYY.ZZZ.4500 > 193.159.XXX.YYY.4500:
UDP-encap: ESP(spi=0x78b2002a,seq=0x2), length 164
08:52:27.003163 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 ZLB
08:52:27.039011 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
08:52:27.098226 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 48
08:52:27.215606 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 135
08:52:28.050686 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
08:52:28.154976 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 135
08:52:29.054503 IP 84.142.YYY.ZZZ.4500 > 193.159.XXX.YYY.4500:
UDP-encap: ESP(spi=0x78b2002a,seq=0x3), length 164
08:52:29.056787 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 ZLB
08:52:29.056966 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
08:52:29.218165 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 48
08:52:29.218311 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 135
08:52:30.073553 IP 193.159.XXX.YYY.1701 > 84.142.YYY.ZZZ.1701:
l2tp:[TLS](27/0)Ns=0,Nr=1 *MSGTYPE(SCCRP) *PROTO_VER(1.0)
*FRAMING_CAP(AS) *BEARER_CAP() |...
08:52:30.246431 IP 84.142.YYY.ZZZ > 193.159.XXX.YYY: ICMP 84.142.YYY.ZZZ
udp port 1701 unreachable, length 135
0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080526/ab5fd393/attachment-0001.html
More information about the Users
mailing list