2.1 / OpenVPN /PIA: can't get it to work

[Mr. Jingles]

@brick41:

Hello I also have private internet access and cannot get OpenVPN to work. It connects just fine but I don't have any internet. I am using this ISO downloaded and installed today:
pfSense-LiveCD-2.1.2-RELEASE-amd64-20140410-0541.iso

I think there is something wrong because the directions from (http://www.komodosteve.com/archives/232) are pretty straightforward. I will try an older ISO tomorrow.

Good to see for my self confidence that I am not the only one  ;D

My attempts were at 2.1 (since you wrote you will try an older one than 2.1.2), and that I couldn't get to work.

For more than just this reason of PIA I decided to completely rebuild my box, yesterday evening I deleted everything and installed 2.1.2. I have yet to try PIA, but given your feedback I think I already know my answer  :'(

[phil.davis]

In versions prior to 2.1.2 the automatic outbound NAT was not making outbound NAT rules for OpenVPN clients that connected out to VPN providers. That was the intended behavior. But there was a [bug|feature] that when you switched to manual outbound NAT, the initial set of rules generated did include NAT rules for OpenVPN clients. That is why the step of switching to manual outbound NAT did the trick.
From 2.1.2, the underlying automatic outbound NAT rules and the set generated when you switch to manual outbound NAT are now the same.
You have to switch to manual outbound NAT, and then add outbound NAT rule/s for traffic leaving the OpenVPN client towards the VPN provider.

[Mr. Jingles]

@phil.davis:

In versions prior to 2.1.2 the automatic outbound NAT was not making outbound NAT rules for OpenVPN clients that connected out to VPN providers. That was the intended behavior. But there was a [bug|feature] that when you switched to manual outbound NAT, the initial set of rules generated did include NAT rules for OpenVPN clients. That is why the step of switching to manual outbound NAT did the trick.
From 2.1.2, the underlying automatic outbound NAT rules and the set generated when you switch to manual outbound NAT are now the same.
You have to switch to manual outbound NAT, and then add outbound NAT rule/s for traffic leaving the OpenVPN client towards the VPN provider.

Thank you very much for your reply, Phil  ;D

PS The OpenVPN log doesn't appear to show any errors.

I tried to add 'some' manual NAT rules, basically by copying the existing ones the switch to 'manual' generated and only changing the interface, but I am still not there yet  :-\

I do have something more now: it now shows me an IP on the gateway (but it is an internal IP, I would have expected an external one), but the gateway itself is offline (screenshot).

So probably I've done something wrong again.

Interesting to see is the firewall on the PIA-interface is blocking something (screenshot).

Would you happen to have a clue as to how to fix this?

Thank you again for all your great help  :-*


[Mr. Jingles]

Picture of my manual NAT outbound:


[Mr. Jingles]

Mmmm. Interesting ( ::)): when I restart the openvpn-service the gateway is up for three seconds, then it is down again. To my understanding the log (attached) doesn't show anything strange.

What is strange too, is: suddenly my MS Outlook mail client can not access my POP3 gmail accounts anymore, due to 'password incorrect'. Even 'though I have not even yet sent any traffic over the PIA interface (firewall rule), as that is still not working correctly.

log1.txt

[phil.davis]

That looks good to me.
PIA allocates some private address space to your VPN tunnel (they won't want to use up their valuable public IP addresses). They know who you are, and will NAT your traffic when it goes out of their VPN server onto the public internet.
But of course they don't know what other private IP addresses you are using behind the PIA tunnel. So pfSense has to NAT onto the tunnel - that way PIA sees all the traffic as coming from the OpenVPN client tunnel IP.
Can someone else spot what else is missing here?

[Mr. Jingles]

@phil.davis:

That looks good to me.
PIA allocates some private address space to your VPN tunnel (they won't want to use up their valuable public IP addresses). They know who you are, and will NAT your traffic when it goes out of their VPN server onto the public internet.
But of course they don't know what other private IP addresses you are using behind the PIA tunnel. So pfSense has to NAT onto the tunnel - that way PIA sees all the traffic as coming from the OpenVPN client tunnel IP.
Can someone else spot what else is missing here?

Thank you Phil  ;D ;D

It gets Eek  :o :o :o

The errors from gmail apparently are because gmail is blocking the logins because of …:

Someone recently used your password to try to sign in to your Google Account. This person was using an application such as an email client or mobile device.

We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:

Wednesday, April 16, 2014 10:19:58 AM UTC
IP Address: 46.165.251.68
Location: Berlin, Germany

If you do not recognize this sign-in attempt, someone else might be trying to access your account. You should sign in to your account and reset your password immediately.

When I go to dslreports.com/whois, I do note suddenly my external address is one in the 46.x.x.x range, so probably that same 46.x.x.x block Google thought was a hacker.

Which would mean that PIA is working.
But:

• Why does the gateway show 'down'?
• Why is all traffic routed over PIA when I never told pfSense to do this?

I'm not quite sure I guess how I need to do this:

• After following the setup tutorial from Komodosteve (my first post), there 'suddenly' where two new interfaces. PIA and OpenVPN.
• According to the tuto I had to assign the openvpn-client to the WAN interface, which is my normal VDSL-account.
• I don't want all traffic to go through PIA, only some.

But now, without me directing any traffic from the LAN into the PIA gateway, apparently all traffic is going through PIA 'anyway'.

Could this have to do something with the way I set up this manual NAT outbound?

To summarize:
1. Why does the gateway for PIA show down when apparently it isn't?
2. Why is all traffic going through PIA by default even if I didn't tell pfSense to do it by directing LAN-traffic through PIA?

Thank you again for your great help  ;D ;D ;D

[Mr. Jingles]

EDIT: although PIA was NOT the default gateway (in system/routing), so that couldn't be the cause for all traffic going through the gateway even when I didn't tell it do to so, while in system/routing I decided the change the monitor IP to 8.8.4.4, instead of the internal 10.x. pfSense assigned itself. That makes the gateway appear as up in the dashboard.

So all I need to figure out now is why all traffic is going through the PIA. Which I definitely don't want (and I hope my Google mail accounts are still recoverable now  :-).

[Mr. Jingles]

EDIT2 ( ;D):

It appears that if I have the default LAN rule direct all traffic into my Failover group, which consists of only my local VDSL and my local Cable, I get my old Dutch external IP. If I then remove the failover group from the gateway in the firewall rule screen, hence leave it at 'default', I will have the German IP again.

I think I can use this knowledge to construct firewall rules the way I want it, but I still don't understand why all traffic is directed through PIA by default, when PIA is not the default gateway (WAN1, VDSL, is).

??? :o


[phil.davis]

• According to the tuto I had to assign the openvpn-client to the WAN interface, which is my normal VDSL-account.

I haven't watched the tutorial, but this seems an odd thing to do. I would want my WAN interface to be the real, unencrypted link to my ISP. Then I build an OpenVPN client to PIA connection on top of that. The PIA connection is assigned to a new interface (OPTn), enable that interface, pfSense automagically makes a gateway that points to the PIA server end of the OpenVPN link.
Then add firewall rules to LAN to match desired traffic and select the PIA GW to push the traffic you want to go through PIA.

[Mr. Jingles]

@phil.davis:

• According to the tuto I had to assign the openvpn-client to the WAN interface, which is my normal VDSL-account.

I haven't watched the tutorial, but this seems an odd thing to do. I would want my WAN interface to be the real, unencrypted link to my ISP. Then I build an OpenVPN client to PIA connection on top of that. The PIA connection is assigned to a new interface (OPTn), enable that interface, pfSense automagically makes a gateway that points to the PIA server end of the OpenVPN link.
Then add firewall rules to LAN to match desired traffic and select the PIA GW to push the traffic you want to go through PIA.

And thank you once again Phil, for your great assistance  ;D

I would have expected it to be like you write, but when I try what you say (pic) the gateway goes down immediately. Set the interface back to WAN in the OpenVPN-client, and the gateway is up immediately again.

Could it be some error in another part of the system that I need to check?

(Been working for three hours to get Radius with EAP-TLS working again on this new box. Completely frustrated I asked WIFE if she had a clue. She browsed in all my screenshots for 5 minutes and said 'this picture of NAT, in december last year, did you that? The exact NAT-thing you told me this morning… Why you now have to set NAT manually is a bit of a mystery to me; having pfSense do it automatically is more user comfortable, so to speak. Anyway: where would I be without WIFE  ;D).

[gazzaman]

sorry not had chance until now to post these
If you need anymore let me know

[gazzaman]

Hi else I had to do was create the ca.crt in the txt editor and save it to /etc/ca.crt

[brick41]

@phil.davis:

In versions prior to 2.1.2 the automatic outbound NAT was not making outbound NAT rules for OpenVPN clients that connected out to VPN providers. That was the intended behavior. But there was a [bug|feature] that when you switched to manual outbound NAT, the initial set of rules generated did include NAT rules for OpenVPN clients. That is why the step of switching to manual outbound NAT did the trick.
From 2.1.2, the underlying automatic outbound NAT rules and the set generated when you switch to manual outbound NAT are now the same.
You have to switch to manual outbound NAT, and then add outbound NAT rule/s for traffic leaving the OpenVPN client towards the VPN provider.

You hit the nail on the head, Phil. I have working Private Internet Access now.

For everyone else here are some directions. After you follow the directions on http://www.komodosteve.com/archives/232 make sure that Status > Gateways shows your OPT1_VPNV4 interface. If it doesn't you will have to reboot (I had to). It may show as down (screenshot) since there is no ping reply but that's ok. After the reboot it should automatically connect to PIA so check the Status > OpenVPN and then try a traceroute. You should see the traceroute is done over PIA (screenshot).

Firewall > NAT > Outbound: After switching to Manual Outbound NAT there is a rule "Auto created rule for LAN to WAN" (not the ISAKMP one). I clicked on the little + button to right of it to "add a new NAT based on this one" (tooltip text). That gave me a copy of that rule and I changed WAN to OPT1 and saved the rule as "OpenVPN (PIA)". Then it returned me to the Outbound page and I clicked the "Apply Changes" button that appeared in a red banner above the rules.

The next problem I had was DNS leaks. DNS was still going out on the WAN. Is that normal? Did I miss some OpenVPN setting? Anyway I decided to make it so that LAN traffic would go out only over the VPN. Skip the rest of these instructions if you don't want to do that. In other words traffic is blocked when the VPN is down. Here's how I did it, and if this is wrong or is leaky please let me know:

This first step was my last step. I tried several times to route traffic over the VPN but traffic kept leaking. I did some searching and read that pfSense will create failover rules when a gateway is down. To disable that you have to "skip rules":
RESOLVED : Firewall rules and OpenVPN client Vs. default gateway
System > Advanced > Miscellaneous > Gateway Monitoring > Skip rules when gateway is down > CHECK

If you're not using IPv6 you could disallow it. I'm not using it but after I disallowed it my logs were filled with IPv6 router availability broadcasts, so I turned it back on just for less noise. There is probably a way to disable IPv6 entirely. This is more of a filtering:
System > Advanced > Networking > IPv6 Options > Allow IPv6 > UNCHECK

This forces traffic to go from the LAN to the VPN, however it doesn't stop communicating with the LAN.
Firewall > Rules > LAN > Disable all rules, Make a new rule:
Action: Pass
Interface: LAN
TCP/IP Version: IPv4
Protocol: any
Source > Type: LAN net
Advanced features > Gateway: OPT1_VPNV4

I used that rule but also added two block rules (one for IPv4, one for IPv6) above it so that anything to the destination of "LAN net" is blocked. In other words no DNS requests can be sent to 192.168.10.1 (the pfSense LAN interface). Blocking all dest LAN net is pretty restrictive, you may not want it.

In any case change the DNS your LAN clients use. I changed the DHCP server for the LAN interface to use Google's DNS servers but you can also use PIA's (209.222.18.222, 209.222.18.218).
Services > DHCP server > LAN > DNS servers > 8.8.8.8, 8.8.4.4

Since I'm not using the DNS forwarder now I turned it off:
Services > DNS forwarder > General DNS Forwarder Options > Enable > UNCHECK

Two things still concern me, I see this in my OpenVPN logs:
Apr 17 00:17:49 openvpn[14080]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Apr 17 00:17:49 openvpn[14080]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

How do I determine the script security level? Is it recorded anywhere and can I or should I change it? And if I specified the ca certificate in the ca.crt file why does it say no verification method has been enabled?

@Hollander:

I still don't understand why all traffic is directed through PIA by default, when PIA is not the default gateway (WAN1, VDSL, is).

I'm pretty sure that's OpenVPN. When you connect to a server I think it runs some command that changes your default route to the address OpenVPN was assigned. It might be the route command, I don't know. Maybe there is an OpenVPN configuration option to stop that from happening?

@gazzaman:

sorry not had chance until now to post these
If you need anymore let me know

Thanks!




[Mr. Jingles]

@brick41:

The next problem I had was DNS leaks. DNS was still going out on the WAN. Is that normal? Did I miss some OpenVPN setting? Anyway I decided to make it so that LAN traffic would go out only over the VPN. Skip the rest of these instructions if you don't want to do that. In other words traffic is blocked when the VPN is down. Here's how I did it, and if this is wrong or is leaky please let me know:

Thanks for your addition to this thread: very useful  ;D

Could I ask: how do you see if there are DNS-leaks?

[Mr. Jingles]

Hmmm, this also still was an open tab in my browser:

http://homeservershow.com/forums/index.php?/topic/5958-pfsense-and-openvpn-problem/

The military man here says that the order of the rules in NAT is important (VPN should be at the top of the list), whereas some comments below it he says this is not necessary if your VPN is the default gateway. However, I have neither: my PIA VPN is not at the top of the rules in NAT, nor is it the default gateway. But I think my PIA VPN is working - looking at the traffic in the GUI, as well as when I look up my own external IP. So apparently what he writes isn't true  ???

[brick41]

@Hollander:

Could I ask: how do you see if there are DNS-leaks?

You could create a firewall rule to allow and log any outgoing traffic on port 53 for the WAN. You should see the only name resolutions will be for pfSense stuff and PIA servers. What's nice about the logging is it deconstructs the packet to determine what hostname was requested to be looked up. If you are interested in logging DNS but just in general check out the thread I started here:
How can I record and maybe monitor all DNS requests and replies?

If you stop DNS outgoing on the WAN there is a "which came first, the chicken or the egg" problem because then how does pfSense lookup the address for the PIA server you're connecting to, or pfSense to check the latest version of FreeBSD?

Also keep in mind about the DNS forwarder if you have that enabled you could leak in certain scenarios. For example I have a pfSense box behind a wireless router. So my router has address 192.168.1.1 and when it assigns an IP via DHCP it offers nameserver 192.168.1.1. So the pfSense WAN IP address is something like 192.168.1.2 for example with nameserver 192.168.1.1. Then the pfSense LAN has a DHCP server (192.168.10.1) that assigns an IP 192.168.10.2 and nameserver 192.168.10.1. When client 192.168.10.2 wants to resolve it sends its request to 192.168.10.1 which is the pfSense DNS forwarder. That then sends the request to 192.168.1.1 which is the wireless router DNS forwarder. I believe that would happen even if I was routing my traffic over OpenVPN because 192.168.1.x is a local route. The setup I have right now is I disabled the pfSense LAN DNS forwarder and the pfSense LAN DHCP instead offers google nameservers. The google nameservers are not a local route so they go over VPN.

@Hollander:

The military man here says that the order of the rules in NAT is important (VPN should be at the top of the list), whereas some comments below it he says this is not necessary if your VPN is the default gateway. However, I have neither: my PIA VPN is not at the top of the rules in NAT, nor is it the default gateway. But I think my PIA VPN is working - looking at the traffic in the GUI, as well as when I look up my own external IP. So apparently what he writes isn't true  ???

That I don't know about, you may have to start a separate thread to ask that question and get someone's attention. In my rules the OpenVPN PIA is first.

Also, unrelated, the biggest issue I've had so far with my setup has been OpenVPN continues to work even after it's terminated due to fatal error. So FYI, you may encounter that. It looks to be a bug.