Problems with pf, ipsec nat-t, l2tp

["Alex Barclay" <alex%planet-barclay.com@localhost>]

Hi all

I'm having some difficulty configuring IPSec NAT-T l2tp from a Mac
(client) to NetBSD (server). It's probably a case of 90% there, 90% to go.

So far I've got through the ISAKMP setup, NAT-T has been determined and
the Mac is now starting to send the l2tp initialization. I'm unsure as to
whether pf is getting in the way but I've turned logging on and I'm not
seeing any packets being dropped.

Here's an example of the first ESP packet that I've captured:
No.     Time        Source                Destination           Protocol Info
   196 167.014042  208.54.14.60          69.17.115.243         L2TP    
Control Message - SCCRQ    (tunnel id=0, session id=0)

Frame 196 (158 bytes on wire, 158 bytes captured)
Ethernet II, Src: Unispher_40:a2:a2 (00:90:1a:40:a2:a2), Dst:
Runtop_1e:69:fe (00:20:78:1e:69:fe)
Internet Protocol, Src: 208.54.14.60 (208.54.14.60), Dst: 69.17.115.243
(69.17.115.243)
User Datagram Protocol, Src Port: 60627 (60627), Dst Port: ipsec-nat-t (4500)
   Source port: 60627 (60627)
   Destination port: ipsec-nat-t (4500)
   Length: 124
   Checksum: 0x0000 (none)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
   ESP SPI: 0x0add84da
   ESP Sequence: 1
   ESP IV: 7DF84D5AE7ED38C8F1EC0A7D158BA730
   Pad
   ESP Pad Length: 10
   Next header: UDP (0x11)
   Authentication Data [correct]
User Datagram Protocol, Src Port: 52412 (52412), Dst Port: l2f (1701)
   Source port: 52412 (52412)
   Destination port: l2f (1701)
   Length: 68
   Checksum: 0x76c1 [incorrect, should be 0xcaf3 (maybe caused by "UDP
checksum offload"?)]
Layer 2 Tunneling Protocol
   Packet Type: Control Message Tunnel Id=0 Session Id=0
   Length: 60
   Tunnel ID: 0
   Session ID: 0
   Ns: 0
   Nr: 0
   Control Message AVP
   Protocol Version AVP
   Framing Capabilities AVP
   Host Name AVP
   Assigned Tunnel ID AVP
   Receive Window Size AVP


This packet was decrypted in wireshark. It is, however, failing to show up
in userland in the l2tp daemon.

Does anyone have any idea where it may be being dropped? Does the packet
get resubmitted to pf or does it bypass that on the resubmission? Anyone
see anything obvious or are there gotchas using pf with this setup (pf may
also be a red herring here)?

Here's a fragment from my pf.conf
pass in quick inet proto udp from any to any port 500 keep state
pass out quick inet proto udp from any port 500 to any keep state
pass in quick inet proto udp from any to any port 4500 keep state
pass out quick inet proto udp from any port 4500 to any keep state
pass in quick inet proto udp from any to any port 1701 keep state
pass out quick inet proto udp from any port 1701 to any keep state
pass in quick inet proto esp from any to any
pass out quick inet proto esp from any to any


I can tell from some judicious print statements in my kernel that it's
been detected as NAT-T and I'll continue to see if I can find out why it's
being dropped.

Thanks - I'm sure there's a lot of needed information left out just ask.

Alex.