2.1 / OpenVPN /PIA: can't get it to work
-
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 :-).
-
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
![12. WAN1_default_gateway.jpg](/public/imported_attachments/1/12. WAN1_default_gateway.jpg)
![12. WAN1_default_gateway.jpg_thumb](/public/imported_attachments/1/12. WAN1_default_gateway.jpg_thumb) -
- 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. -
- 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).
-
sorry not had chance until now to post these
If you need anymore let me know
-
Hi else I had to do was create the ca.crt in the txt editor and save it to /etc/ca.crt
-
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 > CHECKIf 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 > UNCHECKThis 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_VPNV4I 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.4Since I'm not using the DNS forwarder now I turned it off:
Services > DNS forwarder > General DNS Forwarder Options > Enable > UNCHECKTwo 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?
sorry not had chance until now to post these
If you need anymore let me knowThanks!
![gw down.PNG](/public/imported_attachments/1/gw down.PNG)
![gw down.PNG_thumb](/public/imported_attachments/1/gw down.PNG_thumb)
![opt1 nat.PNG](/public/imported_attachments/1/opt1 nat.PNG)
![opt1 nat.PNG_thumb](/public/imported_attachments/1/opt1 nat.PNG_thumb)
-
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?
-
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 ???
-
@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.