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.

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: 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.

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

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

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.

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 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###; All you have to do is enter multiple remote lines into the advanced section on your client settings. There may be a short delay as it reconnects but i have honestly never noticed when mine does. Just choose your favorite server in the main entry and a number of secondary options.

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.

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.

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.

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.

​ ​ ​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 ​