Date: Tue, 14 Jan 2014 18:54:09 -0500 From: Nat Howard <freebsd-stable@track.pupworks.com> To: freebsd-stable@freebsd.org Subject: IPSEC/PF (particularly NAT) problem? RC5,4,3 Message-ID: <CEB744A7-A970-4836-9C4B-B42D6F2B0B60@track.pupworks.com>
next in thread | raw e-mail | index | archive | help
Sorry if this arrives more than once=85. 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=20 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=20 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,=20 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=92t. 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=85 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 =85 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CEB744A7-A970-4836-9C4B-B42D6F2B0B60>