Setup almost fully working - except for this
-
Hi everyone,
I am missing a piece in my setup I can't figure out, I'm hoping someone has the answer.
Desired state:
Got the latest PFSense running. Have a provider that builds a PPPoE connection over VLAN6. Want to run an OpenVPN server for remote access, forcing all client traffic across, and want an OpenVPN Client (IPVanish) through which all traffic from one box on my LAN is forwarded. I want to use Google DNS servers throughout my network, with the exception of the OpenVPN forced client that should use my OpenVPN provider (IPVanish)'s DNS servers.
Here is my setup:
System / General Setup
DNS Server 1: 8.8.8.8
DNS Server 2: 8.8.4.4DNS server override and Disable DNS Forwarder unchecked.
Reasoning: I expect Google DNS to be used throughout the system, with the exception of the IPVanish OpenVPN Client box.
WAN
The WAN is a PPPoE across VLAN6.
Interface name is WAN_PPPoE.
Created VLAN6, associated with WAN, and then a PPPoE associated with said VLAN6. So WAN interface links to PPPoE0(EM0_vlan6). Works fine.LAN
Default run-of-the-mill static port with IP 192.168.2.2.
DNS Resolver
Stock settings, just the fix put in for Plex (server: private-domain: "plex.direct").
It's listening on ALL interfaces and also sending out on ALL.DHCP Server
Range from 192.168.2.50 through to 192.168.2.149. Everything below that is a static based on MAC address (although handed out/managed through DHCP). I've always much preferred static leases over static IP's. No other changes, just a list of devices with static lease IP's.
No different DNS servers set here - I expect the gateway of 192.168.2.2 to be passed on and therefore the clients to rely on resolution through PFSense.OpenVPN Server
Stock. running on UDP, listening on port 1194. Port automatically opened by wizard to allow traffic on that port in.
Virtual IP range for clients is 10.8.0.0/24.
Redirect gateway checked to force all client traffic across this line.
IPv6 blocked.
DNS server being pushed: 10.8.0.1, the virtual IP of the pfsense box.OpenVPN Client
Pretty much stock - I can't select UDP even though IPVanish supports it:
OpenVPN UDP: Often faster due to having no error correction. Recommended use when target server is in the same continent and the end user is not in a rural area.
TCP: Uses error correction so that lost packets don't have to be retransmitted as often. Recommended for connections to servers that are far away and/or if the end user shows packet loss when connecting to server.
For OpenVPN, we allow connections via TCP or UDP on ports 443 or 1194. The IPVanish software uses port 443.If you check TCP rather than UDP the connection won't be established.
All guides tell you to check "infinitely resolve server".
Encryption settings as per IPVanish config files.
Not forwarding IPv6.
I am pushing some custom options because they are in the IPVanish conf files although most of the ones listed on a guide were already handled via the GUI and thus redundant. This I push:persist-key;persist-tun;persist-remote-ip;tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
My expectation is that when pfsense builds the VPN Client connection it receives an IP and therefore also a gateway/DNS instruction.
This is true - once connected and do a DNSLEAK test, it shows an IPVanish DNS server. More on that in a bit though under questions…Firewall Rules
This is the part where I get lost.
Port forwards were simple enough. Added a few for some of my services.
Now, for the Outbound tab, See attachment 1.The first 4 WAN rules were auto generated, you basically get those on a stock install right. Allowing localhost, the local network range and ISAKMP port 500 to reach the internet. So far so good.
The last two are added in as part of the OpenVPN Server install to ensure the virtual range can go out.
For the OpenVPN Client, the guide says to duplicate every WAN rule (I skipped the last 2 OpenVPN Server WAN rules as I figured those would never send out from an IPVANISH client).Then we have the LAN rules:
See attachment 2.Here is where I attempt to ensure there is a rule to pipe all traffic from 192.168.2.7 through gateway IPVANISHVPN. The second LAN rule, which normally has Gateway * , I changed to have WAN_PPPOE as gateway to send all "other" traffic there rather than through the IPVanish Client.
The IPVANISHVPN Firewall rules tab is empty.
Now, on to my…
…Questions
-
Without the above rules for 192.168.2.7 and WAN_PPPOE as gateway, all traffic from everyone is forced through the IPVanish OpenVPN Client by default. Why? The default gateway is set to PPPoEWAN and each respective Outbound rule lists WAN first and IPVANISHVPN second, why does it send all traffic to IPVANISH by default?
-
As mentioned my DNS servers set in General system setup are Google's. "Allow override from WAN DHCP" is unchecked. However, connecting to IPVanish those DNS servers take over, which is what I would expect as it becomes the client's new gateway. However - if I bypass IPVANISH using the 192.168.2.7 rule and the Gateway=WAN_PPPOE for all other traffic as shown in the screenshot above, clients other than 192.168.2.7 get my WAN IP as expected - but when you go to DNSLeaktest it shows the IPVANISH DNS servers as being the querying party. So rather than the IPVanish IP showing and my ISP DNS leaking, it's leaking the IPVanish DNS to my provider IP connections. Why is it not getting the DNS from Google if I'm forcing it down the WAN gateway?
-
If you stop OpenVPN client on PFSense, OpenVPN Server connected clients resolve DNS like a charm. As soon as I enable OpenVPN Client, the clients connected to OpenVPN Server can no longer resolve DNS. Accessing hosts on my LAN via IP works just fine, and the second I kill the OpenVPN Client DNS resolution also works, but turn it on and DNS for remote clients dies. So there is something in the config with IPVANISH being seen as a default route or something that breaks the DNS returns. Because the DNS Resolver logs show the DNS requests from OpenVPN Server clients coming in (if I try www.yahoo.com or something on a remote machine I see it in the DNS Resolver logs given enough verbosity).
I'd really appreciate it if someone could help me resolve the 3 points above.
Many thanks in advance!
Baldrick
-
-
Anyone have any idea? I didn't think my situation would be that unique - I'm probably missing something small but can't for the life of me figure out what.
Thanks!
-
It looks like this was caused by a route push from my OpenVPN Client. I set "don't pull routes" and that resolved it. I have a DNS leak I still need to fix now but I'll raise a new thread for that in the appropriate forum :)