On 8/1/07, Matthew Grooms <[EMAIL PROTECTED]> wrote: > Bill, > > Thanks for the information. I'm not a pfsense developer but I would have > to disagree with your last statement. In my opinion, making exceptions > in the default rules to work around antiquated VPN clients is the wrong > way to go. Maybe this still makes sense for a home firewall where you > are not likely to have more than one remote access user but I always
Or corporations that refuse to enable NAT-T on their IPSec concentrators. > thought of pfsense as an alternative to the commercial appliances not > the consumer products. There are some limitations we have. pf/FreeBSD doesn't have an IPSec aware "fixup" if you will, so we have no way of knowing which session a reply packet is destined for. This means, for backwards (no surprises) support, we can only handle one ipsec passthrough connection. > Cisco, Juniper, Checkpoint, Microsoft and Nortel ( newer Contivity ) are > all on board with NAT-T as its been a non-draft RFC standard for some And that setting isn't necessarily on by default. I work at a place that has it disabled and for my coworkers that I've turned onto pfSense, they all fire it up out of the box and it "just works". It'll "just work" for any home user making use of NAT-T also. > time. The alternatives IPsec Tools, Free/OpenSWAN, vpnc, Greenbow and > Shrew Soft clients all support it as well. Linux, NetBSD and OpenBSD all > include support along with production kernel code. If there is one > straggler, its FreeBSD :\ but this should change soon as the new IPsec > code settles in current. The NAT-T support (or lack thereof) in FreeBSD, has nothing to do with it performing as the NAT box. From what I understand, it's for server side NAT-T (and maybe client?) support. Even if it was there, in kernel, today, it wouldn't solve the issue being discussed. > James, > > If you can find the nat rules that resemble these ... > > nat on $ext proto udp from $prv_net port 500 to any -> ( $ext ) port 500 > nat on $ext proto udp from $prv_net port 4500 to any -> ( $ext ) port 4500 > > ... you should remove them. This will un-break support for IPSEC NAT-T > UDP encapsulation. Or, he could just turn on Advanced Outbound NAT, and remove the the autogenerated IPSec rules (I think we only autogenerate udp 500). If his concentrator supports NAT-T, that's all he needs to do. --Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
