Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Dec 2013 23:51:41 +0100 (CET)
From:      Jimmy Olgeni <olgeni@olgeni.com>
To:        freebsd-questions@FreeBSD.org
Cc:        freebsd-net@FreeBSD.org
Subject:   ipsec packets apparently not getting to destination
Message-ID:  <alpine.BSF.2.00.1312032330100.87957@olgeni.olgeni>

next in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1312032330100.87957>