A couple of problems setting up openvpn-client on pfsense 1.2-RELEASE

tenortim

Hi folks,
I just got my ALIX setup today and replaced my old firewall. I have pretty much everything going, but I have run into two issues with openvpn, and I am looking for advice:

I haven't seen this documented anywhere. The GUI expects a CIDR for the value(s) that generate the ifconfig line in the openvpn config file. This makes it impossible to generate the correct values in my case. The openvpn server is not under my control and it expects an ifconfig line on my client of

ifconfig 10.20.0.61 10.20.0.62

It is not possible to generate those values using the single CIDR (you can generate them back-to-front but that doesn't help). I would request that, at least in 1.3, the GUI allows for entry of two separate IP addresses so that the client- and server- side addresses can be explictly specified, or an option be made available to specify that they are flipped. I can happily code up the changes if that would help.

The old issue of the lack of NAT on the tun interface. Perhaps I am missing something here, but for the case of pfsense operating as an openvpn client as opposed to a server, doesn't the inability to set NAT on the tun interface make it pretty much unusable? It is not at all practical to set routes on the server to the client networks. In my case, there are many clients served by the openvpn server, mostly with the same unroutable rfc1918 addresses. Whilst general support is clearly harder, adding a simple "Enable NAT on the vpn interface" checkbox seems pretty simple. Again, I am happy to code this up if that helps.

Does anybody know if these problems are being worked on/fixed in the upcoming 1.3?
Should I log ticket(s) in trac?
Should I code up fixes against 1.2?

I can easily back-off to using another box in the interim, but I would like to pitch-in and help if I can.

Thanks for providing such an awesome piece of software!

Tim

GruensFroeschli

What kind of subnet do you have for the openVPN link that you NEED to have the IP's 10.20.0.61 & 62?
A /30 subnet would be 10.20.0.59 - 62 –> usable IP's 60 and 61

2: If the client connects a whole network you pretty much should know that.
If you do know that, then it's not a problem of adding a route line to the openVPN config.

I'm not sure when NAT for OpenVPN comes.
But it seems there are a few things for openVPN in the pipeline :)

tenortim

@GruensFroeschli:

What kind of subnet do you have for the openVPN link that you NEED to have the IP's 10.20.0.61 & 62?
A /30 subnet would be 10.20.0.59 - 62 –> usable IP's 60 and 61

2: If the client connects a whole network you pretty much should know that.
If you do know that, then it's not a problem of adding a route line to the openVPN config.

I'm not sure when NAT for OpenVPN comes.
But it seems there are a few things for openVPN in the pipeline :)

Regarding 1:
Ah, this may be the point of confusion. Nowhere in the OpenVPN documentation does it say that the ifconfig lines need to be part of a subnet. It is perfectly valid and functional to choose e.g. 10.12.0.61 at one end 10.12.0.99 at the other. It is, to all intents and purposes, a point-to-point link. In fact, prior to Openvpn 2.0, that was all it was, and our config predates 2.0 by a long way. Quoting from the OpenVPN FAQ:

In OpenVPN 1.6, when you had to run one OpenVPN instance per client, then it would be more like you expected: a PtP link between the server and each client.

In 2.0 however, OpenVPN can handle multiple clients with only one tun interface on the server. To handle this, you can think of the PtP link you see on server as a link between the operating system and OpenVPN. Then when you're inside OpenVPN, another PtP link needs to created to each client. If all O/S would have supported true PtP links over the tun interface, this could have been done with the OpenVPN server using only one IP address and each client using another IP address.

But, as the TUN/TAP driver implementation on Windows does not support true PtP links, this is emulated through a /30 subnet.

So forcing the user to choose a CIDR rather than 2 addresses prevents them generating valid configurations that are currently in use. I did a horrible workaround and added the "ifconfig 10.20.0.61 10.20.0.62" into the additional area, and although the original incorrect entry is still there, it is overridden by the second one.

Regarding 2:
I can access the networks fine from the firewall, but not from anywhere on the local network. If you do not enable NAT on the tun interface (and currently, there is apparently no supported way to do so directly, though it seems it may be possible to get the right effect by switching to advanced outbound NAT and enumerating the subnets), then the addresses that get sent over the vpn link are the client's local network addresses. That doesn't work a) because the server end has no route to those addresses, and I do not control that network and b) even if I did, there are many clients, and many of them have the same address ranges because they are private networks behind the firewall so there is no way to provide distinct routes to them. That's why it is necessary to enable NAT on the OpenVPN tun* interface.

Is there anywhere in particular I should look to see what is going on on the development side here? I have the ability to help work on this if that would be helpful.

Thanks very much for the response.

Regards,

Tim

GruensFroeschli

Well one "way" (ugly hack) would be that you set up a second machine and define on it the OpenVPN interface as WAN.
Then i think you can NAT to the WAN.
http://devwiki.pfsense.org/OpenVPNasWAN

But this would require that you have more than one machine.
One as router and another one just for the openVPN tunnel.

(and i'm not even sure if that works….)