From owner-freebsd-net@FreeBSD.ORG Wed Dec 4 12:52:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA4AA4A for ; Wed, 4 Dec 2013 12:52:11 +0000 (UTC) Received: from smtp-out.dnepro.net (mail.dnepro.net [178.219.93.41]) by mx1.freebsd.org (Postfix) with ESMTP id 629701E98 for ; Wed, 4 Dec 2013 12:52:10 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id rB4CLGlL010929 for ; Wed, 4 Dec 2013 14:21:16 +0200 (EET) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id rB4CLGfw010927 for freebsd-net@freebsd.org; Wed, 4 Dec 2013 14:21:16 +0200 (EET) (envelope-from john) Date: Wed, 4 Dec 2013 14:21:16 +0200 From: Eugene Perevyazko To: freebsd-net@freebsd.org Subject: Re: ipsec packets apparently not getting to destination Message-ID: <20131204122115.GA46835@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (traktor.dnepro.net [127.0.0.1]); Wed, 04 Dec 2013 14:21:16 +0200 (EET) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:52:11 -0000 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