stangri / source.openwrt.melmac.net Goto Github PK
View Code? Open in Web Editor NEWOpenWrt Packages
License: GNU General Public License v3.0
OpenWrt Packages
License: GNU General Public License v3.0
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 [✓]
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.
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.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'
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.
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'
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
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'. [✓]
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
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?
Sending SIGTERM to the process works, but PROCD fails to kill it.
Tagging @anselal.
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.
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.
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.
Would be possible to add split DNS, say:
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'
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.
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?
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 [✓]
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?
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.
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
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.ipkCollected 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
{"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 inotifyERROR: 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.
@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).
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
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.
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?
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
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.
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 Makefile
s 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 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
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.
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.
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"}}
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
Service status remains static @ Service is disabled/stopped
despite running and subsequent the button constantly showing Enable/Start
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
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.
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.
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"}}
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.
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'
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)
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
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
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"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.