Re: IPsec with NAT-T in transport mode dropping all packets?
Hello again all, On Thu 7/8/08 1:01 pm, David Murray wrote: I'm having a bit of trouble getting IPsec working in transport mode with NAT-T. Briefly, the background is that I'm trying to configure a FreeBSD box to provide to remote Windows clients with VPN access to the network it sits on. To that end, I've been trying to construct a solution with the following: 1) FreeBSD (RELENG_7_0), kernel built with options IPSEC and IPSEC_NAT_T, and patched with 2) the NAT-T patch at http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff, 3) ipsec-tools (0.7.0) for racoon for key exchange, and 4) mpd (5.1) for L2TP. I have two security policy entries in ipsec.conf, intended to encrypt L2TP traffic: spdadd 82.16.99.99[1701] 0.0.0.0/0 udp -P out ipsec esp/transport//require; spdadd 0.0.0.0/0 82.16.99.99[1701] udp -P in ipsec esp/transport//require; The tricky key negotiation all seems to be working; when I initiate a connection from a Windows client, racoon negotiates security associations (I'm using certificates): racoon: INFO: IPsec-SA established: ESP/Transport 195.248.102.183[4500]-82.16.99.99[4500] spi=73448711(0x460bd07) racoon: INFO: IPsec-SA established: ESP/Transport 82.16.99.99[4500]-195.248.102.183[4500] spi=2159874738(0x80bd12b2) However, mpd's log doesn't show any evidence of a single packet arriving (and the client eventually gives up). No takers, so I guess this is either a stupid question or a tricky question! Perhaps I should have asked over on freebsd-net@, but I presumed to ask here first, since I've got no reason to suspect anything other than operator error at the moment. Perhaps I could try a simpler question: has anyone got a L2TP/IPSec roadwarrior-style VPN working where the clients (initiators) are behind NAT? Since my first post, I've tried initiating a connection from a client directly connected to the network I'm trying to VPN in to (so pointless, but a way of testing without NAT) and that works just fine, so I can provide differences between the logs of a failed and working connection. Thanks for any hints! -- David Murray ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IPsec with NAT-T in transport mode dropping all packets?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Murray Sent: Tuesday, August 19, 2008 7:45 AM To: freebsd-questions@freebsd.org Subject: Re: IPsec with NAT-T in transport mode dropping all packets? Hello again all, On Thu 7/8/08 1:01 pm, David Murray wrote: I'm having a bit of trouble getting IPsec working in transport mode with NAT-T. Briefly, the background is that I'm trying to configure a FreeBSD box to provide to remote Windows clients with VPN access to the network it sits on. To that end, I've been trying to construct a solution with the following: 1) FreeBSD (RELENG_7_0), kernel built with options IPSEC and IPSEC_NAT_T, and patched with 2) the NAT-T patch at http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff, 3) ipsec-tools (0.7.0) for racoon for key exchange, and 4) mpd (5.1) for L2TP. I have two security policy entries in ipsec.conf, intended to encrypt L2TP traffic: spdadd 82.16.99.99[1701] 0.0.0.0/0 udp -P out ipsec esp/transport//require; spdadd 0.0.0.0/0 82.16.99.99[1701] udp -P in ipsec esp/transport//require; The tricky key negotiation all seems to be working; when I initiate a connection from a Windows client, racoon negotiates security associations (I'm using certificates): racoon: INFO: IPsec-SA established: ESP/Transport 195.248.102.183[4500]-82.16.99.99[4500] spi=73448711(0x460bd07) racoon: INFO: IPsec-SA established: ESP/Transport 82.16.99.99[4500]-195.248.102.183[4500] spi=2159874738(0x80bd12b2) However, mpd's log doesn't show any evidence of a single packet arriving (and the client eventually gives up). No takers, so I guess this is either a stupid question or a tricky question! Perhaps I should have asked over on freebsd-net@, but I presumed to ask here first, since I've got no reason to suspect anything other than operator error at the moment. Perhaps I could try a simpler question: has anyone got a L2TP/IPSec roadwarrior-style VPN working where the clients (initiators) are behind NAT? Since my first post, I've tried initiating a connection from a client directly connected to the network I'm trying to VPN in to (so pointless, but a way of testing without NAT) and that works just fine, so I can provide differences between the logs of a failed and working connection. Thanks for any hints! -End Original Message- It has been a long time since I looked at IPSEC, but my understanding was that it was designed so that it could not work through either NAT or proxy firewalls. Both schemes change header fields that are considered immutable by IPSEC. So it breaks a checksum. Wouldn't it be better to set up SSH tunnels or a secure VPN? Bob McConnell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
IPsec with NAT-T in transport mode dropping all packets?
Greetings All, I'm having a bit of trouble getting IPsec working in transport mode with NAT-T. I wonder if any experts out there might be able to point me in the right direction. Briefly, the background is that I'm trying to configure a FreeBSD box to provide to remote Windows clients with VPN access to the network it sits on. It seemed that L2TP/IPsec was a sensible approach, since then no additional software is required on the clients. To that end, I've been trying to construct a solution with the following: 1) FreeBSD (RELENG_7_0), kernel built with options IPSEC and IPSEC_NAT_T, and patched with 2) the NAT-T patch at http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff, 3) ipsec-tools (0.7.0) for racoon for key exchange, and 4) mpd (5.1) for L2TP. My understanding is that I need IPsec to operate in transport mode (tunnelling will be provided by L2TP). I need NAT-T, since the clients will likely be behind NAT gateways. I can't seem to find much documentation on this configuration (so maybe I'm going about this the wrong way?). Anyhow, I have two security policy entries in ipsec.conf, intended to encrypt L2TP traffic: spdadd 82.16.99.99[1701] 0.0.0.0/0 udp -P out ipsec esp/transport//require; spdadd 0.0.0.0/0 82.16.99.99[1701] udp -P in ipsec esp/transport//require; The tricky key negotiation all seems to be working; when I initiate a connection from a Windows client, racoon negotiates security associations (I'm using certificates): racoon: INFO: IPsec-SA established: ESP/Transport 195.248.102.183[4500]-82.16.99.99[4500] spi=73448711(0x460bd07) racoon: INFO: IPsec-SA established: ESP/Transport 82.16.99.99[4500]-195.248.102.183[4500] spi=2159874738(0x80bd12b2) However, mpd's log doesn't show any evidence of a single packet arriving (and the client eventually gives up), and, with net.inet.ipsec.debug=1, the kernel issues the single line: kernel: ipsec_common_input: no key association found for SA 82.16.99.99[4500]/460bd07/50 I'm guessing, therefore, that the kernel is discarding packets because it doesn't think it has the correct security associations to deal with them (can I check this?). I'm wondering if this is NAT-T related. I'm a bit suspicious that the security associations are in terms of port 4500, the NAT-T port, and not 1701, the L2TP port. I notice the NAT-T patch adds checking of port numbers to the security association lookup. I'd be very grateful if anyone can spot any stupid mistakes I've made, or can suggest what I might do to diagnose further. I'll happily provide any more info required. Many thanks! -- David Murray ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
