Some general questions on VPN and limitations vs future versions..

[0tt0]

Hi,

Since there's no board for general VPN issues and thoughts I'll post it here then..

As I understand it m0n0 supports PPTP and IPSec and pfS all three. I use one of them myself and it appears good.

However, I am a bit worried over the limitations.
I don't like the situation where - regarding pfS - one simply cannot say to a client that "it supports VPN of all those three variants.." since the limitations are so grave so one has to immediately fill in: "..but it cannot do this and that and this..". Many clients would get quite annoyed and say "don't but me with details, simply get me something that will always WORK..".

To install pfS there and then having to explain to that person that "that particular usage cannot be supported due to <lenghty tech stuff he doesn't understand..> and I told you that 6 months ago..". He would get pissed off.

How do you guys do when selling in pfS and it's going to be used for VPN? For example, the issue with NAT-T or not being able to use outgoing PPTP when inboud is set-up, which I imagine is quite common?

And then there's fixes that could/should fix some issues..? Well, any such fixes should be built-in and as long as they're not I'll take that as an indications that the pfS developers themselves don't regard them as fully stable and then I wouldn't want to use them anyway.

As I understand it all this is due to the use of PF, right? Or just partly correct? And since m0n0 doesn't use it it doesn't have the limitations pfS has, right? It would be quite interesting to hear some discussion (or point me to it..) concerning the design choices taken, despite these VPN-issues coming with them.

I am myself thinking of moving over entirely to m0n0 or perhaps use m0n0 as VPN engine only instead, but haven't decided what route would be the least problematic. And I do feel that pfS seems a bit more full featured (even though much is present in m0n0 too) and then there's the issues with one or two packages that one just cannot be without..

How do pfS devs see it, the problems with PF in regard to VPN is not enough to replace it since it brings so many other advanced stuff in, regarding shaping and state table handling etc etc?

I have noted that some fixes seem to be upcoming (frickin etc) but can someone say something more strategic concerning upcoming versions of pfS and VPN status in regards to present limitations?

TIA,

[submicron]

NAT-T is supported in pfSense 1.2.3. 

[Cry Havok]

You'll never get something that'll "always work".  Every implementation has limitations - the difference is that pfSense is more up-front about the limitations of VPNs on pfSense than some commercial bodies

Remember too that pfSense is still pretty young, it takes time to knock all the rough edges out.  It takes people using it in ways the developers don't, or can't, before problems get found.  The limitations aren't to do with the use of pf as far as I can tell (and I've spent a long time following the development of both ipfilter and pf).  Also, some problems relate to the version of FreeBSD in use, the developers of pfSense can't always fix those themselves.

If you want the least problematic then buy a commercial VPN solution and require everybody to use that manufacturer's VPN client.  If you want free then you have to accept that you're getting what you're paying for   Don't forget you can open a bounty to get features added.  The developers have their own agenda, if you're not paying for their effort then that's what they'll work to.

[0tt0]

You'll never get something that'll "always work".  Every implementation has limitations - the difference is that pfSense is more up-front about the limitations of VPNs on pfSense than some commercial bodies

Yeah well, perhaps. But surely users would be quite annoyed if for example mobile clients in IPsec weren't working and nothing was said about that. So, yes I guess they are and that's good, but given what is not working right now they have no option but to be open with it, to be honest.

Remember too that pfSense is still pretty young, it takes time to knock all the rough edges out.  It takes people using it in ways the developers don't, or can't, before problems get found.  The limitations aren't to do with the use of pf as far as I can tell (and I've spent a long time following the development of both ipfilter and pf).  Also, some problems relate to the version of FreeBSD in use, the developers of pfSense can't always fix those themselves.

True. I'm interested in some more detailed comparison on this, between m0n0 and pfS. Are there any practically important limitations in m0n0wall's VPN implementations today?

If you want the least problematic then buy a commercial VPN solution and require everybody to use that manufacturer's VPN client.  If you want free then you have to accept that you're getting what you're paying for   Don't forget you can open a bounty to get features added.  The developers have their own agenda, if you're not paying for their effort then that's what they'll work to.

(This is true, sort of) When this ceases to be as true, then but only then will open source be a real alternative for many now Windows-locked-in users. I very recently worked as an IT consultant myself so I have heard what type of arguments users and clients often have. I would love to be able to replace all those DLink, Netgear etc SOHO FWs with pfS and be sure the basics just works (incl. VPN). Today pfS is a very powerful product, it's not easy to find alternatives that offer the same and when they exist they are often quite expensive. One of the very few problems with the base system I've seen are these VPN issues.

Not sure I fully agree with you though, that this fully pertains to the VPN issues here; I have used extensively a Linux laptop the last year or so (just to give you one example) and I have had no problems using the VPN _client_ with that one. Just as I had no problems admin the pfS server at the other end. And none of the commercial versions I've seen on Win$low were any *easier* to use. Open Source solutions in this particular area are quite mature, there are others that are more problematic, but then we'll stray too much off topic so..

I just hope these few limitations can be ruled out soon, that would benefit pfS greatly I think. (I would also like the RADIUS package to be part of the system, so that it were easily available on embedded too, but that's another thing entirely .

Cheers,

PS: I would gladly contribute to pfS by buying the book that is being worked on, anyone know when it will be released?

[ktims]

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.

[valnar]

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".

[0tt0]

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

[0tt0]

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

[valnar]

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

What 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.

[0tt0]

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

What 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.

[jimp]

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.

[0tt0]

This is really good news

[GruensFroeschli]

    * 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

[jimp]

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.