Sorry if this arrives more than once?.
I'm encountering a problem in updating to 10.0, and wonder if
anything has changed with respect to the way in which you tell (the
new!) PF code to process stuff coming in via IPSEC -- if, for
example, there's a knob somewhere that say "yes, really, really,
do the NATing on incoming packets that came in on IPSEC and
are going out (decrypted) in the clear." that wasn't required
in previous versions (up to 9.1) of FreeBSD.
I've used Freebsd for a base for IPSEC/L2TP/PPTP/Openvpn VPN servers
for a while now, and been (mostly) happy. I got the shiny new 10.0
bits (updated to 10.0RC5, though the same problem showed in
RC4 and RC3) and have a little problem.
Openvpn-based PF processing works just fine, including natting. I
use my test client to connect, and I'm given a network-10 address.
Traffic flows encrypted to the server, arrives on tun0, gets
appropriately decrypted and NATed, sent out,
responses NATed back the other way, and all is well. A similar
"just fine" thing happens with PPTP via MPD5 and the appropriate
ng interface.
IPSEC based VPN service fails in the following way: I establish a
tunnel-mode IPSEC connection with racoon,
get assigned a proper IP address (call
it 10.x.y.z) range on my client. Then when I try to ping (say)
8.8.8.8, I see the ping emerge on the server's ethernet interface
un-natted (with the proper destination, but an 10.x.y.z source
address). Thus if 8.8.8.8 responds, it will be responding to
10.x.y.z, rather than the "external" address on my server.
"pfctl -sI" includes enc0, em0 (the external interface) and lots
of others, such as the tun interfaces. The appropriate line (I
think) is in the pf.conf file:
nat on customer_out from 10.119.8.0/21 to any ->(removed)
where "(removed)" is one of the "real" ip addresses of the
external-facing ethernet interface, and customer_out is a group
name (as in ifconfig -g) for the external ethernet interface.
Early experimentation indicates that pf is pretty much ignoring
"enc0" -- the ipsec virtual network interface -- even a command to
block all traffic from enc0 didn't stop the (un-natted) pings coming.
This makes me think that IPSEC traffic is somehow completely
bypassing PF, even though in 9.1 and earlier, it didn?t.
Relevant sysctls:
net.inet.ipsec.filtertunnel: 1
net.inet6.ipsec6.filtertunnel: 1
net.enc.in.ipsec_filter_mask: 2
net.enc.out.ipsec_filter_mask: 1
net.inet.ip.forwarding: 1
net.inet.ip.fastforwarding: 0
net.enc.in.ipsec_bpf_mask: 2
net.enc.out.ipsec_bpf_mask: 1
So? Did I miss a knob? I didn't even notice
"net.inet.ipsec.filtertunnel" until this release gave me trouble
-- it's "0" on previous versions of my server, but setting it to
"1" didn't help.
Thanks very much for any pointers!
- Nat Howard
P.S: It would be tricky to build a simple example of anything with
ipsec, but I'll do it if nobody has any better ideas?
P.P.S. A similar problem showed up in RC3 when I use mpd5 and ipsec in
transit mode to implement L2TP, but I'm just beginning to look at
that problem, and am not yet sure this occurs in RC4 or RC5.
Perhaps ipsec packets are being tagged "don't mess
with me" in some way, or diverted in such a way that even after
being decrypted, they dodge PF? It seems that net.inet.ipsec.filtertunnel
is meant to do this, but I am setting it to 1 in all these cases.
P.P.P.S: Yes, the kernel is configured with IPSEC and pf:
device crypto # core crypto support
options IPSEC #IP security (requires device crypto)
options IPSEC_DEBUG #debug for IP security
device enc
options IPSEC_NAT_T #NAT-T support, UDP encap of ESP
device pf
device pflog
device pfsync
? and the ALTQ stuff as well.
Relevant googling and searches of the FreeBSD GNATS database have
shown nothing that seems to match.
Anyone have any idea?
Thanks!
- Nat Howard