Im new to openwrt and linux so im just wondering.
Ive been reading different things about whether to update packages or not.
Im running 19.07.3 stable x86_64 made with imagebuilder for 19.07.3
Can i just update vpn-policy-routing packages when there are updates?
Thanks
This was very helpful for me. Thanks!
Since I had ip-full installed, I had to uninstall it which gave it heartburn and failed the first time (but it uninstalled vpn-policy-routing). But after the second uninstall, I was able to reinstall vpn-policy-routing and ip-full and things began working again.
Thanks for the report. Could you please clarify:
I have the same errors today as well on 19.07.3 with the default opkg feed (i.e., no extra repos)
/etc/init.d/vpn-policy-routing reload
Creating table 'wan/eth0.2/24.98.178.1' ip: invalid argument 'ls' to 'ip'
ip: invalid argument '0x010000/0xff0000' to 'fwmark'
[✓]
Creating table 'wg0/10.200.200.2' ip: invalid argument 'ls' to 'ip'
ip: invalid argument '0x020000/0xff0000' to 'fwmark'
[✓]
[✓]
vpn-policy-routing 0.2.1-13 started with gateways:
wan/eth0.2/24.98.178.1 [✓]
wg0/10.200.200.2
vpn-policy-routing 0.2.1-13 monitoring interfaces: wan wg0 .
vpn-policy-routing is safe to update from the official repo. If you're installing from my repo, I've been known to accidentally push non-ready/test binaries there, so unless you know how to grab an older ipk from github should things break, you may want to stay away.
simple-adblock is strongly advisable to update as it now has config-update functionality to update the outdated URLs for block-lists.
@buckaroo @gadgetguy08 -- I believe it's safe to remove ls table main for OpenWrt, so I've pushed vpn-policy-routing 0.2.1-27 to my repo, please test it on your systems.
I may have to go back to using ip-full at some point tho.
UPDATE: nevermind the above, removed dependency on busybox'es ip implementation and added ip-full to dependencies in 0.2.1-27.
I was able to uninstall all the packages and reinstall them like the previous poster to fix the issue before you pushed the update. So I can't verify if the update would have fixed it. It doesn't break anything though, and things continue to work.
Edit: I just saw that the update on the main feed was only for luci-app-vpn-policy-routing. vpn-policy-routing is still 0.2.1-13.
Do i need to do something special to enable wifi clients when using amazon/netflix -> wan policies?
Hi, I'm new to OpenWrt and homenetworking in general am trying to route a few domains over a mullvad wireguard vpn.
The vpn interface is running fine. When I route all traffic over it, everything runs as expected. However when I try to route specific domains, I am having trouble.
To test, I'm trying to just route traffic to "whatismyipaddress.com" and "mullvad.net" through the vpn. "whatismyipaddress" shows the traffic is routed through the vpn, but "mullvad.net/en/check/" does not show it being routed correctly.
etc/config/vpn-policy-routing below:
config vpn-policy-routing 'config'
option verbosity '2'
option strict_enforcement '1'
option src_ipset '0'
option dest_ipset 'dnsmasq.ipset'
option ipv6_enabled '0'
list supported_interface ''
list ignored_interface 'vpnserver wgserver'
option boot_timeout '30'
option iptables_rule_option 'append'
option iprule_enabled '0'
option webui_enable_column '0'
option webui_protocol_column '0'
option webui_chain_column '0'
option webui_sorting '1'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
list webui_supported_protocol 'all'
option enabled '1'
config include
option path '/etc/vpn-policy-routing.netflix.user'
option enabled '0'
config include
option path '/etc/vpn-policy-routing.aws.user'
option enabled '0'
config policy
option name 'Mullvad'
option src_addr '0.0.0.0/0'
option interface 'WGINTERFACE'
option dest_addr 'mullvad.net whatismyipaddress.com'
remove this and reboot the device you've been testing from.
Alright I made the change and rebooted, but unfortunately have the same result. Do you have any other suggestions? Let me know if you need any additional information. Thanks
Updated /etc/config/vpn-policy-routing below:
config vpn-policy-routing 'config'
option verbosity '2'
option strict_enforcement '1'
option src_ipset '0'
option dest_ipset 'dnsmasq.ipset'
option ipv6_enabled '0'
list supported_interface ''
list ignored_interface 'vpnserver wgserver'
option boot_timeout '30'
option iptables_rule_option 'append'
option iprule_enabled '0'
option webui_enable_column '0'
option webui_protocol_column '0'
option webui_chain_column '0'
option webui_sorting '1'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
list webui_supported_protocol 'all'
option enabled '1'
config policy
option dest_addr 'mullvad.net whatismyipaddress.com'
option interface 'WGINTERFACE'
option name 'Mullvad'
So i just recently started using openwrt and have very little linux experience, i went from asuswrt merlin with x3mrouting for netflix/amazon policy based routing.
I set that up many months ago so i cant remember how.
Im now trying to setup netflix/amazon to go through wan, but im clearly missing something basic when it comes to using the vpn-policy-routing.aws.user and vpn-policy-routing.netflix.user
Im not sure they are even used, even though i enabled them, it might be some basic routing/firewall configurations that im missing, cause i set this up last week and mightve missed something.
etc/config/vpn-policy-routing
config include
option path '/etc/vpn-policy-routing.aws.user'
config include
option path '/etc/vpn-policy-routing.netflix.user'
config vpn-policy-routing 'config'
option verbosity '2'
option src_ipset '0'
option ipv6_enabled '0'
option boot_timeout '30'
option iptables_rule_option 'append'
option iprule_enabled '0'
option webui_sorting '1'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
list webui_supported_protocol 'all'
option enabled '1'
option webui_enable_column '1'
option webui_protocol_column '1'
option dest_ipset 'dnsmasq.ipset'
option strict_enforcement '1'
option webui_chain_column '0'
list supported_interface 'wg_1'
list supported_interface 'wg_2'
list supported_interface 'wan'
/etc/init.d/vpn-policy-routing reload
Creating table 'wan/eth0/xxx.xxx.xxx.xxx' [✓]
Creating table 'wg_1/xxx.xxx.xxx.xxx' [✓]
Creating table 'wg_2/xxx.xxx.xxx.xxx' [✓]
Routing 'pc1' via wg_1 [✓]
Routing 'pc2' via wan [✓]
Routing 'pc3' via wan [✓]
Running /etc/vpn-policy-routing.aws.user [✓]
Running /etc/vpn-policy-routing.netflix.user [✓]
This works
Routing 'pc1' via wg_1 [✓]
Routing 'pc2' via wan [✓]
Routing 'pc3' via wan [✓]
But it doesnt seem like the vpn-policy-routing.aws.user and vpn-policy-routing.netflix.user and actually used, how can i confirm?
Thank you
EDIT: Actually all the things ive tried when setting manual policy routing, like "Routing 'pc2' via wan [✓]" seems to work, i tried a few combinations
This is because the ip check is not operated from mullvad.net.
*.am.i.mullvad.net, *.dnsleak.am.i.mullvad.net are doing it.
I upgraded to 0.2.1-27 and the following errors appeared after upgrade
# /etc/init.d/vpn-policy-routing restart
Creating table 'wan/eth0.2/10.10.1.254' ip: invalid argument 'ls' to 'ip'
ip: invalid argument '0x010000/0xff0000' to 'fwmark'
[✗]
...
It seems the problem was with conflict with ip-tiny. So I removed ip-tiny (did it through web interface, but you could do on command):
opkg remove ip-tiny
But this removed also removed wireguard dependency:
Removing package luci-proto-wireguard from root...
Removing package wireguard-tools from root...
Removing package ip-tiny from root...
After the removal I was able to start vpn-policy-routing
# /etc/init.d/vpn-policy-routing restart
Creating table 'wan/eth0.2/10.10.1.254' [✓]
...
So I reinstalled luci-proto-wireguard, which also pulled wireguard-tools, but interestingly enough not ip-tiny!!! Excellent news!
# opkg install luci-proto-wireguard
Installing luci-proto-wireguard (git-20.240.77934-1d65a61-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07.2/packages/arm_cortex-a15_neon-vfpv4/luci/luci-proto-wireguard_git-20.240.77934-1d65a61-1_all.ipk
Installing wireguard-tools (1.0.20191226-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07.2/packages/arm_cortex-a15_neon-vfpv4/base/wireguard-tools_1.0.20191226-1_arm_cortex-a15_neon-vfpv4.ipk
Configuring wireguard-tools.
Configuring luci-proto-wireguard.
After this vpn-policy-routing restarted without problems.
# /etc/init.d/vpn-policy-routing restart
Creating table 'wan/eth0.2/10.10.1.254' [✓]
...
I thought I'd share as this must affect everyone who installed the upgrade and had wireguard installed prior to the upgrade.
I sort of understand, can u explain more?
I have got the below errors before when I upgrade or restart VBR and wanted just to inform @stangri incase it is really an error. It does not seem to affect my VBR setup as far as I can tell.
Below is from upgrade of -27 to -29 versions.
My point was that your config was correct, however you are expecting the mullvad.net ip check to display your mullvad ip but this will not happen since the relevant domains for them are ipv4.am.i.mullvad.net, ipv6.am.i.mullvad.net and am.i.mullvad.net for ips and *.dnsleak.am.i.mullvad.net for dns.
I have a strange minor issue.
On both Davidc502's last build r13342 and a Snapshot build from today r14365 I cannot get VPR to show enable in the "System - Startup" page of the GUI.
I tried on the Startup page to enable, on the VPR GUI page (enable/disable/start/stop) and via CLI with the "enable" command. None managed to get the VPR to show up as enabled in the GUI Startup page.
When I click "Disabled" it does go green to "Enabled" but if I go off the page and back it is back to "Disabled".
I have confirmed that VPR is up and running and all seems OK.
Is there a fix for this?
Probably ACLs are now being enforced for the apps depending on luci-compat. I forgot to add requirement for iptables and uci to the luci app ACL.
I've been experimenting with removing uci use from the controller, but I haven't achieved result I was hoping for.
I'm away until Tuesday, not sure if I'd be able to fix it before then.
