Bill Marquette wrote:
It's worth noting that pfSense does this by default. Some IPSec
concentrators also expect the udp traffic to source from port 500 and
won't allow connections from arbitrary ports (Nortel Contivity is such
a beast). And yes, it means we can only handle one ipsec connection
to a given concentrator at a time. More than that should really use
site-to-site vpn.
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
thought of pfsense as an alternative to the commercial appliances not
the consumer products.
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
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.
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.
-Matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
