Issue with VPN clients behind pfsense

[jamespev]

  Hello.  I am having an issue with pfsense.  Essentially, only one user can be connected to VPN from behind the pfsense firewall.(ie we are connected to a VPN concentrator which is outside the network on the internet from inside the pfsense firewalled network)  We are using the Cisco VPN client.  The client works fine when TCP transport is used, but only one UDP transport user can be connected at once.  Since the Linux Cisco client vpnc only supports UDP this is quite annoying for the linux users.  We started with 1.2Beta1, then Beta2, now RC1... issue has remained the same throughout.  We have paved and reinstalled the machine and played with configuration extensively but couldn't get it to work.  It appears from the logs that when the second user attempts to login, the return traffic from the concentrator is getting blocked by pfsense.
  Any ideas?  We are pretty much stumped on this.  We did not have issues like this with our previous firewalls (although they were much less capable in every other way, I love pfsense).
James

[Alex Robar]

This was a known issue last I heard, but what about a site-to-site VPN? If
it suits your situation, have pfSense establish a site-to-site VPN with the
concentrator. You've only got one VPN link at that point and all users
behind pfSense can access the remote network without establishing their own
VPN.

AR

Hello. I am having an issue with pfsense. Essentially, only one user
can be connected to VPN from behind the pfsense firewall.(ie we are
connected to a VPN concentrator which is outside the network on the internet
from inside the pfsense firewalled network) We are using the Cisco VPN
client. The client works fine when TCP transport is used, but only one UDP
transport user can be connected at once. Since the Linux Cisco client vpnc
only supports UDP this is quite annoying for the linux users. We started
with 1.2Beta1, then Beta2, now RC1... issue has remained the same
throughout. We have paved and reinstalled the machine and played with
configuration extensively but couldn't get it to work. It appears from the
logs that when the second user attempts to login, the return traffic from
the concentrator is getting blocked by pfsense.
Any ideas? We are pretty much stumped on this. We did not have issues
like this with our previous firewalls (although they were much less capable
in every other way, I love pfsense).
James
---------------------------------------------------------------------

[Matthew Grooms]

Hello. I am having an issue with pfsense. Essentially, only one user
can be connected to VPN from behind the pfsense firewall.(ie we are
connected to a VPN concentrator which is outside the network on the
internet from inside the pfsense firewalled network) We are using the
Cisco VPN client. The client works fine when TCP transport is used, but
only one UDP transport user can be connected at once. Since the Linux
Cisco client vpnc only supports UDP this is quite annoying for the linux
users. We started with 1.2Beta1, then Beta2, now RC1... issue has
remained the same throughout. We have paved and reinstalled the machine
and played with configuration extensively but couldn't get it to work.
It appears from the logs that when the second user attempts to login,
the return traffic from the concentrator is getting blocked by pfsense.
Any ideas? We are pretty much stumped on this. We did not have
issues like this with our previous firewalls (although they were much
less capable in every other way, I love pfsense).

I assume you are using NAT. If you are using ESP-in-UDP encapsulation
then any number of clients should be able to communicate outbound via pf
when NAT is being performed.

What do your rules look like? Are you restricting any outbound traffic?
At a minimum, ISAKMP UDP port 500 and NAT-T UDP port 4500 need to be
allowed. Also, a firewall may be performing the equivalent of this ...

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

... which acts like a VPN pass-through by forcing the source port to not
be translated. This is fine when only a single host is attempting to
communicate with a VPN gateway but could cause serious problems if you
have multiple simultaneous connection attempts.

-Matthew

[Bill Marquette]

Post by Matthew Grooms
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
... which acts like a VPN pass-through by forcing the source port to not
be translated. This is fine when only a single host is attempting to
communicate with a VPN gateway but could cause serious problems if you
have multiple simultaneous connection attempts.

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

[Matthew Grooms]

Post by Bill Marquette
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

[Chris Buechler]

Post by Matthew Grooms
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.

The default configuration for all things is intended to work for the
majority of users. This isn't necessarily for "antiquated VPN clients",
it broke a number of them. Less things are broken this way than without it.

You can disable this behavior by enabling AON and defining your own NAT
rules.

[Bill Marquette]

Post by Matthew Grooms
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.

Post by Matthew Grooms
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.

Post by Matthew Grooms
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.

Post by Matthew Grooms
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.

Post by Matthew Grooms
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

[Matthew Grooms]

Post by Bill Marquette
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.

Post by Bill Marquette
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.

Post by Bill Marquette
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

Post by Bill Marquette
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

[Chris Buechler]

Post by Matthew Grooms

Post by Bill Marquette
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.

Post by Bill Marquette
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.

Post by Bill Marquette
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

Post by Bill Marquette
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.

Yeah, as it says in the GUI, "*Automatic outbound NAT rule generation
(IPSEC passthrough)" or *"*Manual Outbound NAT rule generation (Advanced
Outbound NAT (AON))".


*

Post by Matthew Grooms
If pfsense only auto-generates the rule for ISAKMP traffic to be
sourced from port 500, then that should be fine.

That's what it does. Also 5060 for SIP, since it seems a bunch of SIP
implementations are broken without that, but only 500 and 5060.

[Paul M]

Post by Bill Marquette
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.

can you set up multiple external interfaces/IP addresses and bind
pfsense's vpn termination point to the specific interface, and then have
multiple termination points?

[Bill Marquette]

Post by Paul M

Post by Bill Marquette
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.

can you set up multiple external interfaces/IP addresses and bind
pfsense's vpn termination point to the specific interface, and then have
multiple termination points?

Yes, if you have that option. I have coworkers that have installed
pfSense and have multiple people connecting to my work behind it.
They used 1:1 NAT to solve the problem.

--Bill