VPN Policy-Based Routing + Web UI -- Discussion

Nove11 · November 12, 2020, 11:41am

indeed. Here it is:
/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'

config dhcp 'lan'
	option interface 'lan'
	option leasetime '12h'
	option start '10'
	option limit '50'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'tun0'
	option leasetime '12h'
	option interface 'tun0'
	option start '10'
	option limit '50'

config dhcp 'wlan0'
	option leasetime '12h'
	option interface 'wlan0'
	option start '10'
	option limit '50'

config dhcp 'WLAN0'
	option leasetime '12h'
	option interface 'WLAN0'
	option start '10'
	option limit '50'

config dhcp 'WLAN_IN'
	option leasetime '12h'
	option interface 'WLAN_IN'
	option start '10'
	option limit '50'

config dhcp 'WLAN_UK'
	option leasetime '12h'
	option interface 'WLAN_UK'
	option start '10'
	option limit '50'

config dhcp 'WLAN_US'
	option leasetime '12h'
	option interface 'WLAN_US'
	option start '10'
	option limit '50'

/etc/config/firewall

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

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'WLAN_US'
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option network 'WLAN_US'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'

config zone
	option network 'WLAN_IN'
	option input 'ACCEPT'
	option name 'WLAN_IN'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	option mtu_fix '1'

config zone
	option network 'WLAN_UK'
	option input 'ACCEPT'
	option name 'WLAN_UK'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	option mtu_fix '1'

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

config zone
	option name 'Michters'
	option mtu_fix '1'
	option masq '1'
	option output 'ACCEPT'
	option network 'TUN_US'
	option input 'REJECT'
	option forward 'REJECT'

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 src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	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 include
	option path '/etc/firewall.user'

config forwarding
	option dest 'wan'
	option src 'WLAN_USA'

config zone
	option network 'TUN_IN'
	option name 'Amrut'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option input 'REJECT'
	option forward 'REJECT'

config forwarding
	option dest 'Amrut'
	option src 'WLAN_IN'

config forwarding
	option dest 'wan'
	option src 'WLAN_IN'

config zone
	option network 'TUN_UK'
	option name 'Ardbeg'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option input 'REJECT'
	option forward 'REJECT'

config forwarding
	option dest 'Ardbeg'
	option src 'WLAN_UK'

config forwarding
	option dest 'wan'
	option src 'WLAN_UK'

config forwarding
	option dest 'Michters'
	option src 'WLAN_US'

config forwarding
	option dest 'wan'
	option src 'WLAN_US'

/etc/config/network

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

config globals 'globals'
	option ula_prefix 'fd99:442f:eec0::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '10.0.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	list dns '1.1.1.1'

config interface 'wan'
	option ifname 'eth1.2'
	option proto 'dhcp'
	option peerdns '0'

config interface 'wan6'
	option ifname 'eth1.2'
	option proto 'dhcpv6'
	option reqprefix 'auto'
	option reqaddress 'try'
	option peerdns '0'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 5t'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '2'
	option ports '4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '5t 6t'

config interface 'WLAN_US'
	option ifname 'eth0.3'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.2.1'
	option type 'bridge'
	list dns '10.8.8.1'

config interface 'TUN_US'
	option ifname 'tun0'
	option proto 'none'

config interface 'TUN_IN'
	option ifname 'tun1'
	option proto 'none'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option ports '5t 6t'
	option vid '4'

config interface 'WLAN_IN'
	option ifname 'eth0.4'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.3.1'
	list dns '10.8.8.1'
	option type 'bridge'

config switch_vlan
	option device 'switch0'
	option vlan '5'
	option ports '5t 6t'
	option vid '5'

config interface 'TUN_UK'
	option ifname 'tun2'
	option proto 'none'

config interface 'WLAN_UK'
	option ifname 'eth1.5'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.4.1'
	list dns '10.8.8.1'
	option type 'bridge'

/etc/config/vpn-policy-routing

config policy
	option interface 'wan'
	option name 'LAN'
	option dest_addr '0.0.0.0/0'
	option src_addr '10.0.1.1/24'

config policy
	option name 'Michters'
	option dest_addr '0.0.0.0/0'
	option src_addr '10.0.2.1/24'
	option interface 'TUN_US'

config policy
	option name 'Amrut'
	option dest_addr '0.0.0.0/0'
	option src_addr '10.0.3.1/24'
	option interface 'TUN_IN'

config policy
	option name 'Ardbeg'
	option dest_addr '0.0.0.0/0'
	option src_addr '10.0.4.1/24'
	option interface 'TUN_UK'

config vpn-policy-routing 'config'
	option verbosity '2'
	option strict_enforcement '1'
	option ipv6_enabled '0'
	list supported_interface 'TUN_US TUN_IN TUN_UK'
	list ignored_interface 'vpnserver wgserver'
	option boot_timeout '30'
	option webui_protocol_column '0'
	option webui_sorting '1'
	list webui_supported_protocol 'tcp'
	list webui_supported_protocol 'udp'
	list webui_supported_protocol 'tcp udp'
	list webui_supported_protocol 'icmp'
	list webui_supported_protocol 'all'
	option dest_ipset 'dnsmasq.ipset'
	option src_ipset '0'
	option iprule_enabled '0'
	option webui_chain_column '0'
	option webui_enable_column '1'
	option iptables_rule_option 'insert'
	option enabled '1'

config include
	option path '/etc/vpn-policy-routing.netflix.user'
	option enabled '0'

config include
	option path '/etc/vpn-policy-routing.aws.user'
	option enabled '0'

/etc/init.d/vpn-policy-routing support

vpn-policy-routing 0.2.2-2 running on OpenWrt 19.07.4. WAN (IPv4): wan/eth1.2/192.168.1.1.
============================================================
Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify dumpfile
============================================================
Routes/IP Rules
default         10.17.0.1       128.0.0.0       UG    0      0        0 tun2
default         10.20.0.1       128.0.0.0       UG    0      0        0 tun0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth1.2

IPv4 Table 201: default via 192.168.1.1 dev eth1.2 
10.0.2.0/24 dev br-WLAN_US proto kernel scope link src 10.0.2.1 
10.0.3.0/24 dev br-WLAN_IN proto kernel scope link src 10.0.3.1 
10.0.4.0/24 dev br-WLAN_UK proto kernel scope link src 10.0.4.1 
IPv4 Table 201 Rules:

IPv4 Table 202: default via 10.20.0.6 dev tun0 
10.0.2.0/24 dev br-WLAN_US proto kernel scope link src 10.0.2.1 
10.0.3.0/24 dev br-WLAN_IN proto kernel scope link src 10.0.3.1 
10.0.4.0/24 dev br-WLAN_UK proto kernel scope link src 10.0.4.1 
IPv4 Table 202 Rules:

IPv4 Table 203: default via 10.16.0.8 dev tun1 
10.0.2.0/24 dev br-WLAN_US proto kernel scope link src 10.0.2.1 
10.0.3.0/24 dev br-WLAN_IN proto kernel scope link src 10.0.3.1 
10.0.4.0/24 dev br-WLAN_UK proto kernel scope link src 10.0.4.1 
IPv4 Table 203 Rules:

IPv4 Table 204: default via 10.17.0.34 dev tun2 
10.0.2.0/24 dev br-WLAN_US proto kernel scope link src 10.0.2.1 
10.0.3.0/24 dev br-WLAN_IN proto kernel scope link src 10.0.3.1 
10.0.4.0/24 dev br-WLAN_UK proto kernel scope link src 10.0.4.1 
IPv4 Table 204 Rules:
============================================================
Mangle IP Table: PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 10.0.4.0/24 -m comment --comment Ardbeg -c 0 0 -j MARK --set-xmark 0x40000/0xff0000
-A VPR_PREROUTING -s 10.0.3.0/24 -m comment --comment Amrut -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -s 10.0.2.0/24 -m comment --comment Michters -c 129192 147036324 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 10.0.1.0/24 -m comment --comment LAN -c 23626 3360278 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -m set --match-set TUN_UK dst -c 0 0 -j MARK --set-xmark 0x40000/0xff0000
-A VPR_PREROUTING -m set --match-set TUN_IN dst -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -m set --match-set TUN_US dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set wan dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
NAT IP Table: PREROUTING
iptables: No chain/target/match by that name.
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create TUN_US hash:net family inet hashsize 1024 maxelem 65536 comment
create TUN_IN hash:net family inet hashsize 1024 maxelem 65536 comment
create TUN_UK hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]

/etc/init.d/vpn-policy-routing reload Unfortunately i couldnt find how to set verbosity level.

Creating table 'wan/eth1.2/192.168.1.1' [✓]
Creating table 'TUN_US/tun0/10.20.0.6' [✓]
Creating table 'TUN_IN/tun1/10.16.0.8' [✓]
Creating table 'TUN_UK/tun2/10.17.0.34' [✓]
Routing 'LAN' via wan [✓]
Routing 'Michters' via TUN_US [✓]
Routing 'Amrut' via TUN_IN [✓]
Routing 'Ardbeg' via TUN_UK [✓]
vpn-policy-routing 0.2.2-2 started with gateways:
wan/eth1.2/192.168.1.1
TUN_US/tun0/10.20.0.6
TUN_IN/tun1/10.16.0.8
TUN_UK/tun2/10.17.0.34 [✓]
vpn-policy-routing 0.2.2-2 monitoring interfaces: wan TUN_US TUN_IN TUN_UK

I am also guessing because of this routing issue wireless speed is drastically reduced (from 500Mbps+ to ~50mbps). wired LAN is not affected at all.

hetasihow · November 12, 2020, 8:32pm

bump on this since i didn't get any responses. does anyone else have a hairpin nat working with this package?

stangri · November 13, 2020, 3:39am

If /etc/config/openvpn is missing option dev definitions that'd explain the observed behaviour.

stangri · November 13, 2020, 3:43am

Outside of config file for the local Plex server posted in the README I don't think I can contribute anything to this subject.

Wolfie · November 14, 2020, 6:50am

Based on the files you have shown, in your openvpn file, for the Michters (TUN_US) VPN settings, you need to have option dev 'tun0' as part of the other options so that it will always use 'tun0' which is what you have associated with "TUN_US" in your network settings.

In the 'multiple openvpn clients' section you linked to, look at the network options and the openvpn options. See how the dev 'ovpnc0' from the openvpn file matches up with the ifname of clientvpn0 from the network file? That option is telling openvpn to use that specific device when it connects. So in your openvpn file, assuming your VPN names are the same as your policy routing names, you'd have something like this:

config openvpn 'Michters'
  option client '1'
  option dev_type 'tun'
  option dev 'tun0'
  ...

config openvpn 'Amrut'
  option client '1'
  option dev_type 'tun'
  option dev 'tun1'
  ...

config openvpn 'Ardbeg'
  option client '1'
  option dev_type 'tun'
  option dev 'tun2'
  ...

This assigns them static tunX devices instead of dynamic ones, which is what is causing your issue.

Wolfie · November 14, 2020, 6:54am

I'm having an issue with multiple vpn clients. They are connecting, and in the summary at the top of VPR, it shows the default route along with tun0 and tun1, and the tun0 routes work, but when I try to use a tun1 route, there is no ipv4 connection.

wan/eth1/192.168.1.1 ✓
vpn0/tun0/10.7.7.2
vpn1/tun1/10.8.8.3

Do I need to show you the related settings, or do you know of something I can check to see if I can figure it out on my own?

Nove11 · November 14, 2020, 4:26pm

Thanks both for your inputs. I have these options already in my openvpn config file. FYI Here it is: (VPN names are same as tunnel interface names)

config openvpn 'TUN_USA'
        option config '/etc/openvpn/TUN_USA.ovpn'
        option enabled '1'
        option client '1'
        option dev_type 'tun'
        option dev 'tun0'

config openvpn 'TUN_IN'
	option config '/etc/openvpn/TUN_IN.ovpn'
	option enabled '1'
	option client '1'
	option dev_type 'tun'
	option dev 'tun1'

config openvpn 'TUN_UK'
	option config '/etc/openvpn/TUN_UK.ovpn'
	option enabled '1'
	option client '1'
	option dev_type 'tun'
	option dev 'tun2'

Now that i see the latest comment from @Wolfie . i noticed that default routes dont change when i change the wireless connection (or it changes randomly over time... not sure though )

wan/eth1.2/192.168.1.1
TUN_US/tun0/10.16.0.17
TUN_IN/tun1/10.17.0.5 [✓]
TUN_UK/tun2/10.16.0.6

Here is my observation:

This issue only comes from wireless interfaces.
Wired LAN (No VPN) for some reason works just fine. (I didnt test wired lan with VPN. )
wireless LAN (No VPN) uses DNS from one of the vpn interfaces. My default WLAN is associated with 'lan' interface so why does it use DNS from openvpn config?
wireless LAN (with VPN) uses DNS from one of the vpn interfaces. I believe it should change when i change the WLAN.
One or two tunnel interfaces takes while to come up, perhaps because vpn connection takes while to establish. Would that cause this kind of issue?

Here is part of my wireless configuration from /etc/config/wireless.

config wifi-iface 'wifinet1'
        option encryption 'psk2'
        option device 'radio0'
        option mode 'ap'
        option network 'WLAN_IN'
        option key 'ChangedForSharing'
        option ssid 'Amrut'

Would it make any difference if I manually configure openvpn instances instead of using ovpn files?

Wolfie · November 14, 2020, 8:06pm

Not a very secure password there.

My question here (not sure if it will help @stangri or not, since he's the brains of this and I'm just a fellow user), but... Is it necessary to have different wifi connections based on which VPN the user will be connecting through? In other words, everyone just connect to one wifi point or is it important that each group remains separate for some reason? If it's not 100% necessary, then it might be a good idea to trim it down to only one wifi connection (per radio), not only to simplify the overall issue, but keep your setup from being unnecessarily complex as well.

To be honest with you, and it wouldn't surprise me if I'm wrong, but having different wireless points (or not) shouldn't make a difference, as the routing of the VPN's is based on IP address. So if you have static IP's assigned to people (either on their computer or via the DHCP in the router), then regardless of which radio/ssid they connect to, it should always be the same for them. Like I said though, I could be wrong about that.

My setup, which is currently working with one VPN connection but seems to not work with a second one, is that the default route is wan (non VPN), with VPN routes being based on IP's. So if it matches an IP, it routes through a VPN. The issue I'm having is that there is no IPv4 connection on the client device when it's being routed through tun1 (second VPN connection). So in regards to security, it's at least not bypassing the VPN. Wanted to make sure to clarify that, as security is important. So at least I know VPR is doing something. Would be a real PITA if it was simply using the wan connection.

That said, the devices set to use tun0 (first VPN connection) all route through tun0. All other devices (ones not listed or just not active) go through wan. It eliminates the need for an entry to specify devices/IP's for the wan connection entirely.

Here's another question, which I believe will help with diagnosing the issue. Does tun1 always wind up as the default route (one with the checkmark)? Also, is it that all devices wind up using the same VPN connection, or are all three connections randomly used? My thought is that maybe the 'default' tun is the connection being used, with the others being ignored.

Edit: Are the IP's of the clients remaining the same after each reboot? Just want to touch on that to eliminate that as a possible cause.

Nove11 · November 15, 2020, 12:22am

As it says the password is changed for sharing here. and i am glad its confusing.

The thing is i potentially want to connect same device on different VPN. So static ip based routing wont be of much use. with multiple AP setup i can just switch to different SSID's to use different VPN's.

from your comment it appears to me that the fundamental problem is the same for both the issues (yours and mine). I might be wrong.

But i dont understand why wouldnt you get even the ip assignment for the client. That is not handled by VPR. Do you have DHCP server running with static ip assignment based on mac addresses?

EDIT: or is it that you get the IP address assignment on your client but the not the internet connection? then it could be related to VPR.

its totaly random for me. I couldnt find any pattern. The most closest thing i can say is that, after each reboot default route is set. and usually its either wan or whichever tunnel interface comes up first. for example, last time i rebooted during my last comment and since then default route is through tun1.

Also what is confusing me is that, in the current state when default route is set from tun1, the DNS being used is normally should only be available from tun0. This is critical.

interesting point. IP's of the clients remains the same and there is no static ip assignment.

Wolfie · November 15, 2020, 12:56am

I'm referring to internet IP not LAN IP. LAN IP's are mostly static DHCP, though I sometimes set a device to use a static IP if I'm tinkering with the router and might not get an assigned IP.

Try this... Set it up so that WAN is always the default route and see if the devices wind up using the WAN connection vs one of the VPN connections.

Also, are you saying that the devices are each using a random VPN connection? ie, during one cycle, one device is using US, another UK, third IN, but next cycle, the order is different? Or they all wind up using US, or UK, or IN, but never different ones at the same time?

Nove11 · November 15, 2020, 2:06am

once you get a LAN ip and if you run traceroute do you see it using right (or expected) tunnel interface?

when you say default route, you mean in VPR routing i should set all subnets routing to WAN interface? in that case, i have already tried that and it does correctly uses WAN interface. However DNS is still used from one of the tunnel interface. again this is only for WLANs.

EDIT:
if the cycyle = boot then yes thats the case. I ran the traceroute and it does use the correct tunnel interface but the ip addresses are from random VPN instances and they dont change until after reboot.

eg. first boot: if i connect to WLAN_US traceroute shows i am using tun0 (US) but public ip is from UK and DNS from (IN)
second boot: if i connect to WLAN_US traceroute shows i am using tun0 (US) but public ip is from IN and DNS from (IN)
so yes this is random and this is also a DNS leak. it is still secure because it does not use my ISP DNS but it slows down the internet IMO.

Wolfie · November 15, 2020, 4:45am

I know it's using the tun1 interface because VPR is trying to route it and the internet is lost to the device. When I disable the entry for the device, internet returns. Though a tracert wouldn't hurt, so I'll have to try that.

No, I mean setting the WAN device to be the default path as listed in the upper area where it lists the wan/tun0/tun1/tun2 devices with the IP's and a checkmark. ((( Click here )))

For me, I use that so that devices default to using WAN, unless in a list to use a VPN tun, instead of the VPN being the default.

With the cycling, yes, I do mean during a time the router is up after a reboot. Also, I'm referring only to the VPR/tun devices. Focus on having that working before worrying about the wireless. Easier to troubleshoot an issue in one place rather than multiple places. Once you have one issue resolved, then work on the other issue... if it still exists.

Nove11 · November 16, 2020, 12:38pm

this option does what it says but it didnt solve my problem.

However, configuring specific device (tunX) in .ovpn file solved the issue. Now i am looking into DNS leak problem.

Anyway Thanks a lot for your support.

Just a thought concerning your issue, did you double check your firewall rules?

Wolfie · November 17, 2020, 11:52am

Sorry about that. I told you to put it in the openvpn config file and not the .ovpn file because doing it that way actually works for me. I forgot that it'll work like that for me but not for others.

I have four FW's. LAN, WAN, VPN0 and VPN1 (to simplify it). Tried changing vpn1 to use the vpn0 firewall, no change. Changed to wan firewall, started working. Difference is it allows forwarding. So I enabled forwarding on vpn0 and vpn1 fw's and then changed vpn1 to use it's own firewall again. Working now.

Thanks for the idea!

gadgetguy08 · November 23, 2020, 4:03pm

I am seeing a version 0.3 (from 0.2.2-2) being available for OpenWrt but I can't find any description or changelog. Am I missing it?

rassamf · November 24, 2020, 6:37am

Hi guys, can anyone help me on how I can install VPN Policy onto gl-ar300m? https://openwrt.org/toh/gl.inet/gl.inet_gl-ar300m

It doesn't show up on the software list in openwrt. is there an easy way to add the repo and have it installed?

Thank you in advance

stangri · November 25, 2020, 1:59am

I've stopped doing changelog as it started to take not an insignificant amount of README.

Going by commits history, here are the changes from what's available in official repo:

initial support for TOR
refactor config auto-update (hopefully no more zeroed out config files)
support for IGNORE target rather than append src/dest policies
support for extra_command (for additional init script parameters)
refactor dest_ipset code (automatic use of dnsmasq.ipset on supported systems)
use GOTO instead of JUMP in VPR chains (faster iptables processing for high priority policies)

There were also numerous code cleanups/cosmetic fixes.

tombadog · November 25, 2020, 12:41pm

Does anyone have any advice on how to get inter VLAN communication working with VPN policy based routing installed. I need to able to communicate with a device on a separate VLAN in order to administrate it.

Thanks in advance.

bluenote · November 26, 2020, 7:46pm

Hey Stangri
I think I've observed a situation where the service is either not started or it stopped, and my IP was leaking. I actually stumbled on this by noticing the IP leak first. At that point I went to the luci PBR page, and saw that the service didn't seem to be running. (I didn't stop to look in detail on what it was saying, sorry, I just pressed 'start' as I recall). Concerned, I then rebooted the router, and noticed my DSCP tagged traffic was again getting out. I disabled and re-enabled the service from the startup page, and rebooted again, and was unable to reproduce the problem a third time.
Do you have any thoughts on what I should do here?
thx

stangri · November 27, 2020, 4:50am

Sorry, I'm not quite clear what the issue is and also what the desired outcome is.