Tutorial: Configuring pfSense as VPN client to Private Internet Access
-
You need to get proof that the port is properly forwarded to you. Turn logging on on the pass rule, check the logs. Attempt a connection, check for states. Do a packet capture on WAN. Do you see the inbound packets? Do a packet capture on LAN. Do you see the outbound packets? What is returned from 192.168.1.248?
You also need to test from outside.
Do all this. Don't skip anything:
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
-
Nice one, I'm on it…
-
Ok, we have some results,
Firewall checks, with logging on the forwarding rule and utorrent running on 62465, I'm also repeatedly trying to connect externally using a 4g connection (timedout everytime i tried a connection):
I can find loads of outgoing LAN entries on 62465, see first screenshot, nothing at all on TORGUARDICELAND or WAN for 62465.
I cant see any logged entries with a destination port 62465 on any interface, I also cant see anything with a destination 192.168.1.248. As far as i can tell nothing is triggering the forwarding rule. See screenshot 2States:
There are plenty of entries in the states table for port 62465, see screenshot 3. I can't find my external connection in the table but since it keeps timing out that doesn't surprise me…
Packet capture:
On WAN i get only a tiny handful of packets coming in to 62465 from outside to my WAN IP, i.e. the IP assigned to my modem. I assume this is just random non-requested traffic. See screenshot 4. There is plenty of 443 activity between my VPN IP and my WAN IP, i assume this is the vpn tunnel.
I can see plenty of LAN activity on 62465, both inbound and outbound, see screenshot 5. The incoming packets and the returns have different lengths, incoming are short, are these errors of some kind?
On TORGUARDICELAND I can see some packets coming from 10.8.0.6 (the VPN interface virtual address) to my VPN IP and the other way, this seems hopeful! See Sh 6.
I went through the common problems on the list, I think I can tick off all of them, the fact that the forwarding works when using my regular connection instead of the vpn connection dealt with most of them.
Phew, never even seen a states table before this, this is a proper learning experience ;) Hope I've done the correct testing, interpreting these results is killing me though, anything obvious catch your eye? Thanks
 -
If they are supposed to be forwarding a port to you and you have logging on the pass rule for the NAT entry on TORGUARDICELAND and you never see any log entries when you try to connect to it from the outside, their forward isn't working and there is no reason to look at anything else.
-
Good advice! After a spanking Torguard fessed up and got things working, the port is open :) I swear to god I'm happier seeing this port open than I was when I saw my first girlfriends legs open, its been one frustrating week…
Mate you've been truly awesome, thanks for the help and patience
-
I'm trying to allow both VPN and local Lan users to access a networked printer. Is there a way to do this? I've searched the forums and found pieces but no straight tutorial. Thanks!
-
I'd start a new thread.
-
slow speeds on 2.2.4?
I am not sure if it's me or something to do with the new update.
-
I'd start a new thread.
-
This is probably a dumb question, but how can I make sure connections don't go out via my WAN gateway if the VPN drops? I've tried a few things, but every time I shut down the VPN service and check my connected devices they have reverted back to using my WAN gateway.
–-EDIT---
Based on what I read in another thread I created a floating rule blocking WAN access to my VPN connected devices and that seems to be working okay.
-
This is probably a dumb question, but how can I make sure connections don't go out via my WAN gateway if the VPN drops? I've tried a few things, but every time I shut down the VPN service and check my connected devices they have reverted back to using my WAN gateway.
–-EDIT---
Based on what I read in another thread I created a floating rule blocking WAN access to my VPN connected devices and that seems to be working okay.
This is how I would do it:
https://forum.pfsense.org/index.php?topic=84463.msg463226#msg463226
-
pfSense 2.2.4:
Thanks to Derelict –- if my VPN goes down I do not have VPN traffic getting out through my WAN interface. yay.
My openvpn config uses us-midwest... and my DNS entries under General Setup are 208.67.222.222 and 208.67.220.220. This works great, except I get DNS leakage on my VPN client machines.
In General Setup I changed DNS settings from opendns IP addresses to PIA IP addresses and at that point us-midwest... can't be resolved so openvpn fails to start up.
I thought about replacing the us-midwest... with its IP address --- bad idea, so I didn't do that. Instead, I put my opendns IP addresses back in General Setup. Then I hardcoded the PIA DNS addresses into my client computers. The result is that each client that's using the VPN does NOT leak DNS. While the end result is desirable, the method sucks.
I'd prefer a better solution, but I'm at a loss to figure it out.
It would be great if I could use opendns IP's for my traffic going out the WAN interface and PIA IP's for my traffic going out the VPN interface. And, also that us-midwest... is resolved properly when openvpn starts up.
-or- Use PIA IP's for all DNS resolution and, of course, have us-midwest... resolved when openvpn starts up.
Anyway, I'm for a 'best of breed' solution here. I'll take all the help I can get, and a great big thanks ahead of time!
Please realize I'm not far from being a newbie here and gently guide me in the right direction(s). :)
EDIT: I decided to play around a little more and set the DNS entries under General Setup to the PIA IP addresses. I started the reboot of pfSense and got a phone call and went away for 15 minutes. Upon my return I was delighted to see that my openvpn actually came up! It -did- have the us-midwest... resolution problem, like before, but apparently after a time resolved itself and came up ---- yay! So --- it all works exactly as envisioned now.
What remains? I'd still like to know if I could use PIA IP's for my openvpn vpn clients and opendns IP's for my WAN clients?
EDIT2: Well, I just did a dnsleak test and it leaks .... shows the wan IP and not the pia IP ---- dang!
ok --- I yield and wait. Help?
-
The answer is to set DNS servers using a DHCP static mapping to something external on the VPN-only hosts and to not set them to use pfSense itself as the DNS server. That way, the DNS queries will be just another internet packet, will be marked by the same rule, and will be blocked out WAN by policy automatically.
Trying to get pfSense DNS forwarder or resolver to behave in a specific way according to the specific source host is folly.
-
Thanks for the speedy reply.
I went to my DHCP entry for 192.168.1.205 and set its DNS IP's to the PIA addresses. (My General Setup IP's are opendns)
From the 192.168.1.205 client i flushed the dns cache and released/renewed its DHCP loan. ipconfig shows 192.168.1.1 as the DNS server. My hope was that DHCP would loan the actual PIA addresses and not the 192.168.1.1 that it actually loaned.
Well, the DNS leaks.
Did I take the right approach to defining the PIA DNS IP's in DHCP or am I going in the wrong direction?
-
What PIA address.
Do the rules that forward your traffic (and mark it to block it out WAN) match DNS traffic?
If you are querying 192.168.1.1 for your DNS, then you are still querying pfSense and the DNS traffic is sourced from there not the VPN host.
It doesn't matter what the VPN host uses for its DNS servers as long as they are external and the rule that forwards traffic to the VPN and marks it matches the DNS requests.
-
Sorry for the late response … my ISP is having huge issues and I could not access anything for a while.
ok ... I have protocol set to "any" where I'm marking traffic so the rule should catch everything.
I decided to hard code the PIA DNS servers IP's into each client machine. All non-VPN client machines are using pfSense 192.168.1.1 from DHCP. This all works perfectly, no DNS leaks, VPN traffic of any kind does not leak to the WAN -- just works.
I only wish it was possible to have my pfSense deliver the desired PIA DNS IP's to the VPN client machines. oh, well, dang thing marks marvelous, as long as I have the DNS IP's hardcoded so I'll stick with that I think.
But ----- again .... thanks for information about tagging the traffic so VPN traffic doesn't leak into the WAN ------ BIG kudos. ;D
-
DHCP static mappings will set the right DHCP servers for those clients.
-
I have static DHCP mappings for all my clients, non-VPN, and VPN alike. I've tried setting my General Setup DNS to opendns. Then set the overall DNS in DHCP to opendns. Then I manually set non-VPN clients to opendns (for testing). Then I set the VPN clients to use PIA DNS addresses.
Result: The non-VPN work predictably, just like before and like they should. The VPN clients simply will not use the PIA DNS addresses, it seems.
I tried turning off all DNS server functionality of pfSense, along with a setting in DHCP, to force DHCP to deliver the actual DNS addresses to the client machines …
I released my client DHCP loans and renewed ...
Something in pfSense seems adamant that I have the PIA DNS addresses hard coded in the client machines because they still leaked the ISP address.
-
Result: The non-VPN work predictably, just like before and like they should. The VPN clients simply will not use the PIA DNS addresses, it seems.
No need for nebulous descriptions like "work predictably" and "will not use"
What DNS Server IP addresses are being assigned to the various clients?
When you attempt name lookups from those clients, what are the specific results?
This stuff is not subjective. It either works or it doesn't and there are ways to debug exactly what is failing.
ping, dig/drill, firewall logs, traceroute, etc.
-
In my pfSense DHCP server:
For non-VPN users DNS addresses are:
208.67.222.222
208.67.220.220For VPN users DNS addresses tried were:
209.222.18.222
209.222.18.218and sorry for my nebulous descriptions of things previously … I'm at work right now and will be available for testing in about 30 minutes ...
