OpenVPN (Client) + BTGuard + Tunneling WLAN
-
Dear other members of pfSense,
i'm successfully using pfSense to route all my traffic including 2 WANs (no load balancing) several VLANs and networks. Its running quite impressive on my ESXi (a well documented installation will be released shortly to give you guys something back). I've planned to go a step further and plan to make my Wireless Access Point publically available for the other people here in my House/Street. Todo so, i need to tunnel all WLAN traffic which is going to the internet through a VPN. This is because german law has some really annoying paragraphs which will send me to jail if anybody is doing nasty things using my public WLAN (Mitstörerhaftung).
So i've signed up with BTGuard.com VPN Service because speed is fine and i got OpenVPN supported. The only thing i am stuck is setting the stuff up. What i did so far:
- Imported the .crt Certificate from BTGuard (no .key given out by them)
- Setup the OpenVPN
- It is in fact connecting, but connection is getting terminated immediatly
Did anyone successfully used BTGuard to build up a VPN using pfSense client ability?
Kind regards
Florian
-
I had tried something similar but it seemed the routes pushed from the vpn were conflicting with the local routing table. I'm sure there's a workaround. I basically copied a working config from the OpenVPN client (Viscosity,) it was pretty straightforward.
-
PFsense is a great security+ appliance and I definitely applaud the developers et. al. It really comes down to overhead vs. manageability. pfSense is definitely designed to be modular and very capable. It's more than just a capable firewall, it's a proxy and definitely keeps up with the times and needs of the community much faster. You can definitely fine tune pfSense, but without really getting into the guts and doing configuration of the VPNs for example (like pushing routes and running scripts) and even routing table manipulation, it's a bit tedious to do from the command line.
I'm not saying it's not doable, just more of a challenge. For example, understanding how MTUs and Fragmentation effect latency are important.
Adjusting and supporting more than one Cipher is also an issue. Generating keys and clients are much easier on the command line. Client Config Directives from the same server are also important. Having the ability to have multiple clients on the same port would be yet another reason.
You can also apply pre-processing of packets prior to sending out the tunnel (OVPN or IPSEC). There are many ways and things to do. While pfSense is relatively lightweight, I come from the school of keeping the absolute minimum you need on the box and leveraging the rest of the resources towards performance.
I still strongly recommend pfSense as my Firewall of Choice. I just come from a different mindset where I believe the least amount of "weight" on a machine, the better the performance. In some cases though, a GUI does make things easier and that is why pfSense is so successful. It's feature rich and the development team has managed to put it all together in such a way that not only does it make it easy to manage, but it works very well together.
So once again, for me it's Kudos to the team… but in some cases, you'll need to fine tune a specific service / server and pfsense may not be an optimal solution.
-
I had tried something similar but it seemed the routes pushed from the vpn were conflicting with the local routing table. I'm sure there's a workaround. I basically copied a working config from the OpenVPN client (Viscosity,) it was pretty straightforward.
I did the same, but the tunnel didnt came up.
I just took a look into the client config and changed the tls seeting in /var/etc/openvpn/client1.conf from
tls-auth /var/etc/openvpn/client1.tls-auth 1to
tls-auth /var/etc/openvpn/client1.tls-authrestarted the service and the tunnel came up
Now i have the same issue like joako.