Issue with VPN clients behind pfsense

---------------------------------------------------------------------
To unsubscribe, e-mail: support-unsubscribe@...
For additional commands, e-mail: support-help@...

Re: Issue with VPN clients behind pfsense

Re: Issue with VPN clients behind pfsense

jamespev wrote:
> 
>   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

Re: Issue with VPN clients behind pfsense

On 7/31/07, Matthew Grooms <mgrooms@...> wrote:
> 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

Re: Issue with VPN clients behind pfsense

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

Re: Issue with VPN clients behind pfsense

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.

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?

Re: Issue with VPN clients behind pfsense

Matthew Grooms wrote:
> 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.

Re: Issue with VPN clients behind pfsense

On 8/1/07, Matthew Grooms <mgrooms@...> 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

Re: Issue with VPN clients behind pfsense

On 8/1/07, Paul M <it-admin-pfsense@...> wrote:
> 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.
>
> 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

Strange issues with Fedex.com