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]
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]
Keyboard not detected on install.
I have an old IBM PS-2 keyboard. When trying to load FreeBSD (any version) from CD there is no response to keyboard actions. I get to where I'm asked what I want to do by using the arrow keys and there is no response. I try to exit and try again and there is no response. I can't get a response to control-alt-delete. I have to shut the box off to try installing again. The hardware is ok because my Linux and OS2 drives work beautifully. How do I trouble shoot when one of my major trouble shooting tools is out of comission? Is this enough info? I looked through the manual and the handbook and there were no references to this problem. I saw nothing in the e-mail archive, either. Any advice? Thank you. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
