Bill Marquette wrote:
Or corporations that refuse to enable NAT-T on their IPSec concentrators.
Which should be the exception to the rule. But as I stated before, thats just my opinion based on my own experience supporting these platforms.
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.
Yes, I am familiar with the fixup logic and am glad that pf doesn't support it. It sounds like this has already been hashed out on the list and I am a late comer to the discussion. If it helps more pfsense users than it hurts, then its obviously the correct default.
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.
I never said it did. My points were ... 1) It is a published very widely used standard 2) All major commercial vendors support it 3) All major open source OS's support it except FreeBSD
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.
Alright, so you have to enable AOT before modifying auto-generated nat rules. I don't doubt that you know your way around pfsense better than I do.
If pfsense only auto-generates the rule for ISAKMP traffic to be sourced from port 500, then that should be fine. The peers will still detect the NATed address and move to 4500. Forcing NAT-T communications to be sourced from port 4500 is a bad idea. The only hosts trying to do IKE/ESP over this UDP port obviously support NAT-T. Forcing packets to be sourced from 4500 buys you nothing and prevents the protocol from working correctly.
However, if forcing the source port for NAT-T to 4500 does happen to fix a clients ability to connect, its because the gateway is badly mis-configured. The admin has modified a firewall rule to only accept NAT-T packets sourced from 4500 which goes against the RFC which may be the problem in James case. If so, no amount of configuration in pfsense will correct the issue and he will be forced to take it up with the gatway / firewall admin.
-Matthew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
