pfSense_fan

Go to the package manager and install "Service_Watchdog" package. It monitors for stopped services and restarts them.

Once installed, configure it and make sure openvpn is monitored.

By the end of this guide, the firewall rules look like:

 

 ____________________________________________________________________________________________________________________________________________
| Proto     | Source               | Port  | Destination        | Port               | Gateway      | Queue | Schedule | Description        |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| *         | *                    | *     | AirVPN_LAN Address | 443                | *            | *     |          | Anti_lockout Rule  |
|           |                      |       |                    | 80                 |              |       |          |                    |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4      | AIRVPN_LAN net       | *     | 192.168.1.1        | 53 (DNS)           | *            | None  |          | NAT AirVPN LAN     |
| TCP/UDP   |                      |       |                    |                    |              |       |          | DNS REDIRECT       |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4 UDP  | AIRVPN_LAN net       | *     | 192.168.1.1        | 123 (NTP)          | *            | None  |          | NAT AirVPN LAN     |
|           |                      |       |                    |                    |              |       |          | NTP REDIRECT       |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4      | AIRVPN_LAN net       | *     | PRIVATE_NETWORKS   | *                  | *            | None  |          | ALLOW LOCAL        |
| ICMP      |                      |       |                    |                    |              |       |          | ICMP               |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4*     | AIRVPN_LAN net       | *     | LOCAL_IP_MULTICAST | *                  | *            | None  |          | AirVPN_LAN IP      |
|           |                      |       |                    |                    |              |       |          | MULTICAST          |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4      | AIRVPN_LAN net       | 1024  | PRIVATE_NETWORKS   | LAN_SERVICE_PORTS  | *            | None  |          | ALLOW LOCAL        |
| TCP/UDP   |                      | -     |                    |                    |              |       |          | SERVICES           |
|           |                      | 65535 |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4      | AIRVPN_LAN net       | 1024  | *                  | WAN_SERVICE_PORTS  | AirVPN_WAN   | None  |          | AirVPN_LAN         |
| TCP/UDP   |                      | -     |                    |                    |              |       |          | ALLOW              |
|           |                      | 65535 |                    |                    |              |       |          | OUTBOUND           |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________|
| IPv4*     | AirVPN_LAN net       | *     | PRIVATE_NETWORKS   | *                  | *            | None  |          | REJECT LOCAL       |
|           |                      |       |                    |                    |              |       |          |                    |
|           |                      |       |                    |                    |              |       |          |                    |
|___________|______________________|_______|____________________|____________________|______________|_______|__________|____________________| 

The two lines above the final line are allowing local and outbound traffic on approved ports.  But, looking at those lists of approved ports:

 

LAN_Service_Ports:
[ 21           ] [ -- ▼] [ FTP control (command)							]
[ 22           ] [ -- ▼] [ Secure Shell (SSH), file transfers (scp, sftp)	]
[ 80           ] [ -- ▼] [ Hypertext Transfer Protocol (HTTP)				]
[ 161          ] [ -- ▼] [ Simple Network Management Protocol (SNMP)		]
[ 443          ] [ -- ▼] [ Hypertext Transfer Protocol over TLS/SSL (HTTPS)	]
[ 990          ] [ -- ▼] [ FTPS Protocol (control), FTP over TLS/SSL		]
[ 1024:65535   ] [ -- ▼] [ Registered and Ephemeral Ports					]

WAN_Service_Ports:
[ 21           ] [ -- ▼] [ FTP control (command)                                                    ]
[ 43           ] [ -- ▼] [ WHOIS protocol (If you use a WHOIS program to attain host records)       ]
[ 80           ] [ -- ▼] [ Hypertext Transfer Protocol (HTTP)                                       ]
[ 143          ] [ -- ▼] [ Internet Message Access Protocol (IMAP), management of email messages    ]
[ 443          ] [ -- ▼] [ Hypertext Transfer Protocol over TLS/SSL (HTTPS)                         ]
[ 990          ] [ -- ▼] [ FTPS Protocol (control), FTP over TLS/SSL                                ]
[ 993          ] [ -- ▼] [ Internet Message Access Protocol over TLS/SSL (IMAPS), I.E. Secure email ]
[ 1024:65535   ] [ -- ▼] [ Registered and Ephemeral Ports                                           ]

I've got to ask:  since the approved ports both contain the range of all Registered and Ephemeral Ports [1024:65535] (which works out to 64,511 ports), why bother with being specific with the remaining 6 or 7 named ports below 1024?  Why not just leave the port Aliases off those rules entirely and just allow all internal and outgoing traffic (which, I believe, is the default firewall behavior).  Especially for a home network (though, not everyone reading this will be on a home network).

 

EDIT:  And while I'm questioning those rules and aliases, why are the source ports in those two rules restricted to 1024:65535 while the destination ports are restricted by those aliases to that range plus those 6 or 7 named ports?  Why not leave the source ports blank?  Plus, if we remove the aliases from the rules, the two rules could be combined into one "allow all outbound traffic" rule.

Then you did not follow and read the links to more info I left on the step in the guide that deals with this. There is every reason in the world to limit them in that port range.

From Wikipedia:

The port numbers in the range from 0 to 1023 are the well-known ports or system ports.^[6] They are used by system processes that provide widely used types of network services. On Unix-like operating systems, a process must execute with superuser privileges to be able to bind a network socket to an IP address using one of the well-known ports.

Those ports should never be in use without explicit permission. Not allowing ones that are not in use stops any malicious activity on those ports without intervention. As far as the outgoing NAT excluding them? Those are service (server) ports and traffic should never originate from those ports, hence not allowing outgoing NAT from that port range should have ZERO effect on users.

Okay, I read all 15 pages, however I may have simply overlooked it. 

 

How do I only allow certain IPs to go on the VPN? I do not want all of the traffic to route over the VPN.

You make an outbound NAT rule for the range of local ip addresses you want to exit the clear internet, and another for the local IP addresses you want to exit the vpn.

Once thatis done, you make outbound firewall rules for those local IP address ranges, and specifying which gateway those ranges will exit.

It's only a slight adjustment to what the guide teaches. It is called policy routing, and the guide explains how it is accomplish by setting the VPN WAN for the outbound firwall rules.

https://doc.pfsense.org/index.php/What_is_policy_routing

I'm just checking back in as the only major thing remaining on my "I want to do with pfSense" (I've cracked VPN and traffic shaping - remote access almost done) is setting up a proxy.  Is there definitely no way to use Squid with this setup with leakage?  Maybe it's possible to use squid for non-vital IPs/devices, with other devices going via the VPN?

 

Or, are there other proxies/methods available that do work?

What are your goals for using squid? I can give you an answer if I know what you are trying to accomplish.

 

This is probably just an irrelevant typo, but I thought I'd ask to be sure.  In the instructions at "Step 1-A: Disable DHCPv6 on WAN Interface", it implies we should rename the WAN interface "Wan_dhcp."

 

"1.) Go to: Interfaces / WAN...

 

Set as Follows:

--------------------------------------------------------------------------------------------

 General configuration

--------------------------------------------------------------------------------------------

                Enable = [√] (CHECKED)

--------------------------------------------------------------------------------------------

           Description = [ WAN_dhcp ]"

 

I just double-checked and the only other place in the instructions where "WAN_dhcp" shows up is in the tables of what our Gateways should look like in "Step 4-B: Setting the AirVPN Gateway" (System / Routing).  The originally named "WAN" is referenced everywhere else.  I've used "WAN_dhcp" everywhere.  Is this OK?

You need to understand that with each incremental update, the pfSense team makes minor GUI updates. They frequently change the way "buttons" look and the wording on them.  I worked on this guide over the course of 6 or more months, some minor changes in the GUI show because of it.

 

 

 

The tick box for the negate rules should not be skipped. It literally makes your ip leak if a vpn goes down by redirecting rules/gateways

 

We want it to only use our manually created rules, causing the connection to drop if the vpn goes down.

I wish more people would ask questions and discuss this in the main post. The whole community would benefit from the open discussion.

I didn’t start this thread, just answered it to the best of my limited ability, I agree this should be in the main thread.

I did say I don’t endorse skipping rules, you put a lot of effort into your guide and I like many people are very grateful, without it I doubt I would be online now.

I note your point about negate rules but I have a wan_egress floating rule, its a remnant from using another vpn service where the guides where far less informative and being a bit green behind the ears I thought it was a good way to kill traffic if the vpn goes down, that’s just me and I made no mention of it here in case it was bad practice.

The idea behind my replying to this post was to not only answer my own post but to reply to someone else who had trouble setting up pfsense, my thinking is during initial setup it may help to get the vpn up and then once proven, move right on to the rules and tweaks, I should have made that more clear.

--

Quite the opposite, an egress rule is a great practice. I never got around to playing around with it. If you care to share what you did in a PM, perhaps I can add it to the guide.

No offense was taken and I never said i was accusing you of such comments... i just "think out loud".

Also, the nguvu guide and mine are a collective effort, so yes it is good info too. My personal setup is similar to that guide.

If your following pf-fans excellent guide here :

 

https://airvpn.org/topic/17444-how-to-set-up-pfsense-23-for-airvpn/

 

Then do steps 1 to 6 , that should be enough to get you online and on the vpn, pay close attention to each step regarding entering the certs and section 6, that part can cause trouble if not done in the correct way.

 

This is exactly the way I did it BUT I skipped the rules and tweaks after section 6 to simplify things. Read through each step carefully.

 

I in no way endorse skipping the rules, they are done for a reason after some long and tedious study but each set up is different, for simplicity I skipped creating them to get the vpn up and running then created my own rules as needed.

The tick box for the negate rules should not be skipped. It literally makes your ip leak if a vpn goes down by redirecting rules/gateways

With Multi-WAN it is generally desired to ensure traffic reaches directly connected networks and VPN networks when using policy routing. This can be disabled for special purposes but it requires manually creating rules for these networks.

We want it to only use our manually created rules, causing the connection to drop if the vpn goes down.

I wish more people would ask questions and discuss this in the main post. The whole community would benefit from the open discussion.

 

 

Hi,

 

great guide: I followed it with my opnsense (pfsense's fork) box and all works very well.

 

I would like also to use a forward proxy (squid) on my opnsense box and force it to use vpn connections but until now I dont'be able to get (squid uses always default gateway).

 

I would like to know if you have any suggestions on this argument.

 

Thanks in advance

 

I had the issue with squid, it would always leak no matter what i tried on the same instance, i got around the problem by installing win server 2012 on the machine, then creating 2 X Hyper-V machines one for the VPN using this tutorial and the 2nd handles the DHCP and squid, the author himself said on the old thread of this tutorial that getting both VPN and squid to work together does not work.

 

Thanks for your reply Mufasa,

 

I adopted a similar solution (I used a linux virtual machine with squid proxy) but it seems very strange not being able to run squid proxy on pfsense/opnsense on the same machine: I tried with some firewall rules (both on LAN side and floating rule side) without success.

 

I will try again (I do not give up).

It will not work and cannot work unless you manual program static routes. The proxy is coded to exit the WAN/default gateway and there is no setting to policy route it to the VPN. Setting this up is something that is well outside the scope of what this tutorial is intended for, and something that quite literally probably no one at this forum can assist with. If you truly want squid to work, ask questions over at the pfSense forums. This guide is meant to be entry level for beginners. Setting up Squid is very involved. Even if you get it to "work", it may leak. I personally gave up on it.

If you were to ask me, I would tell you to look into pfblockerNG instead. I have it running and blocking roughly 600,000 known ad servers, malware servers and other junk on both a DNS and IP level. The lists auto update and reload on a schedule. But then again, I don't know what your use case is. For what it's worth, pfblockerNG is easier to use, set up and more reliable in my experience.

EDIT: Then I noticed you are on opnsense. Consider moving back over to pfSense for pfblockerNG... it really is the game changer.

Did you also create an outbound NAT rule for the subnet of your DMZ?

Have you cleared your browser cache?

Have you ensured webrtc is disabled in your browser?

You actually can get it working in far fewer steps than are in my guide, but you are not 100% protected from leaks. My guide goes the extra mile to knock out a number of other basic privacy and security precautions.

pfSense also can get much higher speeds through the VPN since almost any pc equipment will be much more powerfull than a consumer router.

Not sure if I am following you, but you can use a public dns through the vpn. Just change the 10.4.0.1 on the general page to whatever you choose, just have it use the AirrVPN_WAN as the outgoing interface.

If you really want to get into it, set up a second openvpn client/interface and have that client connect to the AirVPN server closest to you, and use that for DNS only.

@ JacksonLee

Yes.

I use these.

I've never had it until yesterday when I was having connection issues. I could only get 2Mbps and was disconnecting frequently, so i checked my logs. Tried a number of servers, all the same. I did a web search and one of the top hits was this post. Seems odd though that a few of us had the same "issue" in such a small window.

It went back to normal late at night, but right now its back at 2Mbps. I'm going to try some things to see if I am throttled.

If you used my guide, this is a caveat of that, you must use direct IP for clients. You are better off that way anyway as you are leaving a trail with a third party that your are connecting to a VPN service. That being said, I did make a provision in the client settings that will automatically connect to another server if the one you are using goes down.

### Use Multple "remote" entries with the according entry IP address of your favorite servers       ###;

### other than the server entered in the "Server Host or Address" entry above and pfSense           ###;

### will automatically recconnect in a round robin fashion if the server you are connected to       ###;

### goes down or is having quality issues. Edit and uncomment the fake lines below or add your own. ###;

remote XX.XX.XX.XX 443   ###AirVPN_US-Atlanta-Georgia_Kaus_UDP-443###;

remote XXX.XX.XX.XXX 2018   ###AirVPN_US-Miami_Acamar_UDP-2018###;

remote XXX.XX.XX.XXX 2018   ###AirVPN_US-Miami_Yildun_UDP-2018###;

remote XX.XX.XX.XX 53   ###AirVPN_US-Miami_Cursa_UDP-53###;

remote XXX.XX.XX.XX 443   ###AirVPN_CA-Dheneb_UDP-443###;

remote XXX.XX.XXX.XXX 443  ###AirVPN_CA-Saiph_UDP-443###;

I am also getting this and my logs are flooded with the same message. This is new, it has never been in my logs before.

I can still connect and seemingly use the vpn but it has frequent disconnects and my speeds are much lower than normal.

I've tried changing servers to no avail.

Nov 27 21:09:11 openvpn 32834 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock

Nov 27 21:09:06 openvpn 32834 MANAGEMENT: Client disconnected

Nov 27 21:09:06 openvpn 32834 MANAGEMENT: CMD 'status 2'

Nov 27 21:09:06 openvpn 32834 MANAGEMENT: CMD 'state 1'

Nov 27 21:09:06 openvpn 32834 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock

Nov 27 21:09:01 openvpn 32834 MANAGEMENT: Client disconnected

Nov 27 21:09:01 openvpn 32834 MANAGEMENT: CMD 'status 2'

Nov 27 21:09:01 openvpn 32834 MANAGEMENT: CMD 'state 1'

Nov 27 21:09:01 openvpn 32834 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock

Nov 27 21:08:51 openvpn 32834 MANAGEMENT: Client disconnected

Nov 27 21:08:51 openvpn 32834 MANAGEMENT: CMD 'status 2'

Nov 27 21:08:51 openvpn 32834 MANAGEMENT: CMD 'state 1'

Nov 27 21:08:51 openvpn 32834 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock

Nov 27 21:08:47 openvpn 32834 MANAGEMENT: Client disconnected

Nov 27 21:08:47 openvpn 32834 MANAGEMENT: CMD 'status 2'

Nov 27 21:08:47 openvpn 32834 MANAGEMENT: CMD 'state 1'

Nov 27 21:08:47 openvpn 32834 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock

Nov 27 21:08:45 openvpn 32834 Initialization Sequence Completed

I've been searching the web for a while now trying to pinpoint a cause, not finding anything helpful.

Staff, any insight what this may be and a resolution?

The "EEE" or Energy Efficient Ethernet tweak has nothing to do with DNS. It can cause issues with DHCP though.

I too have had intermittent access to ipleak.net. I have chalked it down to using DNSSEC in combination with Air's DNS servers.

Turning DNSSEC completely off and letting the system DNS cache enough time to clear fixes it, as does using another DNS Server.

 

Worth going over the guide setting by setting, its so easy to make a mistake or one wrong check box or tick ! in fact I have yet to get it fully working myself. I had no websites when I first did the new updated 2.3 guide but then forgot I have 10.4.0.1 under my network adaptor DNS server settings under TCP/ipv4.

 

Hi,

 

Thanks for the reply. Although it's not really helpful. I redid the settings 3 times (one time with a complete fresh install of pfsense). Our router and server are my responsilbility, but my girlfriend is actually much better with computers, so I put aside my pride and asked her to check the configuration. She also didn't find a wrong setting. I then decided to (temporarily) move back to the 2.1 settings, but this guide got updated ever since I first used it. So even with the less secure settings, we had the same problems.

 

I then googled for an alternative guide and found one by nvugu

I roughly followed the guide; I don't need vlans, so I combined the applicable firewall and nat rules from the VPN and MGNT (anti lockout) vlan. I also disabled ipv6 as mentioned in the beginning of this topics guide. We now have smooth internet browsing and all ports seem to be closed, unless I specify them in the port alias. I don't know a lot about firewalls, so I don't know what the exact differences between the guides are. What I did notice though was nvugu doesn't use 'DNSSEC' and the "Experimental Bit 0x20 Support" and the DNS firewall rules are different.

After setting it up, how long did you let the DNS Resolver (Unbound) run before attempting to change a setting? DNSSEC requires a bit of time to negotiate. Another possibility is that DNSSEC is not available on all air servers, I can't be sure of that. I do use these settings so I know they work.

That being said the only appreciable difference between that guide and mine is DNSSEC. I am considering removing DNSSEC from the basic guide and moving the option to an additional/optional step.

Not exactly sure why, but the configuration for 2.3 you have above would NOT function properly with multiple (3) interfaces. Ended up wiping the configuration and creating one from your 2.1 guide, and it worked fine. Not sure why the upgrade killed the configuration either, but at least I'm up and running again.

It does work.

Unlike the old guide, the 2.3 guide is very close to how I actually use my appliance.  It works for me and is tested and working for others.  There is no hidden magic to adding a clear interface.... you create a new interface and through all of the SAME STEPS, tell the traffic to route out WAN instead of AirVPN_WAN.

If you tried and it failed you missed something. It's normal, there are a lot of steps/settings and it is easy to overlook one or more. The most common mistake is the outbound NAT settings and not defining the correct gateway on the outbound firewall rule.

I changed this guide to create the AirVPN_LAN interface first due to the high demand. Adding a second interface for clearnet works the same way in principal as the old guide.... but the old guide should not be used. here are too many settings that have changed.

You would need to use a router that routes all traffic through the VPN such as pfSense, Asus, Netgear etc that have OpenVPN.

That being said you cannot port forward all the required ports for XBOX Live to function entirely and will have a strict NAT and have some services be unavailable at times, including chat.

I use pfSense of course, but I do not run my consoles through the VPN, instead I employ a true isolated DMZ for them and allow UPNP only on that interface and only for those devices. This allows me to enjoy full functionality as well as top level security. I even have ad and tracking servers blocked on the DNS level for a bit of extra privacy. Keep in mind if you use XBOX Live this is generally attached to your true identity through your account so there is little value of the gaming traffic to go through the VPN, unless you are trying to hide gaming use from your ISP.

For those asking about the clearnet interface, I don't have a timetable other than to say eventually.

If you used the original guide, you should be ale to extrapolate how to accomplish this.

First create and name a new interface. All settings on the interface page are the same are the AirVPN_LAN interface EXCEPT the name and IP address of the subnet you choose.

Under dhcp server for the new interface, replace the 192.168.1.100 - 192.168.1.199 with 192.168.123.100 - 192.168.123.199 (or whatever subnet you chose)

For the rest of the interface settings, simply replace AirVPN_LAN in the rules for Clear_LAN (or whatever you name it) and AirVPN_WAN with WAN.

On the outbound rule, select WAN for the gateway.

There is not much different, you are just telling the traffic where to go. I highly encourage you all to take ther time to understand how this works, the information is there in the guide. If not, I will eventually open up the text editor and add it, right now I am backed up with work and cannot.

Hello, pfSense_fan,

I want to thank you for your guide on how to setup PFSense 2.3 for use with AirVPN. I have my PFSense box setup following your detailed instructions, and it is working great. I appreciate the effort that you went to, providing myself and others with your guide. I know it was a lot of work that took many hours and days to compile.

 

I had been using your previous PFSense guide for AirVPN for the last couple of years without any problems. It still works perfectly by the way. It has always updated and continued working fine whenever a newer version of PFSense was released. I hope this guide will last as long as your previous one has.

 

Thanks again.

Thank you, it means lot to read such a wonderful compliment. I am so glad it has helped you. For anyone interested, updating the guide from the original to the new 2.3 took over 100 hours of research and and editing. The original guide took well over a few thousand hours including learning/upgrading it between iterations. I rushed this one out to have it ready for 2.3. There will be small edits over time to explain in more detail what and why settings are recommended the way they are. For now I need a break from it. There will also be some additional optional steps added.

I hope it lasts as long too, and i really hope, as I always have, that discussion will pick up in this thread among users and together we can evolve the discussion to make this better for everyone.

Download again and reflash to usb stick if that is what you are doing. I had this happen to me as well. Downloaded again, reflashed using rufus and off I went. It does sit on that screen for a minute though.

~10% OpenVPN overhead is correct actually.

​

​

Hey all,

 

Thank you very much for this new tutorial worked like a charm to me, did several attempts with the 'old' one with no success.

his one worked very well and I find it clearer also.

 

I have a couple of questions tho:

 

1) If I generate a TCP 443 certificate does it change something in particular besides the OpenVPN Client configuration ?

 

2) Is there any way to change 'easily' (with a minimum of steps) the AirVPN Server I connect to ?

 

 

Thank you very much for your time.

 

 

n.

​You are welcome and I am glad to hear it went so well. Please take a moment to rate/like the post so other users may know the guide has been tested and works for those who have tried it!

​

​1) Any setting that is changed from the OVPN config you download compared to the "standard" OVPN config i used as an example would need to be adjusted accordingly. The guide shows where the settings go, just adjust as needed.

​2) All you need to do is change the entry IP on the "Server host or address" line in the OpenVPN client page on pfsense, then save. You may also need to reset states after saving:

​

​

​https://192.168.1.1/diag_resetstate.php
​