That's very good of you. Thanks, very much! I'll adapt it for my needs and see how it goes. Will report back.
So, haven't given the mwan3 config a whirl yet, but it does look like setting the boot timeout to 120s might have fixed things. I haven't had any occurrences of needing to reload VPR manually after rebooting the router. Early days yet, but it looks promising. I'll keep an eye on it and try the mwan3 option if I find the problem hasn't been eliminated. I also spotted this on the Turris forum which may be something to look at.
Since I have a ADSL based modem, I cant set it to 120s because it seems overkill for me and the reason behind this is that the dsl_control starts after VPR so if VPR takes 120s then the router will be in a booting state for 120+boot-time seconds and then it will try to establish the connection through ADSL. This is definitely not feasible for me or most of the people that are on ADSL/VDSL based modems.
Also I dont quite understand why setting the timeout to 120s would matter here. As @stangri pointed out, VPR should reload itself when the WAN/VPN interfaces gets (re)connected. But in reality it doesnt work as it should, so I think something is going on in the package itself. Maybe something related to specific targets? Is it possible that VPR doesnt get the ifup/ifdown notifications? Can we forcefully provide those notifications to VPR?
When WAN isn't settled before VPR starts, VPR doesn't set a trigger to monitor it. If VPR starts properly after WAN is settled, it does monitor supported interfaces.
This build: https://dev.melmac.net/openwrt-repo/vpn-policy-routing_0.0.4-5_all.ipk actually registers VPR to reload on any interface change. Let me know if it works out for you in conjunction with boot timeout set to 1-2 seconds.
1 Like
For me this build is the same as before. But I also suspect that netifd is not quite working properly for DSL based routers. I already submitted a bug about it but it will take sometime to get it resolved but anyway in my case when wan interface gets connected the associated LED doesn't light up although it should. I think this is because netifd has some problems in Snapshots.
This problem could be related to netifd and this could be why VPR doesnt get triggered on wan status change. If someone uses Snapshot and a DSL based router maybe they can confirm. I use a HomeHub 5A with 4.14.111 kernel. I flashed it today, was using 106 before. Anyway for now I am gonna stick with mwan3 to reload VPR for me. Thank you for the build.
Hi!
I'm using for DNS over TLS - UNBOUND, STUBBY, DNSMASQ.
I have some issues after VPR and my configuration, cos of STUBBY.
After installing the VPR, and reboot - Stubby stop working.
The system.log contains only 1 error from VPR - can't find wan interface for rule and A LOT of errors from Stubby, cos of problem with characters (is it possible what VPR package replace some Stubby dependencies?).
Can u check this combination?
Link for configuration
Router Asus RT-AC58U.
OpenWrt 18.06.2, r7676-cddd7b4c77
Best regards,
rainmaverick
Hey, @tectonic, thanks for the report. Can you try one more thing then please? Can you go to the older build (force-install it, otherwise opkg won't let you replace the newer build with the older one or just uninstall the dev version and install from repo again) and add wan and all the other relevant interfaces to the list of supported interfaces. Please let me know if that works too.
I'd rather not set up monitoring on all router interfaces.
I've never had any experience with stubby, nor unbound. I suggest you ask in the subby thread and/or create a new thread for your stubby errors.
I use dnsmasq with https_dns_proxy (and luci-app-https_dns_proxy) and this combination works fine with or without VPR.
Will do. Away from my network for a couple of days, but will let you know during the week
@rainmaverick I'm running multiple dnsmasq instances: one with Stubby, one with Unbound (one with neither) and haven't seen any problems in conjunction with VPR.
Happy to help by sharing my configs, but probably best to shift it from this thread, as @stangri suggested.
1 Like
I've been trying to figure out the following:
My router has two wireguard interfaces, first one is for my VPN provider and using vpn-policy-routing to assign certain hosts/subnets to it.
The second wireguard interface is used for my mobile devices to access my network at home.
This mostly works with one exception, a device connected to the second wireguard interface will not be able to talk to any host/subnet that has been set up to be policed by vpn-policy-routing.
Some packet dumps/traces shows that packets sent to the hosts policed by vpn-policy-routing will arrive there, but their replies is then sent out the interface configured in vpn-policy-routing, instead of returning to where it came from (the second wireguard interface).
I'm no expert at this, so maybe this is normal? But it would be nice if vpn-policy-routing could be set to not route targets in a local (rfc1918) over the outgoing wan/vpn interface? Perhaps I missed some other setting. Is there anything else I should try? I've been trying to edit the iptables rules to add '! -d 10.0.0.0/8' or similar but haven't so far managed to get things working.
Instead of doing this, try setting (under VPR advanced configuration settings) "Append local IP Tables rules" to "! -d 10.0.0.1/8
[EDIT] also, make sure your second wireguard interface (the one that lets you 'phone home') is in your lan firewall zone.
@stangri I'm still 'on the road', but my VPR config has always had list ignored_interface specified. Appreciate this is the opposite of that which you're asking me to check, but perhaps the effect is equivalent?
No luck unfortunately.
The second wireguard interface already shares the lan firewall zone, and modifying the iptables remote rule in vpn-policy-routing leads to: 'ERROR: iptables -t mangle -I VPR_PREROUTING 1 -j MARK --set-xmark 0x020000/0xff0000 -s 10.0.1.1/24 -d 0.0.0.0/0 ! -d 10.0.0.1/8 -m comment --comment VPN'
Something like 'iptables -t mangle -I VPR_PREROUTING 1 -j MARK --set-xmark 0x020000/0xff0000 -s 10.0.1.1/24 ! -d 10.0.0.1/8' would probably work, but would need editing the vpn-policy-routing service itself.
I must have missed something.. it seems there should be a better way.
I've got the same setup as you: one wireguard interface (in my wan zone) for my VPN provider; and one in my lan zone to allow me to 'phone home'. I'll share my configs with you via DM in the next couple of days once I'm back at home.
Appreciate that, thanks! I'll keep trying meanwhile..
You can use -m iprange to do the trick. It's included in OpenWrt opkg source (iptables-mod-iprange)
Hi guys,
I have a minor issue about when I reboot my router. I have everything working great, just when I reboot, I have to manually restart my Wireguard VPN interface for VPR to pick it up.
I notice that, after a reboot, in the VPR status output it is missing the default route via the VPN interface:
vpn-policy-routing 0.0.4-4 running on OpenWrt 18.06.1. WAN (IPv4): wan/dev/77.248.XX.X. WAN (IPv6): wan6/dev6/fe80::/64.
============================================================
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 dhcp-077-248-02 0.0.0.0 UG 0 0 0 eth1
IPv4 Table 201:
IPv4 Table 201 Rules:
32765: from all fwmark 0x10000 lookup 201
After I have restarted the wg interface, the default route is populated correctly:
============================================================
Routes/IP Rules
default dhcp-077-248-02 0.0.0.0 UG 0 0 0 eth1
IPv4 Table 201: default via 192.168.0.2 dev wg
IPv4 Table 201 Rules:
32765: from all fwmark 0x10000 lookup 201
============================================================
Here's my config:
config vpn-policy-routing 'config'
option boot_timeout '30'
option verbosity '2'
option ipv6_enabled '1'
option strict_enforcement '1'
option dnsmasq_enabled '1'
option enabled '1'
list supported_interface 'wg'
list supported_interface 'wg6'
list ignored_interface 'wan'
list ignored_interface 'wan6'
Any ideas?
Thanks,
Dan
Please share as much as possible publicly, so I could add it to the README potentially. I've been slowly building up the "recipes" section of it.
The goal is to force VPR to set the trigger for WAN interface monitoring, so yeah, it's a complete opposite of what you've had before.
1 Like