Can you show the system log VPN tries to connect and the screenshots of the VPN policies?
I do not work for and I am not directly associated with GL.iNet
“Domain/IP” means allow destination address via VPN，I notice that you are setting a specific IP(192.168.x.y) and it look like a source address, if you want it to work at a source address, you should choose “MAC Address” in the “Please Choose Policy”.
1 Like
I thought so too and is why I asked to see the screenshot of the VPN policies to confirm.
Tonight it has suddenly started working as intended. Only traffic for 192.168.15.x and 192.168.16.x are going through the VPN. Everything else goes direct to the Internet.
Nothing has changed, so I am not sure why it suddenly is working. It does seem a little slower when the policy is enabled than when all traffic is going through the VPN without any policy enabled.
Here is the screen shot for the VPN Policy enabled:
Here is the log with the VPN Policy enabled:
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[9012]: exiting on receipt of SIGTERM
Mon Jul 3 23:54:49 2023 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Mon Jul 3 23:54:49 2023 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: started, version 2.80 cachesize 150
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: DNS service limited to local subnets
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth nettlehash DNSSEC no-ID loop-detect inotify dumpfile
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq-dhcp[18264]: DHCP, IP range 192.168.8.100 – 192.168.8.249, lease time 12h
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain test
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain onion
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain localhost
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain local
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain invalid
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain bind
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53 for domain 192.168.16.1
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53 for domain 192.168.15.127
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53 for domain 192.168.15.1
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain lan
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: reading /tmp/resolv.conf.vpn
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain test
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain onion
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain localhost
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain local
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain invalid
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using local addresses only for domain bind
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53 for domain 192.168.16.1
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53 for domain 192.168.15.127
Mon Jul 3 23:54:49 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53 for domain 192.168.15.1
Mon Jul 3 23:54:50 2023 daemon.info dnsmasq[18264]: using local addresses only for domain lan
Mon Jul 3 23:54:50 2023 daemon.info dnsmasq[18264]: using nameserver 192.168.15.1#53
Mon Jul 3 23:54:50 2023 daemon.info dnsmasq[18264]: read /etc/hosts - 4 addresses
Mon Jul 3 23:54:50 2023 daemon.info dnsmasq[18264]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Mon Jul 3 23:54:50 2023 daemon.info dnsmasq-dhcp[18264]: read /etc/ethers - 0 addresses
Mon Jul 3 23:55:50 2023 kern.warn kernel: [109058.493584] d4e, flush one!
192.168.8.x is the source address range (the GL.iNet).
192.168.15.x and 192.168.16.x are the destination ranges (behind the VPN).
Wait… your VPN Policy is putting those three LAN-side devices for all of their associated traffic through it. That’s not really what Domain/IP → Only allow the follow to use VPN […] is meant for. If you wanted just those devices to use the VPN it’d be better to set the policy as MAC Address → Only allow the follow to use VPN […]
(Not that you’ve done this but the IP for the GL device (default 192.168.8.1) shouldn’t be included if the VPN connection originating that from that very device, of course.)
Domain/IP is meant for if you wanted to use the VPN link to ‘kick in’/route traffic when hitting specific Internet sites, eg: Netflix:
No, 192.168.8.x is not routed through the VPN. It is the local GL device. Only traffic to 192.168.15.1, 192.168.15.127 and 192.168.16.1 should go through the VPN.
In my last reply I indicated this was working as intended with the VPN policy enabled, but slowly. In further testing it is very intermittent–unstable.
I’d still take those LAN-side devices & put their MACs to use the VPN instead.
(GL GUI → VPN → VPN Dashboard → Global Proxy → Based on the Client Device)
The VPN Policies look correct to allow source devices with any IP address to go from the GL-MT1300 through the VPN tunnel to the Netgear router and reach the destination devices with IP addresses 192.168.15.x and 192.168.16.x. Other destination IP addresses would go out to the Internet and not through the VPN tunnel.
There may be minor slowness and intermittent instability over VPN between the 2 routers, depending on the traffic and network conditions at both ends. If the problem is severe, then further traffic monitoring and logging would be required.
GL.iNet Firmware 3 does not have Global Proxy.
No, but it does have the ability to force the MACs thru the VPN.
f/w 3.216
The OP stated that it is working using the Domain/IP-based. VPN Policy:
We seem to have very different definitions of working.
TL;DR. I don’t need more nonsense in this forum.
Another insightful comment from the Minion demonstrating a continued commitment to technical incompetence before trivial troubleshooting I see. How’s the view from the peanut gallery?
As a followup, I did a quick test with your VPN Polcies approach in my own environment and it worked successfully as you described. The setup is OpenVPN Client on GL-AR750S (Firmware 3) connected to OpenVPN Server on my main router. The OpenVPN speed is limited by GL-AR750S performance, but there was no other noticeable slowness or instability.
You do know they’re forwarding local DNS lookups out over the VPN, yes?
Thanks for taking time to confirm. I’m going to play with some OpenVPN settings. I found another thread discussing GL.iNet routers dropping OpenVPN connections after periods of inactivity and then having trouble reconnecting automatically. This could explain the intermittent behavior. I’ve noticed, for example that if the Samba connection stops working, I can browse to the IP using Chrome, then return to Samba and it works. I’m going to see if any of the suggested settings help.
I’ve fixed that since sending the logs earlier. I went into GL.iNet’s DNS settings and manually entered a DNS. External requests are no longer being routed through the VPN.
Huh; I know WireGuard conf files usually set a persistent_keepalive '25' directive to send a ‘heartbeat’ packet every 25 seconds. I’d look for a proper fix first but worst case something similar can be done here, I think, to ping whatever IPs you specified that should accomplish the same effect. I’m reasonably sure the OpenVPN feature sets a virtual interface like WG does (eg: network.wgclient=interface == wgclient for the interface name). That should be enough to restart the VPN should pings to, say, 192.168.16.1 fail.
opkg update && opkg install luci-app-watchcat watchcat nano
uci show | grep network | grep interface
nano /etc/config/watchcat