How to direct internet thru OpenVPN?

t_open · September 7, 2025, 6:47pm

I have a working OpenVPN Server configuration in my OpenWrt home router and a remote laptop with OpenVPN client software so I can access LAN resources away from home.

Right now, all internet connections from the remote laptop go through the laptop's local ISP, while references to home LAN addresses 192.168.0.x get routed through the VPN to the home network. When the laptop connects to the VPN, it takes on an address of the form 10.8.0.x that can be reached from the home network.

I would like to direct all Internet from the client laptop to go through the server to the Server's ISP from this remote laptop. What must I change for this to work? I would like the Open VPN server to be able to support this client whose Interent goes through the server's ISP and not impact any other client whoose internet remains local at the same time.

(The OpenVPN server sits in a fixed location with an ISP that provides a public IPV4 address and a dyndns service is used to remotely find the server from anywhere. There is also a second OpenVPN client that is another openwrt router at 192.168.4.1 whose Internet accesses are to remain direct through its own ISP.)

Server OpenVPN configuration:

root@OpenWrt:~# cat /etc/config/openvpn

config openvpn 'custom_config'
	option config '/etc/openvpn/my-vpn.conf'

config openvpn 'sample_server'
	option enabled '1'
	option port '1194'
	option proto 'udp'
	option dev 'tun'
	option ca '/etc/openvpn/ca.crt'
	option cert '/etc/openvpn/server.crt'
	option key '/etc/openvpn/server.key'
	option dh '/etc/openvpn/dh.pem'
	option server '10.8.0.0 255.255.255.0'
	option ifconfig_pool_persist '/tmp/ipp.txt'
	option keepalive '10 120'
	option persist_key '1'
	option persist_tun '1'
	option user 'nobody'
	option status '/tmp/openvpn-status.log'
	option verb '3'
	list push 'route 192.168.0.0 255.255.255.0'
	option client_config_dir '/etc/openvpn/ccd'
	list route '192.168.4.0 255.255.255.0'

config openvpn 'sample_client'
	option client '1'
	option dev 'tun'
	option proto 'udp'
	list remote 'my_server_1 1194'
	option resolv_retry 'infinite'
	option nobind '1'
	option persist_key '1'
	option persist_tun '1'
	option user 'nobody'
	option ca '/etc/openvpn/ca.crt'
	option cert '/etc/openvpn/client.crt'
	option key '/etc/openvpn/client.key'
	option verb '3'

Client Open VPN Configuration:

remote [MyAfraidID].mooo.com 1194 udp
nobind
dev tun
persist-tun
persist-key
pull
tls-client
ca ca.crt
cert cert.crt
key key.key
remote-cert-tls server
auth SHA256
cipher AES-256-GCM
data-ciphers AES-256-GCM:AES-256-CBC
tls-version-min 1.2

Thanks in advance for any advice.

egc · September 8, 2025, 5:56am

First consider using WireGuard which is three times faster and easier to implement then OpenVPN
For WireGuard see my notes how to setup WireGuard:
WireGuard Server Setup Guide
or the Official WireGuard wiki:

But to answer your question:
On the client side add to the OpenVPN config, to route all traffic via the server:

redirect-gateway def1
# or if you also have IPv6 implemented:
redirect-gateway ipv6

The server side must allow traffic from VPN firewall zone to wan zone to have internet access.

t_open · September 8, 2025, 2:13pm

Thanks for your reply.

So, would I use both redirect-gateway commands if I use ipv6?

How do I set this up on the server side?

egc · September 8, 2025, 2:43pm

Just one is enough, using ipv6 covers both ipv4 and ipv6.

The firewall setup for your OpenVPN server is the same as for a WireGuard server:
See paragraph about Firewall setup: WireGuard Server Setup Guide

If you cannot get it working, please show your configs, connect to your OpenWRT device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button

Remember to redact keys, passwords, MAC addresses and any public IP addresses you may have but do not redact private RFC 1918 IP addresses as that is not needed:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall
ip route show
ip -6 route show
cat /etc/config/openvpn
for ovpn in $(ls /etc/openvpn/*.ovpn);do echo $ovpn; cat $ovpn; echo;done
for vpn in $(ls /tmp/etc/openvpn*.conf);do echo $vpn;cat $vpn;echo;done
logread | grep openvpn

KSofen · September 8, 2025, 3:17pm

WireGuard is better, but as you can see, a lot trickier. OpenVPN is reliable and integrated more fully and invisibly into OpenWrt. There’s an easy guide.

OpenVPN client using LuCI

It’s also much easier to enable and disable OpenVPN and no need for complex policy based routing setups.

egc · September 8, 2025, 3:22pm

WireGuard is very well integrated even at the kernel level.

The WireGuard interface can be brought up and down very easily both from GUI and from the command level

But if you are happy with OpenVPN then that is fine

Mullvad one of the bigger VPN providers is even going to stop supporting OpenVPN, which I think is a bad decision, WireGuard is faster and easier but there is still a use case for OpenVPN

KSofen · September 8, 2025, 3:25pm

I’ve never been able to bring WireGuard up and down reliably. What’s your method? I always have problems. With OpenVPN, Luci can just enable and disable it. How is that done with WireGuard?

egc · September 8, 2025, 3:34pm

Exactly the same.

The difference between default WireGuard setup and OpenVPN is that OpenVPN does not replace the default route but it uses def 1 meaning you get extra routing rules like

ip route add 128.0.0.0/1 dev tun
ip route add 0.0.0.0/1 dev tun

This routes all traffic via the OpenVPN interface but preserves the default route via the wan.

When the interface is brought down it will delete these routes but the existing default route via the wan is still there.

If you follow the WireGuard instructions then default is to use 0.0.0.0/0 as Allowed IPs this will replace the existing default route via the WAN, now if you disable the interface it will remove the default route via the WG interface but does not automatically bring back the default route via the wan.
Two solutions:

Restart the network: service network restart
My solution use as Allowed IPs not: 0.0.0.0/0 but 128.0.0.0/1 and 0.0.0.0/1 and Bob is your uncle

Elementary

KSofen · September 8, 2025, 3:41pm

Yes, I remember writing scripts to do that – but they didn’t work reliably as the toggle for OpenVPN in the Luci interface. I also had a lot of issues with the RTC having to be EXACTLY correct for WireGuard to work. I’m glad your wiki covered the tick mark people always seem to forget. Your wiki is quite thorough but I think most OpenWrt people are not going to read it as thoroughly as you need to. Hitting the enable disable button in Luci is the easy button. My VPN are not using commercial VPN providers and just through my own computers in different locations and the download speed is always limited by the upload speed at the server so I never can use WireGuard’s better throughput anyway.

egc · September 8, 2025, 3:48pm

You do not need any scripts just use as Allowed IPs 128.0.0.0/1 and 0.0.0.0/1 instead of 0.0.0.0/0.
If you do then just disabling the interface in the GUI or doing an ifdown <wg-interface> will restore default routing via the WAN

t_open · September 9, 2025, 2:54am

I am not sure how to proceed with an attempt to follow this advice. Which part of “Firewall Setup” should I pay attention to. The VPN (which was setup under the VPN tab on the server router) does not create a named interface, so I have nothing similar to a “wgserver interface”.

I show the result of “cat /etc/config/openvpn” in my original post and here are the other items…(Note: These codes will show I am using LAN port 5 for WAN to have both my 2.5GbE ports for LAN.)

ubus call system board

{
	"kernel": "6.6.73",
	"hostname": "OpenWrt",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT6000",
	"board_name": "glinet,gl-mt6000",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.0",
		"revision": "r28427-6df0e3d02a",
		"target": "mediatek/filogic",
		"description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
		"builddate": "1738624177"
	}
}

cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd05:32cf:785e::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.0.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'lan5'
	option proto 'dhcp'

config interface 'wan6'
	option device 'lan5'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'

config device
	option type 'bridge'
	option name 'br-guest'
	option bridge_empty '1'

config interface 'guest'
	option proto 'static'
	option device 'br-guest'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'

cat /etc/config/firewall

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list device 'tun0'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config zone
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config forwarding
	option src 'guest'
	option dest 'wan'

config rule
	option name 'Allow-DNS-Guest'
	option src 'guest'
	option dest_port '53'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCP-Guest'
	list proto 'udp'
	option src 'guest'
	option dest_port '67'
	option target 'ACCEPT'

config rule
	option name '20-29 off the net'
	option src 'lan'
	option dest 'wan'
	option target 'REJECT'
	list src_ip '192.168.0.20-192.168.0.29'

config rule
	option name 'Allow-OpenVPN'
	list proto 'udp'
	option src 'wan'
	option dest_port '1194'
	option target 'ACCEPT'

ip route show

default via 24.107.0.1 dev lan5  src 24.107.2.131 
10.8.0.0/24 via 10.8.0.2 dev tun0 
10.8.0.2 dev tun0 scope link  src 10.8.0.1 
24.107.0.0/19 dev lan5 scope link  src 24.107.2.131 
192.168.0.0/24 dev br-lan scope link  src 192.168.0.1 
192.168.2.0/24 dev br-guest scope link  src 192.168.2.1 
192.168.4.0/24 via 10.8.0.2 dev tun0

ip -6 route show

default from 2600:6c40:0:ac::/64 via fe80::201:5cff:fe68:4646 dev lan5  metric 512 
default from 2600:6c40:700b:100:4481:dff6:dcc4:d873 via fe80::201:5cff:fe68:4646 dev lan5  metric 512 
2600:6c40:0:ac::/64 dev br-lan  metric 1024 
unreachable 2600:6c40:0:ac::/64 dev lo  metric 2147483647 
fd05:32cf:785e::/64 dev br-lan  metric 1024 
unreachable fd05:32cf:785e::/48 dev lo  metric 2147483647 
fe80::/64 dev eth0  metric 256 
fe80::/64 dev tun0  metric 256 
fe80::/64 dev br-lan  metric 256 
fe80::/64 dev lan5  metric 256 
fe80::/64 dev br-guest  metric 256 
anycast 2600:6c40:0:ac:: dev br-lan  metric 0 
anycast fd05:32cf:785e:: dev br-lan  metric 0 
anycast fe80:: dev tun0  metric 0 
anycast fe80:: dev eth0  metric 0 
anycast fe80:: dev br-lan  metric 0 
anycast fe80:: dev lan5  metric 0 
anycast fe80:: dev br-guest  metric 0 
multicast ff00::/8 dev br-lan  metric 256 
multicast ff00::/8 dev eth0  metric 256 
multicast ff00::/8 dev tun0  metric 256 
multicast ff00::/8 dev lan5  metric 256 
multicast ff00::/8 dev br-guest  metric 256

for ovpn in $(ls /etc/openvpn/*.ovpn);do echo $ovpn; cat $ovpn; echo;done

ls: /etc/openvpn/*.ovpn: No such file or directory

for vpn in $(ls /tmp/etc/openvpn*.conf);do echo $vpn;cat $vpn;echo;done

/tmp/etc/openvpn-sample_server.conf
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
client-config-dir /etc/openvpn/ccd
dev tun
dh /etc/openvpn/dh.pem
ifconfig-pool-persist /tmp/ipp.txt
keepalive 10 120
key /etc/openvpn/server.key
port 1194
proto udp
push "route 192.168.0.0 255.255.255.0"
route 192.168.4.0 255.255.255.0
server 10.8.0.0 255.255.255.0
status /tmp/openvpn-status.log
user nobody
verb 3

egc · September 9, 2025, 6:06am

Your firewall is fine the tun interface is added to the LAN zone which gives it the same permissions as LAN traffic e.g. you should have internet access from your OpenVPN clients.

There is no IPv6 VPN server setup, which is no problem per se but if your client does have working IPv6 you have to either remove IPv6 from the client or still add to the client config:
redirect-gateway ipv6
This makes the default IPv6 route via the VPN but as you did not implement IPv6 on the server this will effectively block IPv6 which can lead to problems.

As you do seem to have a working IPv6 on the server it is better to also implement IPv6 on the OpenVPN server

Next problem you might run into is DNS as we did not cover that but if it works it works

t_open · September 10, 2025, 5:12am

The client laptop has IPV6 disabled (link local only). I connected to the VPN with the original configuration modified only by adding redirect-gateway def1 to the client. I then tried to connect to google directly by number as in 142.250.190.46 instead of relying on DNS and my browser still cannot connect. So there is something more than DNS wrong. Connections to my LAN through the VPN remain working with redirect-gateway def1 in the client configuration. Not sure what to try next.

egc · September 10, 2025, 7:00am

Did you test from outside your network e.g. with your laptop on cellular? Testing from inside does not work reliably.

I would remove this from your OpenVPN server setup

Not sure why you want to route that traffic through the VPN it probabaly will not work anyway without an iroute

Reboot afterwards

You can run a traceroute from your laptop (if it is running windows then tracert 8.8.8.8) to see what is stopping the traffic

t_open · September 10, 2025, 5:14pm

Yes I am testing from outside my network. The laptop with original configuration is able to access my LAN resources (through the VPN) and the Internet directly. With modified configuration to add “redirect-gateway def1” to client, I still can access LAN resources, but lose Internet entirely - it won’t go through the VPN.

I removed this, rebooted, and retested. It makes no difference for the issue here, but with this removed you can forget any mention of an openwrt openvpn client router I said above, it is out of the picture and disconnected from where it was used.

I tried my fixed google IP address and your 8.8.8.8 and get the below, yet putting the fixed Google IP addresses in the browser does not work.

mymac@mymacs-MacBook-Pro ~ % traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
 1  10.8.0.1 (10.8.0.1)  574.821 ms  510.002 ms  716.074 ms
 2  * * *
 3  96.34.55.129 (96.34.55.129)  175.334 ms  72.685 ms  77.647 ms
 4  96.34.49.220 (96.34.49.220)  81.659 ms  163.498 ms  134.682 ms
 5  96.34.76.137 (96.34.76.137)  359.491 ms  312.506 ms *
 6  96.34.2.88 (96.34.2.88)  210.949 ms  123.068 ms
    96.34.2.164 (96.34.2.164)  78.038 ms
 7  96.34.0.12 (96.34.0.12)  80.886 ms
    96.34.2.120 (96.34.2.120)  98.406 ms
    96.34.0.12 (96.34.0.12)  93.749 ms
 8  96.34.3.73 (96.34.3.73)  77.793 ms
    96.34.3.11 (96.34.3.11)  91.782 ms
    96.34.3.73 (96.34.3.73)  85.174 ms
 9  96.34.152.155 (96.34.152.155)  88.709 ms
    96.34.152.97 (96.34.152.97)  81.870 ms  95.281 ms
10  192.178.249.201 (192.178.249.201)  100.019 ms *
    142.251.77.147 (142.251.77.147)  343.446 ms
11  8.8.8.8 (8.8.8.8)  305.406 ms  306.625 ms
    142.251.60.201 (142.251.60.201)  110.490 ms
mymac@mymacs-MacBook-Pro ~ % traceroute 142.250.190.46
traceroute to 142.250.190.46 (142.250.190.46), 64 hops max, 40 byte packets
 1  10.8.0.1 (10.8.0.1)  347.798 ms  305.067 ms  307.312 ms
 2  * * *
 3  96.34.55.129 (96.34.55.129)  446.983 ms  85.917 ms  88.725 ms
 4  96.34.49.220 (96.34.49.220)  87.504 ms  82.529 ms  71.214 ms
 5  96.34.76.137 (96.34.76.137)  73.515 ms  85.296 ms  82.295 ms
 6  96.34.2.164 (96.34.2.164)  80.443 ms
    96.34.2.88 (96.34.2.88)  81.149 ms
    96.34.2.164 (96.34.2.164)  86.833 ms
 7  96.34.2.120 (96.34.2.120)  84.098 ms
    96.34.0.12 (96.34.0.12)  93.586 ms  82.438 ms
 8  96.34.3.73 (96.34.3.73)  89.261 ms  83.657 ms
    96.34.3.11 (96.34.3.11)  87.244 ms
 9  96.34.152.155 (96.34.152.155)  86.832 ms
    96.34.152.97 (96.34.152.97)  80.897 ms  88.588 ms
10  * 192.178.249.201 (192.178.249.201)  173.608 ms *
11  142.251.60.210 (142.251.60.210)  104.896 ms
    209.85.255.172 (209.85.255.172)  99.107 ms
    142.251.60.202 (142.251.60.202)  93.610 ms
12  142.250.190.46 (142.250.190.46)  98.579 ms  109.618 ms
    192.178.249.208 (192.178.249.208)  89.969 ms
mymac@mymacs-MacBook-Pro ~ %

egc · September 10, 2025, 6:28pm

That looks fine you have routing via the VPN to the internet.

Now do a traceroute ipchicken.com and traceroute openwrt.org

t_open · September 10, 2025, 11:01pm

The result is

% traceroute ipchicken.com
traceroute: unknown host ipchicken.com
% traceroute openwrt.org
traceroute: unknown host openwrt.org

And the only changes I made to my configuration since the start of the conversation are to add “redirect-gateway def1” to the client and remove “route 192.168.4.0 255.255.255.0” from the server. If I take out “redirect-gateway def1” Internet access returns, but only through the client’s ISP.

egc · September 11, 2025, 5:34am

Well like I mentioned some posts back you have a DNS problem, now all traffic is routed via the tunnel so also DNS, your DNS queries might be intercepted by your router but are not answered.

How is your router setup to handle DNS queries?
Are you using any DNS redirect rules?

If you are using DNSMasq as your only DNS server take note of this, this is meant for WireGuard but the same holds true for all VPN tunnels:

The first is to make sure that the DNS server can actually process queries from the other side.
DNSmasq has to listen on all interfaces so also on the WG interface, by default this is the case but if you changed that then you have to add the WG interface as listen interface.

The second is that DNSMasq has to answer non local request coming from the other side.
For this disable Local Service only (DNSMasq: -local-service):
Luci DNS-DHCP > Filter >Local service only : untick/disable,
or in /etc/config/dhcp > config dnsmasq:
option localservice '0'

t_open · September 11, 2025, 5:37pm

Thanks for your continued replies.

I am using default settings for DNS. I added or changed nothing related to DNS.

Exactly How do I set this up? I do not see a specific interface I would add as a listen interface and generally do not understand how to perform this step.

OK, I see this option and will update it along with whatever I end up doing for the first step.

egc · September 11, 2025, 6:35pm

By default there are no interfaces specified meaning DNSMasq listens on all interfaces so normally you should be good