Some general questions on VPN and limitations vs future versions..
-
Personally I manage this by managing the client. As you say, they don't know anything about this stuff, they just want it to work - so why do they care what technologies are supported, or how? As long as you can fulfill their needs (ie. a mobile VPN setup) they shouldn't need to even know what you're using on the backside. In this respect I've found that either IPsec or OpenVPN almost always fits the bill and works well in pfSense, but mostly I am setting up point-to-point tunnels so maybe there are limitations I haven't seen. NAT-T is in 1.2.3 as mentioned and I've been using it for a couple of weeks at a new client for mobile VPN and haven't had any issues, so now I can almost completely ditch OpenVPN even.
I suppose there might be some situations where you need to access a VPN you don't control via pfSense, and maybe some of the PPTP or L2TP stuff might be relevant, but I'd think you'd either know ahead of time about this, or the customer should expect cost to get the new unplanned tunnel set up.
-
Can you spell out exactly what limitations you are referring to? As far as I know, pfSense has no more limitations than any other VPN product. You have to understand the limitations of NAT, IPSEC, SSL and TCP/IP in general.
Everything requires setup, both on the head-end and client side. Nothing "just works".
-
Can you spell out exactly what limitations you are referring to? As far as I know, pfSense has no more limitations than any other VPN product. You have to understand the limitations of NAT, IPSEC, SSL and TCP/IP in general.
Everything requires setup, both on the head-end and client side. Nothing "just works".
That is only partly correct, see notes by pfS team on below URL:
http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43 -
Personally I manage this by managing the client. As you say, they don't know anything about this stuff, they just want it to work - so why do they care what technologies are supported, or how? As long as you can fulfill their needs (ie. a mobile VPN setup) they shouldn't need to even know what you're using on the backside. In this respect I've found that either IPsec or OpenVPN almost always fits the bill and works well in pfSense, but mostly I am setting up point-to-point tunnels so maybe there are limitations I haven't seen. NAT-T is in 1.2.3 as mentioned and I've been using it for a couple of weeks at a new client for mobile VPN and haven't had any issues, so now I can almost completely ditch OpenVPN even.
I suppose there might be some situations where you need to access a VPN you don't control via pfSense, and maybe some of the PPTP or L2TP stuff might be relevant, but I'd think you'd either know ahead of time about this, or the customer should expect cost to get the new unplanned tunnel set up.
Yes it can solve some problems clearing stuff with client beforehand that's for sure.
Many small businesses use PPTP cause they're easy to set up and they don't need extra client SW and in such a situation the PPTP limitation is very likely to be in effect. That would be true for a number of clients I know of. But I'm sure pfS will embed the fix in future versions so we can rule that one out. The NAT-T fix should also solve a lot and then we're almost there :) -
That is only partly correct, see notes by pfS team on below URL:
http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43What exact limitations are you referring to? I see nothing that is out of the ordinary for any implementation of IPSEC or PPTP, with the exception of NAT-T. PFS says that works in the new builds now.
-
That is only partly correct, see notes by pfS team on below URL:
http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43What exact limitations are you referring to? I see nothing that is out of the ordinary for any implementation of IPSEC or PPTP, with the exception of NAT-T. PFS says that works in the new builds now.
I'm referring to all 6 mentioned on the page, but obviously the PPTP and NAT-T firstly.
-
Most of the VPN limitations listed on that page will be fixed by 2.0.
IPsec
- NAT-T is not supported, which means mobile clients behind NAT are not supported. This limits pfSense's usefulness with mobile IPsec clients. OpenVPN or PPTP is a better solution.
Fixed in 1.2.3
- Only one end of an IPsec tunnel can have a dynamic IP address.
Fixed in 1.2.3 (can use a DNS hostname instead of IP, so you can use dyndns to accomplish this)
- Some of the more advanced capabilities of ipsec-tools are not yet supported, including DPD, XAuth, NAT-T, and others.
Not sure on this one
- Not all of the capabilities of OpenVPN are supported yet. Support for virtually all of OpenVPN's capabilities will be included in the next release.
Someone was working on this, not sure if anything has happened in a while. The OpenVPN gui in 2.0 was completely redone, but it is not yet complete.
- Filtering of OpenVPN traffic is not yet possible. Support for this is in 2.0.
Fixed in 2.0
- Because of limitations in pf NAT, when the PPTP Server is enabled, PPTP clients cannot use the same public IP for outbound PPTP connections. This means if you have only one public IP, and use the PPTP Server, PPTP clients inside your network will not work. The work around is to use a second public IP with Advanced Outbound NAT for your internal clients. See also the PPTP limitation under NAT on this page.
I'm fairly certain this was also being worked on in 2.0, but I'm not sure of the status.
-
This is really good news :)
-
- Filtering of OpenVPN traffic is not yet possible. Support for this is in 2.0.
Fixed in 2.0
According to this: http://blog.pfsense.org/?p=428
Disable auto-added VPN rules option - added to System -> Advanced to prevent the addition of auto-added VPN rules for PPTP, IPsec, and OpenVPN tun/tap interfaces. Allows filtering of OpenVPN client-initiated traffic when tun/tap interfaces are assigned as an OPT.
We already have filtering of OpenVPN in 1.2.3
-
We already have filtering of OpenVPN in 1.2.3
I was experimenting with this a little today, and while it did work, there were plenty of quirks in getting it to do so… But it does work.
