L2TP/IPSec with AH/ESP QUES: SonicWALL, firewalls work fine though the Mesh using the client software provided (10 min to setup) and use IPSEC tunnelling. http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs /en-us/sag_ipsectunnel.mspx
However, I lost two customers do to this issue. I was willing to keep trying to find the problem but their IT depts wouldn't work with me at all.Both customers were on the latest version of Nortel VPN products. One of the clients I do development for gave me VPN access. It's nortel and works fine through the mesh. It's an older version than the one being used by my ex-customers. My neighbor uses cisco products and he works fine as well. I had a tough time getting *good* information on the different *payfor* VPNs.
ANSW: I got L2TP/IPSec to go through the MeshAP, but I had to remove the NA(P)T on eth0 (outside or public interface). I believe I got it to work with that NA(P)T still in place, but using an IPSec pass-through, but I could not repeat or verify. From the testing, I can deduce that the reason it is not working is because L2TP/IPSec requires transport mode (RFC 3193), but the ISAKMP NAPT requires tunnel mode. If I can somehow get it to work with transport mode, it will work even with the full NAPT. Note also that this does not break the NA(P)T required for the mesh to work. Here's the statement I removed:
iptables -t nat -D POSTROUTING -o eth0 -s 192.168.0.0/16 -d 0.0.0.0/0 -j MASQUERADE
(it's also found in the start-up scripts in /hj/detectmode, so I comment it out there) Here is the statement that I want to be able to connection track to (above that statement, but without removing it):
iptables -t nat -I POSTROUTING -p udp --dport isakmp -j MASQUERADE --to-ports 500
(or put it into the /hj/detectmode file after the other line above) Maybe I need to add another line or change this line to support transport instead of tunnel mode? Maybe I should put ESP (and maintain state) in the netfilter FORWARD rules? I'm not sure. I also don't think those lines are supposed to be in /hj/detectmode, they should probably be in /etc/init.d/rc.firewall or similar (but I'm not sure). I blame this on wiana.
I understand that the Linux kernel that comes with MeshAP is version 2.4. Linux kernel 2.6 is required for use with NAT-Traversal (i.e. NAT-T). NAT-T would allow passage of these packets (in tunnel mode at least), but MeshAP doesn't currently have NAT-T. IPSec Pass-Through with iptables/netfilter is an option, but this would only allow IPSec in ESP-only mode (i.e. there is no connection tracking for AH packets). Since IPSec AH/ESP is relatively popular among users, this isn't a very viable alternative.