stangri / source.openwrt.melmac.net Goto Github PK

Router Turri Omnia
OpenWrt omnia 15.05 r47055 / LuCI cc8b99aacec15490bb725fe53abefa1156cb5fe3 branch (git-18.123.42193-cc8b99a)
Kernel 4.4.131-a2dbf3bef3d0c1f725e0a5f0801935a1-2
openvpn-openssl 2.4.4-1
vpn-policy-routing 0.0.1-25 (option strict_enforcement '1')

Rebooting the linux os server which is hosting the openvpn server is logically disrupting the vpn tunnel.
With the openvpn client on the router re-establishing the vpn tunnel automatically (connect-retry 10 /
resolv_retry infinite) as soon as the vpn server gets back online but the traffic which is supposed to be routed via VPN tunnel by PBR is now routed via WAN suddenly and thereby apparently neglecting/circumventing option strict_enforcement '1'

Router Turri Omnia
OpenWrt omnia 15.05 r47055 / LuCI cc8b99aacec15490bb725fe53abefa1156cb5fe3 branch (git-18.123.42193-cc8b99a)
Kernel 4.4.131-a2dbf3bef3d0c1f725e0a5f0801935a1-2

PBR is starting prior the ovpn tun is up during router boot and thus fails to create a routing table for the tun

notice [2569]: Creating table 'wan/pppoe-wan/ip.redacted' [✓]
notice openvpn[2546]: TCP/UDP: Preserving recently used remote address: [AF_INET]ip.redacted:61023
notice openvpn[2546]: UDPv4 link local (bound): [AF_INET]192.168.112.12:61023
notice openvpn[2546]: UDPv4 link remote: [AF_INET]ip.redacted:61023
notice openvpn[2546]: VERIFY OK: depth=2,
notice openvpn[2546]: VERIFY OK: depth=1,
notice openvpn[2546]: VERIFY KU OK
notice openvpn[2546]: Validating certificate extended key usage
notice openvpn[2546]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
notice openvpn[2546]: VERIFY EKU OK
notice openvpn[2546]: VERIFY OK: depth=0,
notice openvpn[2546]: peer info: IV_VER=2.4.4
notice openvpn[2546]: peer info: IV_PLAT=linux
notice openvpn[2546]: peer info: IV_PROTO=2
notice openvpn[2546]: peer info: IV_LZ4=1
notice openvpn[2546]: peer info: IV_LZ4v2=1
notice openvpn[2546]: peer info: IV_LZO=1
notice openvpn[2546]: peer info: IV_COMP_STUB=1
notice openvpn[2546]: peer info: IV_COMP_STUBv2=1
notice openvpn[2546]: peer info: IV_TCPNL=1
notice openvpn[2546]: peer info: IV_SSL=OpenSSL_1.0.2l__25_May_2017
notice openvpn[2546]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
2018-05-11 22:49:00 notice openvpn[2546]: [CA OVPN Server] Peer Connection Initiated with [AF_INET]ip.redacted:61023
notice [2569]: Creating table 'ovpn/tun0/0.0.0.0' [✗]
notice [2569]: Routing 's5' via wan [✓]
notice [2569]: Routing 's1' via wan [✓]
notice [2569]: Routing 'da' via wan [✓]
notice [2569]: Routing '1750e' via wan [✓]
notice [2569]: Routing 'dvb-c' via wan [✓]
notice [2569]: Routing 'stv9s' via wan [✓]
notice [2569]: Routing 'lan' via wan [✓]
notice [2569]: service started on wan/pppoe-wan/ip.redacted with errors [✗]
notice [2569]: ERROR: Failed to set up 'ovpn/tun0/0.0.0.0'
notice openvpn[2546]: Data Channel: using negotiated cipher 'AES-256-GCM'
notice openvpn[2546]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
notice openvpn[2546]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
notice openvpn[2546]: TUN/TAP device tun0 opened
notice openvpn[2546]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
notice openvpn[2546]: /sbin/ifconfig tun0 172.24.120.2 netmask 255.255.255.0 mtu 1500 broadcast 172.24.120.255
notice netifd[]: Interface 'ovpn' is enabled
notice netifd[]: Network device 'tun0' link is up
notice netifd[]: Interface 'ovpn' has link connectivity
notice netifd[]: Interface 'ovpn' is setting up now
notice netifd[]: Interface 'ovpn' is now up
notice openvpn[2546]: UID set to nobody
notice openvpn[2546]: Initialization Sequence Completed

When Linksys boot partition was modified from U-Boot (with setenv bootcmd ...; saveenv), the 'Current' and 'Alternative' partitions are swapped-out in the luci-app-advanced-reboot Luci GUI (and thus, do not depict reality).
Sometimes it is required to set the boot partition from U-Boot, for example when a partition does not have luci-app-advanced-reboot installed. In such a case, luci-app-advanced-reboot GUI should update its view.

0.0.1-25

It appears that icmp traffic is routed outside the PBR assigned vpn tunnel, at least ovpn tun (did not test others). Which can be a bit confusing if debugging with tracert from a Win box as the OS is utilizing icmp for tracert, and ping naturally.

luci-app-vpn-policy-routing | git-18.194.53747-b383..-29
vpn-policy-routing | 0.0.2-17

TOS 3.10.3 ({"kernel":"4.4.138-1e8e1b4c23f383e990eb3c4f490f5f2e-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}})

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option udp_proto_enabled '1'
	option strict_enforcement '1'
	list ignored_interface 'guest'
	list ignored_interface 'tun'
	option enabled '1'

referenced #18 (comment) and #18 (comment)

So far discovered no correlation between the VPR settings in general or the number of assigned policies in particular. In this box the total number of reloads always counts to 11 and thus making it 10 redundant reloads.

Router Turri Omnia
OpenWrt omnia 15.05 r47055 / LuCI 526a8767846acbe57c521912b35feb4d97354db6 branch (git-18.145.30016-526a876)
Kernel 4.4.134-8f7f4132dc88fb7034ce9648e5961be5-0
luci-app-vpn-policy-routing | git-18.151.61791-fed3..-23
vpn-policy-routing | 0.0.2-2

mentioned https://forum.turris.cz/t/vpn-policy-based-routing-possible/7204/23

After updating the router's OS from TOS 3.10 to 3.10.1 and issue #7 the workaround of getting PBR to work after a reboot is not working anymore, as in pressing Save & Apply (/cgi-bin/luci/admin/services/vpn-policy-routing) is not having any effect.

Only way to get PBR after a router's reboot is connecting to the TO over ssh and then from the command line

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

Router Turris Omina
Firmware OpenWrt omnia 15.05 r47055 / LuCI 49c3edd5861fd032fa8379ceda525c27a908a114 branch (git-17.212.24321-49c3edd)
luci-app-vpn-policy-routing git-18.122.73605-3f51..-22
vpn-policy-routing 0.0.1-24

Unfortunately this package is not available in the Turris Omnia repo but furtunately some OpenWRT user brought it up in the TO forum and the app installed without a hitch and seems to be working well.

Yet the log is showing the errors and since not being sure of the relevance wanted to make you aware at least.

notice [32269]: Creating table 'lan/br-lan/0.0.0.0' [✗]
notice [32269]: Routing '' via wan [✗]
notice [32269]: service started on wan/pppoe-wan/<ip.redacted> wg0/wg0/<ip.redacted> with errors [✗]
notice [32269]: ERROR: Failed to set up 'lan/br-lan/0.0.0.0'
ERROR: policy comment is empty!
notice [32269]: service monitoring interfaces: lan wan wg0 [✓]

https://github.com/stangri/openwrt_packages/blob/fe4541878e502b6088252538abef01218ac03591/vpn-policy-routing/files/vpn-policy-routing.init#L526

This line of code doesn't suppress the module is already loaded warning messages in system log.
I have to add 2>/dev/null at the end of each modprobe command to completely suppress them.

modprobe xt_set 2>/dev/null
modprobe ip_set 2>/dev/null
modprobe ip_set_hash_ip 2>/dev/null

Or you can make some error handling by checking exit code (modprobe returns 255 if it can't find/load the module, returns 0 if it loads the module or already loaded):

modprobe xt_set 2>/dev/null &&
modprobe ip_set 2>/dev/null &&
modprobe ip_set_hash_ip 2>/dev/null ||
echo "failed to load module"

@stangri

Just updated to 0.0.2-29 and /etc/init.d/vpn-policy-routing restart producing

vpn-policy-routing 0.0.2-29 stopped [✓]
ERROR: vpn-policy-routing 0.0.2-29 failed to load kernel modules!

That is on TOS 3.10.8 (OpenWrt omnia 15.05 r47055 with kernel 4.4.161)

cross reference https://forum.turris.cz/t/vpn-policy-routing-broke-in-last-os-update/8800

I have such weird configuration: openconnect → l2tp → dhcp wan. And your script detects l2tp as wan here. When l2tp detected as wan branch there is some error in ipt function call at point --set-xmark /0xff0000, it looks like mark variable is empty, so iptables call fails.
I change order of checks (tunnel before wan) and it looks like my case is resolved, but I don't really now how this change will affect other cases.
I'm tired of diggin into bash hieroglyph-spaghetti 🤣 so no extra information. If you want I can paste any config you need.

TOS 3.10.3 ({"kernel":"4.4.138-1e8e1b4c23f383e990eb3c4f490f5f2e-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}})

After having updated to 0.0.2-22 and applied some VPR settings the router went into a reboot loop, rebooting every few minutes.
Even disabling VPR between reboots did not solve it.

Had to rollback the router (0.0.2-21) and since then the reboots have ceased.

Since the systemlog is rolled over at each reboot it was not possible to gather information of how VPR exactly causes the reboots.

https://github.com/stangri/openwrt_packages/blob/da75d0209a483fd50687ab5d37e17a1adb26f233/luci-app-advanced-reboot/Makefile#L11 "altnerative"

Hello,

I'm receiving the following error when running make defconfig or make menuconfig when configuring a build for the LEDE master branch. This error does NOT occur when building against LEDE 17.01:

$ make defconfig
tmp/.config-package.in:90388:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:90388:	symbol PACKAGE_vpn-policy-routing depends on PACKAGE_vpnbypass
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:90407:	symbol PACKAGE_vpnbypass depends on PACKAGE_vpn-policy-routing
#
# configuration written to .config
#

I tried digging but I can't quite figure out what is causing the issues. Let me know if I can provide any other information that would be helpful for troubleshooting.

@stangri

Since recently VPR is not picking up a firewall restart which flushes all rules and thus any policy based connectivity ceases until VPR is manually restarted. A firewall reload though is detected by VPR.

Had a look at the TOS code base to see if anything changed in their firewall init script between the last releases but it has not. It seems thus likely being a regression bug introduced with 0.0.2-34.

Please let me know if there is anything to debug the issue.

TOS 3.11.1 | vpn-policy-routing 0.0.2-34 | firewall 2018-06-13

{"kernel":"4.4.167-4a7a81f8db0ad743e54c68e1845c60b6-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}

Router Turri Omnia
OpenWrt omnia 15.05 r47055 / LuCI cc8b99aacec15490bb725fe53abefa1156cb5fe3 branch (git-18.123.42193-cc8b99a)
Kernel 4.4.131-a2dbf3bef3d0c1f725e0a5f0801935a1-2
kmod-wireguard 4.4.131+0.0.20171017-..1-2 (option route_allowed_ips '0')
vpn-policy-routing 0.0.1-25

There is no traffic between the wg ifaces, peers cannot be pinged or tracerouted. Switching option udp_proto_enabled did not make a difference. Made sure that the WG tunnel is actual up and the peers are connected.

config policy
	option local_addresses '192.168.112.120'
	option comment 's5'
	option interface 'wan'

config policy
	option comment 's1'
	option local_addresses '192.168.112.121'
	option interface 'wan'

config policy
	option comment 'da'
	option local_addresses '192.168.112.160'
	option interface 'wan'

config policy
	option comment '1750e'
	option local_addresses '192.168.112.190'
	option interface 'wan'

config policy
	option comment 'dvb-c'
	option local_addresses '192.168.112.191'
	option interface 'wan'

config policy
	option comment 'stv9s'
	option local_addresses '192.168.112.122'
	option interface 'wan'

config policy
	option interface 'wan'
	option comment 'oc_vpscp'
	option remote_addresses '<redacted>'
	option remote_ports '4083'

config policy
	option comment 'lan'
	option local_addresses '192.168.112.12/24'
	option interface 'wg0'

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	list ignored_interface 'guest'
	option enabled '1'
	option udp_proto_enabled '1'

/etc/init.d/vpn-policy-routing reload
Creating table 'wan/pppoe-wan/<redacted' [✓]
Creating table 'wg0/wg0/172.25.120.2' [✓]
Routing 's5' via wan [✓]
Routing 's1' via wan [✓]
Routing 'da' via wan [✓]
Routing '1750e' via wan [✓]
Routing 'dvb-c' via wan [✓]
Routing 'stv9s' via wan [✓]
Routing 'oc_vpscp' via wan [✓]
Routing 'lan' via wg0 [✓]
vpn-policy-routing 0.0.1-25 started on wan/pppoe-wan/<redacted> wg0/wg0/172.25.120.2 [✓]
vpn-policy-routing 0.0.1-25 monitoring interfaces: wan wg0 [✓]

/etc/init.d/vpn-policy-routing support
vpn-policy-routing 0.0.1-25 running on OpenWrt Chaos Calmer. WAN (IPv4): wan/dev/<redacted>. WAN (IPv6): wan/dev6/::/0.
============================================================
Dnsmasq version 2.78  Copyright (c) 2000-2017 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify
============================================================
Routes/IP Rules
default         ppp-gw-pop107.r 0.0.0.0         UG    0      0        0 pppoe-wan
32712:  from all fwmark 0x20000 lookup 202
32713:  from all fwmark 0x10000 lookup 201
IPv4 Table 201: default via <redacted> dev pppoe-wan
IPv4 Table 202: default via 172.25.120.2 dev wg0
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 192.168.112.0/24 -m comment --comment lan -c 213 33355 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -d <redacted>/32 -p udp -m multiport --dports 4083 -m comment --comment oc_vpscp_<redacted> -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -d <redacted>/32 -p tcp -m multiport --dports 4083 -m comment --comment oc_vpscp_<redacted> -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.112.122/32 -m comment --comment stv9s -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.112.191/32 -m comment --comment dvb-c -c 2 120 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.112.190/32 -m comment --comment 1750e -c 2 120 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.112.160/32 -m comment --comment da -c 1 40 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.112.121/32 -m comment --comment s1 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.112.120/32 -m comment --comment s5 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -m set --match-set wg0 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
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create wg0 hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]

Whilst the readme is bare of any hint about tor routing the init script code though has some related snippets on display and thus wondering whether/how routing via tor might work, considering tor is not providing an iface but a SOCKET5 proxy?

I am currently running a tor client node with username/password credentials and would like to route onion. centrally from the router rather than with a proxy browser plugin for each client.
One other issue comes to mind - resolving tor domains, which currently is set in the browser plugin with Send DNS through SOCKS5 proxy
I am also looking whether that DNS can be handled centrally by the router's DNS server (unbound) but have not reached a solution yet.

• luci-app-vpn-policy-routing | git-18.192.22043-6f77..-27
• vpn-policy-routing | 0.0.2-11
• TOS 3.10.3 (OpenWrt omnia 15.05 r47055 / LuCI 526a8767846acbe57c521912b35feb4d97354db6 branch (git-18.145.30016-526a876)
• kernel 4.4.138-1e8e1b4c23f383e990eb3c4f490f5f2e-1

Service status remains static @ Service is disabled/stopped despite running and subsequent the button constantly showing Enable/Start

{"kernel":"4.4.150-0a333a8e606ab056173befac424900d2-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}

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

vpn-policy-routing 0.0.2-25 running on OpenWrt Chaos Calmer. WAN (IPv4): wan/dev/

Dnsmasq version 2.78 Copyright (c) 2000-2017 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify

ERROR: curl, libopenssl or ca-bundle were not found!
Run 'opkg update; opkg install curl libopenssl ca-bundle' to install them.

opkg update; opkg install curl libopenssl ca-bundle

Package curl (7.60.0-1) installed in root is up to date.
Package libopenssl (1.0.2o-1) installed in root is up to date.
Package ca-bundle (20180409-2) installed in root is up to date.

root@OpenWrt:~# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
VPR_PREROUTING all -- anywhere anywhere [goto] mark match 0x0/0xff0000
mwan3_hook all -- anywhere anywhere
...

At boot, sometimes, the VPR_PREROUTING and mwan3_hook priority is inverted. As a result the VPN rules are ignored.

Currently I don't have the second wan up&running so I can't test what happens to mwan rules but I suspect that VPR bypasses mwan. I need to use both: any idea?

Regards

I'm getting the following error when updating the openwrt_packages feed from git. I also tried cloning the repo locally and using src-cpy and src-link but the results were the same:

Updating feed 'stangri' from 'https://github.com/stangri/openwrt_packages.git' ...
Cloning into './feeds/stangri'...
remote: Counting objects: 148, done.
remote: Compressing objects: 100% (96/96), done.
remote: Total 148 (delta 13), reused 132 (delta 7), pack-reused 0
Receiving objects: 100% (148/148), 1.05 MiB | 1.26 MiB/s, done.
Resolving deltas: 100% (13/13), done.
Create index file './feeds/stangri.index' 
ERROR: please fix feeds/stangri/luci-app-advanced-reboot/Makefile - see logs/feeds/stangri/luci-app-advanced-reboot/dump.txt for details
ERROR: please fix feeds/stangri/luci-app-easyflash/Makefile - see logs/feeds/stangri/luci-app-easyflash/dump.txt for details
ERROR: please fix feeds/stangri/luci-app-simple-adblock/Makefile - see logs/feeds/stangri/luci-app-simple-adblock/dump.txt for details
ERROR: please fix feeds/stangri/luci-app-vpn-policy-routing/Makefile - see logs/feeds/stangri/luci-app-vpn-policy-routing/dump.txt for details
ERROR: please fix feeds/stangri/luci-app-vpnbypass/Makefile - see logs/feeds/stangri/luci-app-vpnbypass/dump.txt for details
ERROR: please fix feeds/stangri/luci-mod-alt-reboot/Makefile - see logs/feeds/stangri/luci-mod-alt-reboot/dump.txt for details

Editing the Makefiles and changing the ../../luci.mk path to ../../luci/luci.mk resolves the issue for me. I can submit a PR if you want but I wanted to make sure I wasn't doing something wrong on my end first.

I'm trying to move from vpnbypass which correctly identified my wwan interface, but it seems this project doesn't detect wwan as a wan interface

0.0.2-16

It seems that VPR is trying to configure a tun iface which is dormant. The iface is present in /etc/config/network but otherwise dormant/dead

ip a ls tun or ip l ls tun

Device "tun" does not exist.

and yet VRP is trying to set it up

err modprobe[]: xt_set is already loaded
err modprobe[]: ip_set is already loaded
err modprobe[]: ip_set_hash_ip is already loaded
notice [9347]: Creating table 'wan/84.[truncated]' [✓]
notice [9347]: Creating table 'tun/0.0.0.0' [✗]
notice [9347]: Creating table 'wg0/192.168.112.12' [✓]
notice [9347]: Routing 's5' via wan [✓]
notice [9347]: Routing 's1' via wan [✓]
notice [9347]: Routing 'da' via wan [✓]
notice [9347]: Routing '1750e' via wan [✓]
notice [9347]: Routing 'dvb-c' via wan [✓]
notice [9347]: Routing 'stv9s' via wan [✓]
notice [9347]: Routing 'oc_vpscp' via wan [✓]
notice [9347]: Routing 'oc_vnc' via wan [✓]
notice [9347]: Routing 'oc_ssh' via wan [✓]
notice [9347]: Routing 'lan' via wan [✓]
notice [9347]: service started on wan/84.[truncated] wg0/192.168.112.12 with errors [✗]
notice [9347]: ERROR: Failed to set up 'tun/0.0.0.0'

• TOS 3.10.4 {"kernel":"4.4.147-0a333a8e606ab056173befac424900d2-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}
• vpn-policy-routing 0.0.2-24
• luci-app-vpn-policy-routing git-18.225.48207-809d3b9-33

trying to install VPR via LuCI the following is reported

Installing luci-app-vpn-policy-routing (git-18.225.48207-809d3b9-33) to root...
Downloading https://raw.githubusercontent.com/stangri/openwrt-repo/master/luci-app-vpn-policy-routing_git-18.225.48207-809d3b9-33_all.ipk

Collected errors:

• satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-vpn-policy-routing:
• vpn-policy-routing *
• opkg_install_cmd: Cannot install package luci-app-vpn-policy-routing.

opkg search '*vpn-policy-routing*' comes up empty

I am intending to switch from ipt to nft but that would render this package not working as currently being based on ipt and ipset.

One of the many benefits of nft is the independency of ipset since it features its own sets

TOS 3.11.2 RC | vpn-policy-routing 0.0.2-35 | luci-app-vpn-policy-routing git-19.006.40074

{"kernel":"4.4.169-7bc33afbb1b35f5830b2b1b42c9cd8a0-2","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}

I have a got a few lxc guests on the router (host) with ip subnets (l3 dev bridge) different from the router (host) and I would consider each such lxc guest being just another lan client to the router.

With the below conf I would expect ingress to 10.169.112.0/24 via nc and egress from 10.169.112.0/24 via wg.
However, once activated 10.169.112.0/24 becomes inaccessible and I am bothering you because apparently I cannot see why this happening.

Not sure if I got my routing logic mixed up?

config policy
	option remote_addresses '10.169.112.0/24'
	option interface 'nc'
	option name 'router-nc-ingress'

config policy
	option name 'router-nc-egress'
	option local_addresses '10.169.112.0/24'
	option interface 'wg0'

config policy
	option name 'lan'
	option local_addresses '192.168.112.12/24'
	option interface 'wg0'

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	list ignored_interface 'guest'
	option udp_proto_enabled '1'
	list supported_interface 'nc'
	option enabled '1'

Router Turri Omnia
OpenWrt omnia 15.05 r47055 / LuCI cc8b99aacec15490bb725fe53abefa1156cb5fe3 branch (git-18.123.42193-cc8b99a)
Kernel 4.4.131-a2dbf3bef3d0c1f725e0a5f0801935a1-2
BusyBox v1.25.1
openvpn-openssl 2.4.4-1
vpn-policy-routing 0.0.1-25

With traceroute wrapped in BusyBox it is lacking the -T option (TCP) and thus only UDP can be utilized.
It seems that UDP traffic however is routed outside the VPN iface designated by PBR despite being set in advanced options:

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	list ignored_interface 'guest'
	option enabled '1'
	option udp_proto_enabled '1'

Running traceroute is showing as heading trough the WAN only. Suppose that holds true for other UDP traffic then too.

The above based on ovpn tun.

Would be possible to add split DNS, say:

• client 1 routed via WAN with WAN DNS resolver
• client 2 routed via WAN but with router (127.0.0.1) DNS resolver
• client 3 routed via VPN with VPN DNS resolver
• client 4 routed via VPN but with router (127.0.0.1) DNS resolver

It would be handy to add an Enable option to rules in the list. Like in openwrt firewall rules list.

The policy section in this image of your openwrt_package shows it does only give the possibility to delete a rule to temporarily disable it. Even a moved rule would be readed obviosly.

@stangri

It may not be a widely deployed user scenario but right now it is possible to add/delete a policy but not to pause/resume such, only globally for VPR (or editing the config via ssh and restarting VPR).

When one is testing or deploying policies only intermittent it thus requires policies to be deleted and added every time and thus pausing/resuming policies would add usability through the UI

Please kindly add support for Firefox Detect portal. When you connect to Firefox seems to check for this address: http://detectportal.firefox.com/success.txt

Perhaps just adding entry detectportal.firefox.com with policy fake should fix this bug?

luci-app-vpn-policy-routing | git-18.194.53747-b383..-29
vpn-policy-routing | 0.0.2-17

TOS 3.10.3 ({"kernel":"4.4.138-1e8e1b4c23f383e990eb3c4f490f5f2e-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}})

config interface 'wan'
	option ifname 'eth1'
	option proto 'pppoe'
	option username '[obfuscated]'
	option password '[obfuscated]'
	option delegate '0'
	option ipv6 '0'
	option peerdns '0'

ISP is rolling over WAN ip every 24 hours and also issuing a new ip on router reboot, however noticed that VPR is not picking up those new ips and instead is stuck with the same old one.

This becomes only apparent from the logs

Creating table 'wan/[same old ip]
service started on wan/[same old ip]

It seems that it is owed to the ISP's PPOE routing table. The router log showing after reboot

notice pppd[2960]: local IP address [actual WAN ip]
notice pppd[2960]: remote IP address [ISP gateway ip and the one reported by VPR]

ip r

default via [ISP gateway ip and the one reported by VPR] dev pppoe-wan proto static
[ISP gateway ip and the one reported by VPR] dev pppoe-wan proto kernel scope link src [actual WAN ip]

ip a ls pppoe-wan

pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet [actual WAN ip] peer [ISP gateway ip and the one reported by VPR] scope global pppoe-wan
valid_lft forever preferred_lft forever

Not sure whether it is actuallly a bug or the correct/expected behaviour and whether it has an inclemement impact on the routing tables created by VPR.

OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)

WireGuard

Installed according to the manual, all dep met.

All connections, randomly, either go through WAN or not routed at all.

@n8v8R -- can you please test something for me,
can you please place the following into file /etc/hotplug.d/iface/70-vpn-policy-routing:

#!/bin/sh

if [[ "$ACTION" == "ifup" ]]; then
  /etc/init.d/vpn-policy-routing reload
fi

Might need to also do chmod +x /etc/hotplug.d/iface/70-vpn-policy-routing.

Then manually stop and restart openvpn and see if you see any traces of VPR reloaded in the system log (wherever it is on TurrisOS).

Info and needed configs and logs

Device: TP-Link WR-842ND
OS: OpenWrt 18.06.2, r7676-cddd7b4c77

cat /etc/config/vpn-policy-routing

config vpn-policy-routing 'config'
        option ipv6_enabled '0'
        option strict_enforcement '1'
        option dnsmasq_enabled '1'
        option verbosity '2'
        option enabled '1'

config policy
        option chain 'PREROUTING'
        option name 'news'
        option remote_address 'bbc.com bbc.co.uk bbci.co.uk arstechnica.net arstechnica.com'
        option proto 'tcp udp'
        option interface 'wg0'

config policy
        option chain 'PREROUTING'
        option name 'other'
        option remote_address 'myip.com'
        option interface 'wg0'
        option proto 'tcp udp'

/etc/init.d/vpn-policy-routing status
vpn-policy-routing 0.0.4-1 running on OpenWrt 18.06.2. WAN (IPv4): wan/dev/192.168.49.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         192.168.49.1    0.0.0.0         UG    0      0        0 eth0
IPv4 Table 201: default via 192.168.49.1 dev eth0
IPv4 Table 201 Rules:
32765:  from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via 10.180.83.84 dev wg0
IPv4 Table 202 Rules:
32764:  from all fwmark 0x20000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -m set --match-set wg0 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
============================================================
IP Tables FORWARD
-N VPR_FORWARD
============================================================
IP Tables INPUT
-N VPR_INPUT
============================================================
IP Tables OUTPUT
-N VPR_OUTPUT
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create wg0 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
Creating table 'wan/192.168.49.1' [✓]
Creating table 'wg0/10.180.83.84' [✓]
Routing 'news' via wg0 [✓]
Routing 'other' via wg0 [✓]
vpn-policy-routing 0.0.4-1 started on wan/192.168.49.1 wg0/10.180.83.84 [✓]
vpn-policy-routing 0.0.4-1 monitoring interfaces: wan wg0 [✓]

Issue Description

Hi and thanks for this great package. I've been using this on Openwrt 18.6.1 for few months and it was mostly ok. yesterday I clean installed OpenWRT 18.6.2 and tried whole day to make it work, but no luck!
not all intended Traffic is routed to wireguard interface, especially level 3 domains that are CNAME of another domain.

Wireguard Interface is set up on wg0 and working.

wg show all
interface: wg0
  public key: a2svsHWlAUsomegibberrishZWqz//hSU=
  private key: (hidden)
  listening port: 57259

peer: EcxHFjc20blahblahblahblahblahblahLOUIgI=
  endpoint: 190.2.141.163:51840
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 43 seconds ago
  transfer: 3.32 KiB received, 5.45 KiB sent
  persistent keepalive: every 25 seconds

here is the ping through wg0 interface:

ping myip.com -I wg0
PING myip.com (104.31.67.68): 56 data bytes
64 bytes from 104.31.67.68: seq=0 ttl=58 time=122.680 ms
64 bytes from 104.31.67.68: seq=1 ttl=58 time=124.160 ms
64 bytes from 104.31.67.68: seq=2 ttl=58 time=122.523 ms
64 bytes from 104.31.67.68: seq=3 ttl=58 time=121.246 ms

In VPR have redirected arstechnica.com and arstechnica.net to wg0.
When I traceroute arstechnica.com on a PC in LAN, everything is ok:

tracert arstechnica.com

Tracing route to arstechnica.com [50.31.169.131]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  abyss-r.local [192.168.48.1]
  2   119 ms   119 ms   122 ms  190.2.141.163
  3   117 ms   119 ms   119 ms  172.16.0.1
  4   120 ms   124 ms   119 ms  190.2.141.3
  5   121 ms   119 ms   118 ms  109.236.95.184
  6   123 ms   120 ms   119 ms  be4381.rcr21.rtm01.atlas.cogentco.com [149.6.110.89]
  7   121 ms   129 ms   120 ms  be3384.ccr41.ams03.atlas.cogentco.com [154.54.58.165]
  8   122 ms   122 ms   127 ms  be3499.rcr22.ams05.atlas.cogentco.com [154.54.60.22]
  9   124 ms   126 ms   134 ms  level3.fra06.atlas.cogentco.com [130.117.15.194]
 10   214 ms   218 ms   217 ms  xe-4-2-2.cr2-chi1.ip4.gtt.net [89.149.143.97]
 11   217 ms   216 ms   233 ms  as23352.chi12.ip4.gtt.net [199.229.229.214]
 12   215 ms   216 ms   216 ms  0.ae4.cr1.ord6.scnet.net [204.93.204.85]
 13   223 ms   216 ms   216 ms  0.ae1.ar3.ord6.scnet.net [204.93.204.109]
 14   223 ms   242 ms   234 ms  vlan-41.aggrdl114-1.ord6.scnet.net [167.88.157.25]
 15   216 ms   216 ms   217 ms  ge-11-2-1.ar9.ord6.us.scnet.net [50.31.169.130]
 16   217 ms   217 ms   218 ms  ge-11-2-1.ar9.ord6.us.scnet.net [50.31.169.130]
 17   217 ms   219 ms   220 ms  ge-11-2-1.ar10.ord6.us.scnet.net [50.31.169.131]

as you can see 2nd hop is my WG endpoint.

But if I traceroute cdn.arstechnica.net:

tracert cdn.arstechnica.net

Tracing route to vip1.g5.cachefly.net [205.234.175.175]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  abyss-r.local [192.168.48.1]
  2     1 ms    <1 ms     1 ms  192.168.49.1
  3    36 ms    31 ms    31 ms  94-183-140-6.shatel.ir [94.183.140.6]
  4    31 ms    31 ms    31 ms  94-183-140-1.shatel.ir [94.183.140.1]
  5    35 ms    34 ms    34 ms  172.18.74.113
  6    44 ms    36 ms    36 ms  172.18.218.145
  7    42 ms    37 ms    36 ms  172.18.196.65
  8    41 ms    36 ms    36 ms  172.18.196.90
  9    43 ms    39 ms    43 ms  10.202.4.132
 10    37 ms    37 ms    37 ms  10.21.211.20
 11   110 ms   109 ms   108 ms  et-5-0-1-0.ffttr6.frankfurt.opentransit.net [193.251.154.203]
 12   111 ms   108 ms   109 ms  et-14-0-7-0.ffttr7.frankfurt.opentransit.net [193.251.132.163]
 13   114 ms   112 ms   112 ms  be5511.agr41.fra03.atlas.cogentco.com [130.117.14.225]
 14     *        *        *     Request timed out.
 15   110 ms   110 ms   110 ms  vip1.g-anycast1.cachefly.net [205.234.175.175]

2nd hop is my upstream router, not WG endpoint. So no cdn.arstechnica.net content is being redirected to wg0. Can someone tell me where the problem is?

This commit openwrt/luci@90bf08a introduced a new package named luci-nginx, which uses nginx as its web server, while the old luci package uses uHTTPd.
With the dependency on luci, I can't deselect uhttpd despite no need for it.

@stangri

There seems to be a mismatch in parsing a bridge iface name br-guest from supported interface - it turns up as guest only in the other options. Since there is no actual guest interface on the system the routing policy fails and the log output shows:

service started on (strict mode): guest/0.0.0.0 [✓]

config vpn-policy-routing 'config'
	option enabled '1'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	option udp_proto_enabled '1'
	option wan_dscp '1'
	option wg0_dscp '2'
	option guest_dscp '3'
	list supported_interface 'br-guest'

config policy
	option name 'router-hpot'
	option remote_addresses '10.168.112.67'
	option remote_ports '56007'
	option interface 'guest'
	option local_addresses '192.168.112.12/24'

Changing the guest entries manually via ssh edit into br-guest and then refreshing the LuCI page produces:

The configuration file could not be loaded due to the following error:
uci: Parse error (invalid character in name field)

Is this a UCI bug/limitation rather than VPR?

TOS 3.11.1 | vpn-policy-routing 0.0.2-32 | luci git-18.328.59464-9636605-1

{"kernel":"4.4.167-4a7a81f8db0ad743e54c68e1845c60b6-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}

Sending SIGTERM to the process works, but PROCD fails to kill it.

Tagging @anselal.

luci-app-vpn-policy-routing | git-18.194.53747-b383..-29
Remove | vpn-policy-routing | 0.0.2-17

TOS 3.10.3 ({"kernel":"4.4.138-1e8e1b4c23f383e990eb3c4f490f5f2e-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}})

Not sure whether it is a bug or by design, however having VPR disabled via LuCI and afterwards trying to start it from cli with /etc/init.d/vpn-policy-routing start produces

vpn-policy-routing is currently disabled.
Run the following commands before starting service again:
uci set vpn-policy-routing.config.enabled='1'; uci commit;

Same happens when VPR is disabled via LuCI and in that state changing VPR settings via LuCI and pressing save & apply in LuCI

After disabling VPR via LuCI, and returning traffic to wan, there is no connectivity however. Restarting/reloading network a/o firewall does not remedy the issue but only rebooting the router.

• {"kernel":"4.4.172-7bc33afbb1b35f5830b2b1b42c9cd8a0-0","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}
• TOS 3.11.3 RC3
• vpn-policy-routing 0.0.3-3
• luci-app-vpn-policy-routing git-19.035.52233-21b2..-36
• Wireguard 0.0.20190123

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	option proto_control '1'
	option chain_control '1'
	option enabled '0'

config policy
	option interface 'wan'
	option name 'oc-ssh'
	option remote_addresses 'x.x.174.98'
	option remote_ports '56009'
	option chain 'PREROUTING'
	option proto 'tcp udp'

config policy
	option interface 'wan'
	option name 'oc-vps-cp'
	option remote_addresses 'foo.bar'
	option chain 'PREROUTING'
	option proto 'tcp udp'

config policy
	option interface 'wan'
	option name 'oc-vnc'
	option remote_addresses 'x.x.152.30'
	option remote_ports '5903'
	option chain 'PREROUTING'
	option proto 'tcp udp'

config policy
	option name 'lan'
	option local_addresses '192.168.84.0/24'
	option interface 'wg0'
	option chain 'PREROUTING'
	option proto 'tcp udp'

Please kindly add support for Gnome Network manager in fakeinternet. When Gnome connects, it checks the following network address. Thanks!

http://nmcheck.gnome.org/check_network_status.txt
NetworkManager is online

I'm not sure if it's a bug or just my setup but i'm trying to use VPR with "strict enforcement" but i loose access to my Modem if this option is enabled.
I don't have much expirience with VPR and routing in generel but problem seems to be that there is no gateway IP set for my modem interface and thereore VPR reports the modem gateway IP as 0.0.0.0.

Router: WRT3200ACM
Build: davidc502, Lede SNAPSHOT r7829-42dc0e2594 / LuCI Master (git-18.222.53504-c2d36ba)
Versions i've tested so far: 0.0.2-26, 0.0.2-27, 0.0.2-28

Modem interface config (Modem IP is 192.168.254.254):

config interface 'modem'
        option proto 'static'
        option ifname 'eth1.2'
        option ipaddr '192.168.254.1'
        option netmask '255.255.255.0'
        option delegate '0'

Screenshot status page: https://imgur.com/OUW0Hh7

/etc/init.d/vpn-policy-routing status:

vpn-policy-routing 0.0.2-28 running on Lede SNAPSHOT. WAN (IPv4): wan/dev/GATEWAY-IP.
============================================================
Dnsmasq version 2.80test3  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         WAN-GATEWAY-IP 0.0.0.0         UG    0      0        0 pppoe-wan
IPv4 Table 201: default via WAN-GATEWAY-IP dev pppoe-wan
IPv4 Table 201 Rules:
32741:  from all fwmark 0x10000 lookup 201
IPv4 Table 202: unreachable default
IPv4 Table 202 Rules:
32740:  from all fwmark 0x20000 lookup 202
IPv4 Table 203: default via VPN-GATEWAY-IP dev tun0
IPv4 Table 203 Rules:
32739:  from all fwmark 0x30000 lookup 203
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 192.168.1.141/32 -m comment --comment VPN_TEST -c 105 8820 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -s 192.168.1.230/32 -m comment --comment WAN_TEST -c 117 22133 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.1.0/24 -d 192.168.254.254/32 -m comment --comment MODEM_ACCESS -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set vpn0 dst -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -m set --match-set modem 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
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create wan6 hash:net family inet6 hashsize 1024 maxelem 65536 comment
create vpn0 hash:net family inet hashsize 1024 maxelem 65536 comment
create modem6 hash:net family inet6 hashsize 1024 maxelem 65536 comment
create modem hash:net family inet hashsize 1024 maxelem 65536 comment
create vpn06 hash:net family inet6 hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]

/etc/init.d/vpn-policy-routing reload:

Creating table 'wan/GATEWAY-IP [✓]
Creating table 'modem/0.0.0.0' [✓]
Creating table 'vpn0/GATEWAY-IP' [✓]
Routing 'MODEM_ACCESS' via modem [✓]
Routing 'WAN_TEST' via wan [✓]
Routing 'VPN_TEST' via vpn0 [✓]
vpn-policy-routing 0.0.2-28 started on (strict mode): wan/GATEWAY-IP modem/0.0.0.0 vpn0/GATEWAY-IP [✓]
vpn-policy-routing 0.0.2-28 monitoring interfaces: wan modem vpn0 [✓]

VPR config:

config vpn-policy-routing 'config'
	option verbosity '2'
	list supported_interface 'modem'
	option dnsmasq_enabled '1'
	option enabled '1'
	option strict_enforcement '1'
	option ipv6_enabled '0'

config policy
	option name 'MODEM_ACCESS'
	option local_addresses '192.168.1.1/24'
	option interface 'modem'
	option remote_addresses '192.168.254.254'

config policy
	option interface 'wan'
	option local_addresses '192.168.1.230'
	option name 'WAN_TEST'

config policy
	option local_addresses '192.168.1.141'
	option interface 'vpn0'
	option name 'VPN_TEST'

Let me know if I forgot any critical information. Thanks for your time.

For single devices to be routed it currently requires to assign them a static ip. With mac source based routing those devices could be assigned a dynamic ip instead.

Not sure but thus far my understanding of iptables is such would be feasible with something like

iptables -t nat -A PREROUTING -m mac --mac-source

Also not certain whether additional kernel modules would be needed, e.g. iptables-mod-dhcpmac & kmod-ipt-dhcpmac

Whilst reading on https://www.kernel.org/doc/Documentation/networking/vrf.txt

The design also allows the use of higher priority ip rules (Policy Based Routing, PBR)

it occurred to me that it could potentially make sense for VPR to use and thus be liberated of any nf/ipt/nft/ipset bloating/complications? Even running a VPN server/client in a lxc container routing via/to/from via such container #28 sounds feasible? And not to mention being liberated from uci with its curious naming convention for network bridges , #42 (comment)

Hello,

first thanks for your great vpn policy package...

As i´m using it on my main router and i build my images always with my needed packages i´ve included your custom repo in my feeds.conf.default

But i have to change on every luci package the include from:
include ../../luci.mk
to include
include $(TOPDIR)/feeds/luci/luci.mk

Why are this not the default?
Do you build the packages inside of luci feed dir?

Placing the VPN client inside an unpriviliged lxc container the VPN interface is not available at the router host. Whilst the lxc container being paired with a bridge (interface) at the (router) host the bridge interface could hold other containers than just the one for the VPN service.

Thus routing VPN traffic via an unpriviliged lxc container would require an option to route via a designated ip rather than interface.

@stangri

TOS 3.11.1 | vpn-policy-routing 0.0.2-33 | luci git-18.328.59464-9636605-1

{"kernel":"4.4.167-4a7a81f8db0ad743e54c68e1845c60b6-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}

started to happen after upgrade to 0.0.2-33

ERROR: policy 'router-hpot' has an unknown interface: iced!

source /lib/functions.sh
packageName="vpn-policy-routing"
config_load "$packageName"
config_get supportedIfaces          'config' 'supported_interface'
echo "$supportedIfaces"
process_interface(){ echo "$1"; }
config_load 'network'; config_foreach process_interface 'interface' 'create';

produces

loopback
lan
wan
wan6
wg0
guest
iced

default via xx46.104.107 dev pppoe-wan proto static
10.168.112.0/24 dev br-guest proto kernel scope link src 10.168.112.12
xx.46.104.107 dev pppoe-wan proto kernel scope link src xx.46.10.175
172.20.112.0/24 dev br-iced proto kernel scope link src 172.20.112.12
179.43.174.98 via 84.46.104.107 dev pppoe-wan proto static
192.168.112.0/24 dev br-lan proto kernel scope link src 192.168.112.12

br-iced Link encap:Ethernet HWaddr D8:58:D7:00:87:4B
inet addr:172.20.112.12 Bcast:172.20.112.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1

config policy
	option name 'router-iced'
	option remote_addresses '172.20.112.12/24'
	option interface 'iced'

• TOS 3.11
  {"kernel":"4.4.165-4a7a81f8db0ad743e54c68e1845c60b6-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}}
• VPR 0.0.2-31 / 0.0.2-32
• WG 0.0.20181119

enabling kernel reverse-path filter via sysctl

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

ceases the VPR routed traffic on the WG iface. Instead packages showing up as Martians.

vpn-policy-routing | 0.0.2-20

TOS 3.10.3 ({"kernel":"4.4.138-1e8e1b4c23f383e990eb3c4f490f5f2e-1","hostname":"router","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","release":{"distribution":"OpenWrt","version":"Chaos Calmer","revision":"r47055","codename":"omnia","target":"mvebu/generic","description":"OpenWrt omnia 15.05"}})

excecuting from cli

• uci set vpn-policy-routing.config.enabled='1'; uci commit;
• uci set vpn-policy-routing.config.enabled='0'; uci commit;

produces

uci: Parse error (invalid command) at line 12, byte 0

I have the follwing Error since i update vpn-poliy-routing:
user.notice vpn-policy-routing [1789]: ERROR: service failed to load kernel modules!

I have Chaos Calmer 15.05.1 r49389

How can i rollback to an earlier Version?