Re: L2TP VPN / pf
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- msgid: 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- msgid: 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...
Re: L2TP VPN / pf
On Thu, 27 Feb 2014 13:51:10 -0800 Paul B. Henson hen...@acm.org wrote: From: YASUOKA Masahiko Sent: Wednesday, February 26, 2014 8:46 PM 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. I'm glad to hear that. 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: You're right. I was confused, sorry. 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. Exactly. 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... Not at all. I'll fix npppd to warn in the log when the pipex sysctl is not set. --yasuoka
Re: L2TP VPN / pf
From: YASUOKA Masahiko Sent: Thursday, February 27, 2014 5:44 PM 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: You're right. I was confused, sorry. When I shut down the VPN client, it does look like there are some non-encapsulated packets coming from the client to the l2tp port on the WAN interface: 17:52:50.434908 esp bart.pbhware.com host-134-71-203-251.allocated.csupomona.edu spi 0x0 d875c54 seq 23 len 68 17:52:50.512023 host-134-71-203-251.allocated.csupomona.edu.isakmp bart.pbhware.com.isak mp: isakmp v1.0 exchange INFO encrypted cookie: 5eaec242bc98f28f-83a0e65155bcbcf8 msgid: c52320cb len: 76 17:52:50.512028 host-134-71-203-251.allocated.csupomona.edu.isakmp bart.pbhware.com.isakmp: isakmp v1.0 exchange INFO encrypted cookie: 5eaec242bc98f28f-83a0e65155bcbcf8 msgid: c52320cb len: 76 17:52:50.512030 host-134-71-203-251.allocated.csupomona.edu.isakmp bart.pbhware.com.isak mp: isakmp v1.0 exchange INFO encrypted cookie: 5eaec242bc98f28f-83a0e65155bcbcf8 msgid: 64cf721d len: 92 17:52:50.512032 host-134-71-203-251.allocated.csupomona.edu.isakmp bart.pbhware.com.isakmp: isakmp v1.0 exchange INFO encrypted cookie: 5eaec242bc98f28f-83a0e65155bcbcf8 msgid: 64cf721d len: 92 17:52:50.961996 host-134-71-203-251.allocated.csupomona.edu.62139 bart.pbhware.com.l2tp: l2tp:[TLS](6/24262)Ns=4,Nr=2 *MSGTYPE(CDN) *ASSND_SESS_ID(4330) *RESULT_CODE(768/0 ) [|l2tp] 17:52:50.962000 host-134-71-203-251.allocated.csupomona.edu.62139 bart.pbhware.com.l2tp: l2tp:[TLS](6/24262)Ns=4,Nr=2 *MSGTYPE(CDN) *ASSND_SESS_ID(4330) *RESULT_CODE(768/0 ) [|l2 They result in warnings from npppd though: 2014-02-27 17:52:50:INFO: l2tpd Received from=134.71.203.251:62139: bad control message: tunnelId=6 is not found. mestype=CDN 2014-02-27 17:52:52:INFO: l2tpd Received from=134.71.203.251:62139: bad control message: tunnelId=6 is not found. mestype=CDN So they're clearly not important. The client I'm testing right now is an iPhone, maybe it's a bug on that side. Not at all. I'll fix npppd to warn in the log when the pipex sysctl is not set. Yeah, that's a great idea. I was running in debug mode, and it logged: 2014-02-27 17:37:44:NOTICE: ppp id=0 layer=base Using pipex=yes If there would have been a warning right next to it that pipex was disabled that would've been quite helpful in pointing out the forgotten step.
L2TP VPN / pf
I'm trying to get a L2TP VPN working using npppd; I think I'm most of the
way there but packets just aren't quite flowing. I'm not sure why, but I
think I might be missing something or misunderstanding something with pf.
I've got ipsec=YES and isakmpd_flags=-K in rc.conf.local, and
/etc/ipsec.conf configured as:
-
ike passive esp transport \
proto udp from 96.251.22.154 to any port 1701 \
psk somesekretkeyhere
-
My /etc/npppd/npppd.conf is:
-
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 96.251.22.154
}
ipcp IPCP {
pool-address 10.128.120.2-10.128.120.254
dns-servers 10.128.0.4
}
interface pppx0 address 10.128.120.1 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0
-
I currently have the following in pf.conf:
-
pass quick proto { esp, ah } from any to any
pass in quick on em1 proto udp from any to 96.251.22.154 port {500, 4500,
1701} keep state
set skip on enc0
set skip on pppx0
-
I'm pretty sure I have the ipsec/npppd pieces correct, as I am successfully
able to connect to the VPN:
-
2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
from=134.71.203.230:644
68/udp tunnel_id=2/6 protocol=1.0 winsize=4 hostname=Dogbert vendor=(no
vendorname) firm=0
000
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 SendSCCRP
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 RecvSCCN
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 SendZLB
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 RecvICRQ session_id=3388
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 SendICRP session_id=21438
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 RecvICCN session_id=3388
calling_number=
tx_conn_speed=100 framing=async
2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 call=21438 logtype=PPPBind ppp=1
2014-02-26 15:35:01:INFO: ppp id=1 layer=base logtype=Started
tunnel=L2TP_ipv4(134.71.203.
230:64468)
2014-02-26 15:35:01:INFO: l2tpd ctrl=2 call=21438 SendZLB
2014-02-26 15:35:04:INFO: ppp id=1 layer=lcp logtype=Opened mru=1360/1360
auth=MS-CHAP-V2
magic=c638067d/52525adf
2014-02-26 15:35:04:INFO: ppp id=1 layer=chap proto=mschap_v2
logtype=Success username=he
nson realm=LOCAL
2014-02-26 15:35:04:INFO: ppp id=1 layer=ipcp IP Address peer=0.0.0.0
our=10.128.120.160.
2014-02-26 15:35:04:INFO: ppp id=1 layer=base unhandled protocol ipv6cp,
32855(8057)
2014-02-26 15:35:04:INFO: ppp id=1 layer=base unhandled protocol acsp,
3(8235)
2014-02-26 15:35:04:INFO: ppp id=1 layer=ccp CCP is stopped
2014-02-26 15:35:04:INFO: ppp id=1 layer=ipcp logtype=Opened
ip=10.128.120.160 assignType=
dynamic
2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base logtype=TUNNELSTART
user=henson duration
=4sec layer2=L2TP_ipv4 layer2from=134.71.203.230:64468 auth=MS-CHAP-V2
ip=10.128.120.160
iface=pppx0
2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base Using pipex=yes
-
However, from the VPN client I cannot ping 10.128.120.1, the server
endpoint, and from the server I cannot ping 10.128.120.160, the client
endpoint. When I try to ping the client, I can see traffic on the ethernet
interface:
16:07:56.431711 esp bart.pbhware.com
host-134-71-203-230.allocated.csupomona.edu spi 0x04e9efec seq 32 len 148
(DF)
16:07:57.441732 esp bart.pbhware.com
host-134-71-203-230.allocated.csupomona.edu spi 0x04e9efec seq 33 len 148
(DF)
16:07:58.451762 esp bart.pbhware.com
host-134-71-203-230.allocated.csupomona.edu spi 0x04e9efec seq 34 len 148
(DF)
And on the enc0 interface:
16:07:52.391543 (authentic,confidential): SPI 0x04e9efec:
bart.pbhware.com.l2tp host-134-71-203-230.allocated.csupomona.edu.51118:
l2tp:[LS](8/3432)Ns=21,Nr=65535[hdlc|][|l2tp]
16:07:53.401575 (authentic,confidential): SPI 0x04e9efec:
bart.pbhware.com.l2tp host-134-71-203-230.allocated.csupomona.edu.51118:
l2tp:[LS](8/3432)Ns=22,Nr=65535[hdlc|][|l2tp]
Conversely, when I try to ping the server from the client:
16:09:42.857872 esp host-134-71-203-230.allocated.csupomona.edu
bart.pbhware.com spi 0x506039f8 seq 96 len 148
16:09:42.857875 esp host-134-71-203-230.allocated.csupomona.edu
bart.pbhware.com spi 0x506039f8 seq 96 len 148
16:09:43.855422 esp host-134-71-203-230.allocated.csupomona.edu
bart.pbhware.com spi 0x506039f8 seq 97 len 148
16:09:43.855454 (authentic,confidential): SPI 0x506039f8:
host-134-71-203-230.allocated.csupomona.edu.51118 bart.pbhware.com.l2tp:
l2tp:[L](1/12490)[hdlc|][|l2tp]
16:09:44.855469 (authentic,confidential): SPI 0x506039f8:
host-134-71-203-230.allocated.csupomona.edu.51118 bart.pbhware.com.l2tp:
l2tp:[L](1/12490)[hdlc|][|l2tp]
16:09:45.855498 (authentic,confidential): SPI 0x506039f8:
host-134-71-203-230.allocated.csupomona.edu.51118 bart.pbhware.com.l2tp:
l2tp:[L](1/12490)[hdlc|][|l2tp]
Ideally, I would like to completely disable pf at this point to confirm that
is the problem, but unfortunately it is a production router and I can't
really do that 8-/.
Am I missing something in either the ipsec, npppd, or pf
Re: L2TP VPN / pf
Hi,
On Wed, 26 Feb 2014 16:32:34 -0800
Paul B. Henson hen...@acm.org wrote:
I currently have the following in pf.conf:
-
pass quick proto { esp, ah } from any to any
pass in quick on em1 proto udp from any to 96.251.22.154 port {500, 4500,
1701} keep state
set skip on enc0
set skip on pppx0
-
set skip on pppx0 needs to be improved because npppd may use pppx1,
or pppx2 ...
I'm pretty sure I have the ipsec/npppd pieces correct, as I am successfully
able to connect to the VPN:
-
2014-02-26 15:35:01:NOTICE: l2tpd ctrl=2 logtype=Started RecvSCCRQ
from=134.71.203.230:644
(snip)
2014-02-26 15:35:04:NOTICE: ppp id=1 layer=base logtype=TUNNELSTART
user=henson duration
=4sec layer2=L2TP_ipv4 layer2from=134.71.203.230:64468 auth=MS-CHAP-V2
ip=10.128.120.160
iface=pppx0
L2TP/IPsec seems to be established successfully. This means your
ipsec.conf, npppd.conf and pf.conf are ok.
However, from the VPN client I cannot ping 10.128.120.1, the server
endpoint, and from the server I cannot ping 10.128.120.160, the client
endpoint. When I try to ping the client, I can see traffic on the ethernet
interface:
(snip)
Am I missing something in either the ipsec, npppd, or pf configuration?
Did you do
sysctl net.pipex.enable=1
? This is required to pass packets through the VPN tunnel.
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.
Wouldn't all of the ipsec traffic be on the WAN interface to/from
the WAN IP? While I think this piece is working, I'd rather have the
rule exactly match what is needed than be extra generic.
Regarding this rule pass in quick on em1 proto udp from any to
96.251.22.154 port {500, 4500, 1701} keep state, it looks like the
connection to the l2tp port is over the ipsec tunnel and hence via enc0, not
em1? So it doesn't seem 1701 needs to be allowed in on this rule, I removed
it and it continued to work, at least as far as successfully connecting but
not passing traffic over the VPN link sigh.
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.
--yasuoka
