Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Finger79

Pages: [1] 2 3 4 5 ... 13
1
If I'm running 'Services > DNS Resolver' on PFsense, It looks like (most?) of my DNS queries are still going out the WAN. Is this because the the source IP is 'LAN net' on my VPN policy (ports 80,443,53) and the Resolver is using my WAN IP for the DNS queries (at least what it looks like from tcpdump)?
To fix this, go to Services / DNS Resolver and under "Outgoing Network Interfaces," select only your PIA VPN interface(s) and make sure "All' and "WAN" aren't selected.

This fixes the DNS leak over your regular WAN but introduces the problem that if your VPN ever goes down, pfSense will not be able to resolve DNS to reconnect the VPN.  To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing (Google, OpenDNS, Level 3, Verisign, etc.).  This setting only affects outbound DNS queries by localhost, not by anything on your LAN, which should go out the PIA VPN only via unbound.

This is not entirely true.  You do not need to add a 3rd party DNS for WAN use.

When System >> General DNS "Outgoing Network Interfaces" is configured for a given DNS server, pfSense creates a static route for that DNS entry to go out that interface, but only when that interface is up.  Otherwise the routing is subject to the current routing table default routing, thus DNS queries will go out the default route, usually the WAN.  (This also applies to policy routing rules, which are only added after the target gateway interface is online.)  So you have to plan routing and rules in two states; 1) When VPN links are down and WAN is default route, and 2) when VPN links are up.

What's missing in the DNS routing is configuring Unbound to use localhost for outbound queries so that outbound DNS queries go through default routing.  If Unbound is configured to only use the VPN links as outbound interfaces, then of course those interfaces will not be usable when the VPN is down, and Unbound will have no other interface for outbound queries.

Additionally to really prevent unexpected DNS leaks, and extra query traffic, especially when using multi-wan / multi-vpn, configure Unbound to only use localhost for outbound. 

The reason is that Unbound will try to query all configured DNS servers on each configured outbound interface directly, bypassing the route table, and then manage responses accordingly, which results in leaks if WAN is configured as an outbound interface, and lots of extra activity if you have multiple links.  Configuring Unbound to only use the localhost for outbound not only limits the amount of queries outbound attempts, but also subjects all outbound queries to NAT'ing and routing.  Thus when the VPN links are down, dns queries are routed out the default route, which should be the WAN, but when the VPN links are up and are the default route, DNS queries go out the VPN default routes (either by default or as configured for "Outgoing Network Interface" once the link is up.  When Unbound is configured to use only localhost as outbound, you do not need to configure an DNS outbound interface under System >> General (unless you have disabled pulling routes in the VPN client.) as outbound queries from localhost will go out the VPN link once it becomes the default route.

And as an added note: Since PIA does not support IPv6, Unbound needs to be configured to disable IPv6 queries, otherwise there is a bit of a performance hit with all DNS queries as it wil try to resolve both A & AAAA records for all queries.  Add the Unbound configuration directive "server: do-ip6: no" to turn off AAAA record queries.


Very interesting.  Thanks for the info!

you do not need to configure an DNS outbound interface under System >> General (unless you have disabled pulling routes in the VPN client.)
It's frequently advised in the forums here to disable pulling routes in OpenVPN client config.  Lots of people do that, which helps with policy-based routing.

2
i am following the newest guide:

https://www.privateinternetaccess.com/forum/discussion/29231/tutorial-pia-on-pfsense-2-4?new=1


i also posted an updated link just about the top page of 22.  from a PIA staff
Their guides are never perfect.

Quote from: Guide
14.) Ensure NCP is checked.
       Remove AES-128-GCM and AES-256-GCM by clicking on them in the darkened box in NCP Algorithms
       Add AES-128-CBC and AES-256-CBC  by selecting them in the left box.
This is stupid and defeats the purpose of NCP in OpenVPN 2.4 which automatically negotiates the NCP ciphers if both client and server support NCP.  NCP should remain set to AES-256-GCM and/or AES-128-GCM.  And the traditional cipher should be set to AES-256-CBC or AES-128-CBC.

Quote from: Guide
17.) Custom Options: Add these parameters:

          persist-key
          persist-tun
          remote-cert-tls server
          reneg-sec 0

"persist-key" and "persist-tun" are already hard-coded in pfSense's OpenVPN implementation and are redundant if specified here.  They should be left out because all this does is list the directives twice in the config file.

Mine are currently set to:

Quote
# Advanced Configuration Settings from GUI
remote-cert-tls server
auth-nocache
tls-version-min 1.2
reneg-sec 0
pull-filter ignore "auth-token"

I learned a lot from reading the OpenVPN 2.4 Manual.  Took several hours over several days before I had a basic understanding of how to harden the config settings.  The pull-filter ignore "auth-token" is my latest addition since I was having issues with the session token expiring and the VPN would never automatically reconnect by itself.  Adding that directive keeps pfSense connected to PIA 24/7 and automatically reconnects.

3
If I'm running 'Services > DNS Resolver' on PFsense, It looks like (most?) of my DNS queries are still going out the WAN. Is this because the the source IP is 'LAN net' on my VPN policy (ports 80,443,53) and the Resolver is using my WAN IP for the DNS queries (at least what it looks like from tcpdump)?
To fix this, go to Services / DNS Resolver and under "Outgoing Network Interfaces," select only your PIA VPN interface(s) and make sure "All' and "WAN" aren't selected.

This fixes the DNS leak over your regular WAN but introduces the problem that if your VPN ever goes down, pfSense will not be able to resolve DNS to reconnect the VPN.  To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing (Google, OpenDNS, Level 3, Verisign, etc.).  This setting only affects outbound DNS queries by localhost, not by anything on your LAN, which should go out the PIA VPN only via unbound.

4
i've followed the instructions above and now i am getting several events in the logs

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'

WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

seems like several red flags.  what is everyone's opinion on this?

I get the 'link-mtu' warnings as well.  The Blowfish/SWEET32 warning is because PIA can't competently maintain their systems (and I'm a customer!) and still defaults to BF-CBC instead of at least AES-128-CBC.  They really should be using the latest OpenVPN 2.4.4 with NCP support.  As much as I like PIA, they can be a real frustrating PI[T]A....

As long as you (the client endpoint) have your config set to use AES-128-CBC or AES-256-CBC, it'll override the server settings, so don't worry about that warning.

5
[Edit:  Oops, I didn't read the entire thread first.  You already bought a beefy Poweredge T30 a couple months ago.  Woot.]

If that's overkill, what about using something like ESXi to run pfSense (and other services) in a virtual machine? I know it's possible, but is it a good idea (in the eyes of the pfSense community)?
I'll add my two cents to this one.  One of the lessons learned at a past company (when we lost power to the datacenter because of catastrophic UPS failure duriing a UPS test on a Monday at noon (go figure...idiots in charge), and recovery took 12-24+ hours... losing millions of $$$) was that critical infrastructure (such as our DNS servers and Domain Controllers) were 100% virtualized.  And the back-end storage arrays for all these virtual servers?  Since the array lost power abruptly it had to go through a lengthy disk check, which took hours.  Meanwhile, since none of the servers that *were* up and running had any DNS, they were sitting ducks and useless.

Lesson learned:  Virtualization is awesome, but don't virtualize 100% of your critical infrastructure.  Always have at least one physical device per infrastructure type.


This is probably apples and oranges compared to a home environment, but if you want to virtualize pfSense in ESXi or any other hypervisor, just be aware that if the physical host fails or has to be rebooted (etc), your pfSense router, firewall, DNS, DHCP, and any other critical services will be down during that time.  So for highest availability, have at least one physical pfSense device, and feel free to virtualize the others.  Or have two virtual pfSense instances on two separate physical ESXi servers.

Totally overkill answer, especially for home.  But it was a painful lesson learned and one I will always think about when I implement infrastructure, even at home.  :P

6
Side note:  PPTP was publicly known to be insecure no later than December 2004.  Can I ask why you're still using it in ~2018 instead of a commercial TLS VPN, OpenVPN, or IPsec?

7
Post a bounty / Re: Temperature Fahrenheit /Celsius Option and Alarms
« on: December 12, 2017, 06:16:02 pm »
https://github.com/pfsense/pfsense/pull/3891

This patch adds a preference to the thermal sensors widget, which is also read by the system information widget.

Notification is the job of a network monitoring system, not pfSense. (Your pfSense can't email you about high temperatures if its CPU is a puddle of molten slag!)


Looks awesome, sir!  Hope they merge the PR.

Was curious, maybe a quick Find & Replace:
* getCelciusValue() --> getCelsiusValue()
* celc --> cels

8
Post a bounty / Re: Temperature Fahrenheit /Celsius Option and Alarms
« on: December 06, 2017, 06:47:34 pm »
If Fahrenheit is selected, I'd like to only see Fahrenheit in the UI, not both.

9
@Haze028, I noticed your LAN network is 150.160.170.0/24, which is a public IP range.  If you haven't purchased or otherwise own this block of IPs, you should stick with private IP ranges.

10
Also, can't you just set up DHCP to give the IP address of your AD Domain Controller for DNS?  This way all Windows clients in your Winlab will send all DNS traffic to the domain controller instead of to pfSense.  This is simpler than the port forward option above.

11
Maybe look at modifying this article to meet your needs:  Redirecting all DNS Requests to pfSense

So maybe something like:
Interface: [Whatever your Winlab interface is]
Protocol: TCP/UDP
Destination: Invert Match checked, Winlab Address
Destination Port Range: 53 (DNS)
Redirect Target IP: [IP address of Active Directory domain controller that does DNS]
Redirect Target Port: 53 (DNS)
Description: Redirect Winlab DNS
NAT Reflection: Disable

12
Why should netflix work and amazon not?  That is fairly backwards
That's never made sense to me.  All else being equal, why would Amazon work when using the Asus router for OpenVPN but Amazon doesn't work when using pfSense for OpenVPN?  So weird.  lovan6 says the configurations are exactly the same, which means we should expect the same results.  *shrug*

13
Yes - It is very odd that netflix would work but not amazon.  Its probably a simple fix.  We can see after you post your final configuration. 

This could be a DNS issue.  You might want to find out if your VPN provider has their own dedicated reliable DNS IP and use that. 

The problem I have with 8.8.8.8 and 8.8.4.4 is those can connect you to many different servers depending on your location.

In my laptop off the VPN from Manila when I ping 8.8.8.8, its 30ms

When in my vpn I use my remote pfsense LAN IP as my DNS server IP.  When I ping that IP, it shows about 250ms.  Far away as it should be.

When I ping 8.8.8.8 in the vpn, again over 250ms.  So, it is being tunneled properly.

We might want to do that test with you to be sure that the DNS servers you are connecting to are physically in the USA and not close by.

Could be something else though.  Not sure.  Its strange.
He's using unbound for DNS resolution though.  The Google 8.8.8.8/8.8.4.4 settings are only used by the pfSense box if the VPN tunnel goes down.  No LAN DNS queries should be forwarded to Google DNS.

14
I have a question because I have the same dilemma. If I am using 3 OpenVPN connections for my Outgoing DNS Resolver settings I would select all 3 for the Outgoing Interfaces.  But, when Unbound is doing the resolving will it send a query out to all 3 Interfaces or only 1?

I also have a Gateway Group that is setup for fail-over purposes for the OpenVPN not sure if that matters as to whether or not Unbound will send a query to all interfaces or just the one that traffic is suppose to be going out at that time.

Unbound sends DNS queries out all interfaces.  You can verify this from a DNS Leak tester such as this one:  https://www.dnsleaktest.com/ and click on "Extended Test."  You'll see the IP addresses for all 3 of your OpenVPN connections.

15
I followed your suggestions on the NAT outbound.
Dude, you're tweaking mah OCD.  :P  I'd edit your Descriptions for sanity purposes as in my screenshot.  Just two edits.  "LAN to ExpressVPN" and "localhost to ExpressVPN"

Pages: [1] 2 3 4 5 ... 13