ipsec packets apparently not getting to destination
Jimmy Olgeni
olgeni at olgeni.com
Tue Dec 3 22:51:44 UTC 2013
Hello,
I'm trying to setup a VPN server using L2TP/IPSEC, racoon (from
ipsec-tools) and mpd5, with certificates (to avoid patching racoon for
handling wildcard PSKs). PF disabled for testing, no other firewall is
active, no NAT on the server, NAT on the client using server port 4500.
Server is running 9.2-RELEASE r256712, with this config appended to
GENERIC:
device crypto # core crypto support
device cryptodev # /dev/crypto for access to h/w
device enc # IPsec interface.
options IPSEC # IP security (requires device crypto)
options IPSEC_NAT_T # NAT-T support, UDP encap of ESP
options IPSEC_FILTERTUNNEL # filter ipsec packets from a tunnel
(plus other unrelated things, ALTQ, SW_WATCHDOG, DDB, TEKEN_UTF8).
After tens of tests I got to this point...
If I disable ipsec on the Windows 8 client, the L2TP tunnel comes up
perfectly. A sample PPTP tunnel (unrelated) also works fine. I take it as
proof that mpd5 is configured in a more or less sensible manner.
My /etc/ipsec.conf looks like this:
flush;
spdflush;
spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec esp/transport//require;
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require;
Which translates to this at runtime:
0.0.0.0/0[1701] 0.0.0.0/0[any] udp
in ipsec
esp/transport//require
spid=58 seq=1 pid=43822
refcnt=1
0.0.0.0/0[any] 0.0.0.0/0[1701] udp
out ipsec
esp/transport//require
spid=57 seq=0 pid=43822
refcnt=1
When connecting with L2TP/IPSEC from the Windows client, racoon shows this
output:
(C.C.C.C -> NAT address before Windows client, S.S.S.S -> public address of L2TP server)
2013-12-03 23:10:03: INFO: respond new phase 1 negotiation: S.S.S.S[500]<=>C.C.C.C[49216]
2013-12-03 23:10:03: INFO: begin Identity Protection mode.
2013-12-03 23:10:03: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2013-12-03 23:10:03: INFO: received Vendor ID: RFC 3947
2013-12-03 23:10:03: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2013-12-03 23:10:03: INFO: received Vendor ID: FRAGMENTATION
2013-12-03 23:10:03: [C.C.C.C] INFO: Selected NAT-T version: RFC 3947
2013-12-03 23:10:03: ERROR: invalid DH group 20.
2013-12-03 23:10:03: ERROR: invalid DH group 19.
2013-12-03 23:10:03: [S.S.S.S] INFO: Hashing S.S.S.S[500] with algo #2
2013-12-03 23:10:03: INFO: NAT-D payload #0 verified
2013-12-03 23:10:03: [C.C.C.C] INFO: Hashing C.C.C.C[49216] with algo #2
2013-12-03 23:10:03: INFO: NAT-D payload #1 doesn't match
2013-12-03 23:10:03: INFO: NAT detected: PEER
2013-12-03 23:10:03: [C.C.C.C] INFO: Hashing C.C.C.C[49216] with algo #2
2013-12-03 23:10:03: [S.S.S.S] INFO: Hashing S.S.S.S[500] with algo #2
2013-12-03 23:10:03: INFO: Adding remote and local NAT-D payloads.
2013-12-03 23:10:03: INFO: NAT-T: ports changed to: C.C.C.C[4500]<->S.S.S.S[4500]
2013-12-03 23:10:03: INFO: KA found: S.S.S.S[4500]->C.C.C.C[4500] (in_use=2)
2013-12-03 23:10:03: WARNING: unable to get certificate CRL(3) at depth:0 SubjectName:/C=IT/ST=Lombardia/L=Milano/O=MovieReading/CN=LiveSub Client
2013-12-03 23:10:03: WARNING: unable to get certificate CRL(3) at depth:1 SubjectName:/C=IT/ST=Lombardia/O=MovieReading/CN=ROOT CA
2013-12-03 23:10:03: INFO: ISAKMP-SA established S.S.S.S[4500]-C.C.C.C[4500] spi:077c160ee905cf2e:062d1918ab2b788f
2013-12-03 23:10:03: INFO: respond new phase 2 negotiation: S.S.S.S[4500]<=>C.C.C.C[4500]
2013-12-03 23:10:03: INFO: Adjusting my encmode UDP-Transport->Transport
2013-12-03 23:10:03: INFO: Adjusting peer's encmode UDP-Transport(4)->Transport(2)
2013-12-03 23:10:03: INFO: IPsec-SA established: ESP/Transport S.S.S.S[500]->C.C.C.C[500] spi=225553014(0xd71aa76)
2013-12-03 23:10:03: INFO: IPsec-SA established: ESP/Transport S.S.S.S[500]->C.C.C.C[500] spi=2749046390(0xa3db1e76)
CRL aside, which is not configured right now, certificate handling looks
ok. Client side NAT also looks good.
Also, tcpdump on enc0 shows the relevant packets coming through IPSEC:
tcpdump: WARNING: enc0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 65535 bytes
23:10:03.521573 (authentic,confidential): SPI 0x0d71aa76: IP client.dialup.tiscali.it.l2f > olgeni.olgeni.com.l2f: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() FIRM_VER(1539) *HOST_NAME(moviereading) VENDOR_NAME(Microsoft) *ASSND_TUN_ID(16) *RECV_WIN_SIZE(8)
23:10:04.513077 (authentic,confidential): SPI 0x0d71aa76: IP client.dialup.tiscali.it.l2f > olgeni.olgeni.com.l2f: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() FIRM_VER(1539) *HOST_NAME(moviereading) VENDOR_NAME(Microsoft) *ASSND_TUN_ID(16) *RECV_WIN_SIZE(8)
Now, the really weird part is that mpd5 does not even see the packets
addressed to the l2f (1701) port.
I tried to bind mpd5 both to S.S.S.S and to 0.0.0.0, but nothing
changed.
Also, if I run "socat UDP-LISTEN:1701 STDOUT" in place of mpd5, *nothing*
comes through, even if the dump on enc0 shows that something is coming in.
Running "setkey -D" shows this:
S.S.S.S C.C.C.C
esp mode=transport spi=3417968112(0xcbba0df0) reqid=0(0x00000000)
E: rijndael-cbc 65260e8e fd0d9dbf 8aa363d8 7cc81f41 2eb89aff d6984fb9 b7bdfc56 50774e0a
A: hmac-sha1 fd5e6716 fe7e2c57 fc1f42b9 ec5307ab dae3ea6f
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 3 23:24:16 2013 current: Dec 3 23:24:29 2013
diff: 13(s) hard: 3600(s) soft: 2880(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=43884 refcnt=1
C.C.C.C S.S.S.S
esp mode=transport spi=253016163(0x0f14b863) reqid=0(0x00000000)
E: rijndael-cbc 1463f10b 87e52b9b 9d32ee04 350198ae 6779d06d 3f57389b 71bffd18 72211b36
A: hmac-sha1 1037b02e 7ec2cf51 50351bb6 cf8ab693 25d87e0a
seq=0x00000004 replay=4 flags=0x00000000 state=mature
created: Dec 3 23:24:16 2013 current: Dec 3 23:24:29 2013
diff: 13(s) hard: 3600(s) soft: 2880(s)
last: Dec 3 23:24:23 2013 hard: 0(s) soft: 0(s)
current: 532(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 4 hard: 0 soft: 0
sadb_seq=0 pid=43884 refcnt=1
I cannot imagine any obvious reason for packets getting "lost" after enc0,
so any hint would be much appreciated :)
--
jimmy
More information about the freebsd-questions
mailing list