ipsec packets apparently not getting to destination
Eugene Perevyazko
john at dnepro.net
Wed Dec 4 12:52:11 UTC 2013
On Tue, Dec 03, 2013 at 11:51:41PM +0100, Jimmy Olgeni wrote:
>
> 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 :)
>
mpd uses netgraph for most if not all processing. Could it be that ipsec-processed packets do not enter corresponding netgraph node?
You can look at the netgraph tree to see where mpd expects to see incoming
packets.
--
Eugene Perevyazko
More information about the freebsd-net
mailing list