What's new

dedicated router for OpenVPN

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

nickolasm5

Occasional Visitor
I already have a router (#1) that is set up and fucntioning as expected.
I need to set up additional dedicated router (#2) (HW accelerated ASUS) that will be a OpenVPN client for a remote server. It should be connected to router 1 via LAN, get local IP via DHCP for the WAN interface, and it will have its own separate LAN network, and all clients that are connected to it (2) should only use OpenVPN to access internet. If the OpenVPN connection fails, or any other failiures happen (router 1 / 2 reboot, power failiure. etc.) the clients shouldn't access internet in any way.
Do I understand correctly - the only things I need is to select in the client settings in router 2 are "Redirect Internet traffic through tunnel - Yes ALL" and "Killswitch - Block routed clients if tunnel goes down - Yes"? Or there is something else I need to check? What would be the best practice for such config?
 
I don't understand. If you want a dedicated VPN router, why use a hardware accelerated router? Hardware acceleration has no impact on VPN server/client software, as it is purely a CPU task. Your ASUS even with the newest 4 core CPU will struggle to achieve anything higher than 1Gbps...

I think the best practice is using a Raspberry Pi, or an old but super cheap j1900 machine, or if you want something fancy and power Intel 8505 etc.
 
It works as you describe it. The fact it's subordinate to another router upstream that YOU happen to control doesn't make it any different from the same configuration on the primary router. It all works the same.

However...

Many ppl don't find the built-in killswitch 100% reliable. It's been unreliable enough that its implementation and behavior have been changed several times, each time in an attempt to address complaints, with varying levels of success.

IMO, the problem is w/ the way it's implemented. If the VPN fails, it alters the relevant routing table to deny access to a default gateway. On the face of it, it seems reasonable. But I think it's more reliable and straight-forward to just block access to the WAN 24/7 using the firewall, esp. if ALL your users will be routed through the VPN. Now you're not dependent on how the routing tables are being managed to enforce the killswitch. There's simply is NO WAY for clients to access the internet via the WAN, *ever*, even if the VPN is intentionally NOT running, or even configured AT ALL!

Note, given this is an internal router, you might still want to minimally allow access to the immediate, private upstream network of router #1. So the firewall rules need to be adjusted accordingly.

At least that what *I* would do.

And btw, it would probably make more sense to NOT use Yes(all), but instead the VPN Director, then add a rule that routes the entire private network over the VPN (e.g., 192.168.2.0/24). This removes the router itself from the VPN (which is NOT the case w/ Yes(all)). Having the router bound to the VPN can be problematic. For example, if the VPN fails and the router needs to perform name resolution w/ the domain name of the VPN server, and you're using Exclusive (which routes DNS over the tunnel), the router loses access to DNS as well, and now the router can't restart the VPN!

That's why, as a general rule, it's best to keep the router itself OFF the VPN if at all possible. It just avoids "quirks" like the above.

JMTC
 
It works as you describe it. The fact it's subordinate to another router upstream that YOU happen to control doesn't make it any different from the same configuration on the primary router. It all works the same.
But I think it's more reliable and straight-forward to just block access to the WAN 24/7 using the firewall, esp. if ALL your users will be routed through the VPN. Now you're not dependent on how the routing tables are being managed to enforce the killswitch. There's simply is NO WAY for clients to access the internet via the WAN, *ever*, even if the VPN is intentionally NOT running, or even configured AT ALL!



JMTC
As I remeber there is no option to forbid that via GUI? So both FW / Routing only via script / SSH? Or it can be done via "Firewall - Network Services Filter"?
 
Last edited:
I would just create a firewall-start script containing the following:

Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -i br+ -o $WAN_IF -j REJECT

The following link shows how to create and install the firewall-start script. You just need to substitute the above rules for those in the example.

 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top