> From: YASUOKA Masahiko
> Sent: Wednesday, February 26, 2014 8:46 PM
> "set skip on pppx0" needs to be improved because npppd may use pppx1,
> pppx2 ...
Once I've got things working, I'm probably going to want to have more
explicit rules rather than skipping; if I understand correctly I can just
use the generic interface group pppx rather than a specific instance so it
won't matter which one a given VPN connection is using.
> sysctl net.pipex.enable=1
Hmm, yeah, that... I had updated my /etc/sysctl.conf with that change, but
the system had not been rebooted since I did that; and it does appear I
forgot to run it by hand 8-/. I could have sworn I manually tweaked it when
I updated the config, but when I double checked, it was not set, so clearly
I did not <sigh>. After enabling that setting, I can ping the client from
the server and vice versa, yay! It looks like ospfd isn't propagating the
route for the VPN addresses, so I can't talk to anything past the router,
presumably I need to update that config next.
> > For this rule "pass quick proto { esp, ah } from any to any", does it
really
> > need to be any to any with no interface defined?
>
> I think it is required only from/to the listening address of L2TP.
Cool. Now that it's somewhat working I will go back and clean that up.
> In L2TP/IPsec, "transport mode" IPsec is used instead of tunnel mode.
> This means enc(4) is not used. And de-capsulated L2TP packets are
> received on the same interface which receives IPsec packet.
Hmm, that's not what I'm seeing. On the regular WAN interface (em1), when a
connection is established, I see some initial isakmp packets, and after
that, the only packets on that interface are the esp protocol:
12:23:29.614487 host-134-71-203-161.allocated.csupomona.edu.isakmp >
bart.pbhware.com.isak
mp: isakmp v1.0 exchange ID_PROT
cookie: 3d028e2c298bc357->0000000000000000 msgid: 00000000 len: 500
12:23:29.614490 host-134-71-203-161.allocated.csupomona.edu.isakmp >
bart.pbhware.com.isak
mp: isakmp v1.0 exchange ID_PROT
cookie: 3d028e2c298bc357->0000000000000000 msgid: 00000000 len: 500
[...]
mp: isakmp v1.0 exchange QUICK_MODE encrypted
cookie: 3d028e2c298bc357->d01b5baa5e938551 msgid: 080e9e87 len: 60
12:23:30.696974 host-134-71-203-161.allocated.csupomona.edu.isakmp >
bart.pbhware.com.isak
mp: isakmp v1.0 exchange QUICK_MODE encrypted
cookie: 3d028e2c298bc357->d01b5baa5e938551 msgid: 080e9e87 len: 60
12:23:30.697094 esp host-134-71-203-161.allocated.csupomona.edu >
bart.pbhware.com spi 0x9
81e7ad1 seq 1 len 116
12:23:30.697096 esp host-134-71-203-161.allocated.csupomona.edu >
bart.pbhware.com spi 0x9
81e7ad1 seq 1 len 116
And on the enc0 interface, I do see traffic, in particular what appears to
be the l2tp communication:
12:23:31.599555 (authentic,confidential): SPI 0x981e7ad1:
host-134-71-203-161.allocated.cs
upomona.edu.63807 > bart.pbhware.com.l2tp: l2tp:[TLS](0/0)Ns=0,Nr=0
*MSGTYPE(SCCRQ) *PROTO
_VER(1.0) *FRAMING_CAP(AS) *HOST_NAME(Dogbert) *ASSND_TUN_ID(15)
*RECV_WIN_SIZE(4) [|l2tp]
12:23:31.599714 (authentic,confidential): SPI 0x0173ea42:
bart.pbhware.com.l2tp > host-134
-71-203-161.allocated.csupomona.edu.63807: l2tp:[TLS](15/0)Ns=0,Nr=1
*MSGTYPE(SCCRP) *PROT
O_VER(1.0) *FRAMING_CAP(S) *HOST_NAME(bart.pbhware.com) *ASSND_TUN_ID(1)
FIRM_VER(1282) |.
..[|l2tp]
12:23:31.622116 (authentic,confidential): SPI 0x981e7ad1:
host-134-71-203-161.allocated.cs
upomona.edu.63807 > bart.pbhware.com.l2tp: l2tp:[TLS](1/0)Ns=1,Nr=1
*MSGTYPE(SCCCN) [|l2tp
]
12:23:31.622181 (authentic,confidential): SPI 0x0173ea42:
bart.pbhware.com.l2tp > host-134
-71-203-161.allocated.csupomona.edu.63807: l2tp:[TLS](15/0)Ns=1,Nr=2
ZLB[|l2tp]
12:23:31.624720 (authentic,confidential): SPI 0x981e7ad1:
host-134-71-203-161.allocated.cs
upomona.edu.63807 > bart.pbhware.com.l2tp: l2tp:[TLS](1/0)Ns=2,Nr=1
*MSGTYPE(ICRQ) *ASSND_
SESS_ID(4051) *CALL_SER_NUM(1) [|l2tp]
For the purpose of writing pf rules, I'd like to understand exactly what
interfaces the packets are traversing. It looks like initially there are
isakmp packets from the remote client to the server on the external WAN
interface, followed by encapsulated esp packets. At that point, it looks
like the packets are flowing through the enc0 interface, from the remote
client to the l2tp server. Once that tunnel is established, it looks like
the tunneled packets flow through the pppx0 interface. So from a firewall
perspective, I think I just need a minimal set of rules on the WAN interface
and the enc0 interface to allow the l2tp tunnel to get established, and then
restrict the actual VPN traffic on the pppx interfaces.
Thanks much for helping point out my obvious mistake with pipex :). I wish I
would have thought to double check that yesterday when I was beating my head
against the wall trying to figure out why it wasn't working...
