Nevermind, found the answer in your earlier post.
BTW I updated to DavidC502's latest build R13059 (26 Apr 20) for the WRT3200ACM
OpenWrt SNAPSHOT r13059-9fac9168c6 / LuCI Master git-20.116.42735-f44ba48
and had the same original "invalid argument" errors.
Installed "ip-full" again and errors are gone.
Just wanted to put it out there in case someone else is having the same issue.
1 Like
Thanks for bringing it up again, I'll seek advice on both ip-full issue and interface trigger from core OpenWrt team.
If you're on snapshots and experiencing issues with VPR not reloading after WG interface(s) come up on boot, could you please try adding some debug output (either logger or just echo) on this line of init-file: https://github.com/openwrt/packages/blob/master/net/vpn-policy-routing/files/vpn-policy-routing.init#L879
Just change the line for n in $ifSupported; do procd_add_reload_interface_trigger "$n"; procd_add_interface_trigger "interface.*" "$n" /etc/init.d/${packageName} reload; done; to the following three lines:
logger -t "${packageName}" "monitoring: $ifSupported"
# for n in $ifSupported; do procd_add_reload_interface_trigger "$n"; procd_add_interface_trigger "interface.*" "$n" /etc/init.d/${packageName} reload; done;
for n in $ifSupported; do procd_add_reload_interface_trigger "$n"; procd_add_interface_trigger "interface.*" "$n"; logger -t "${packageName}" "procd_reload_trigger"; done;
And then check/post the system log after you reboot the system.
PS. Please remove the hotplug.d script from your system first before testing it.
I'm having an issue whereby approximately every 45 minutes traffic routed to my WAN (not default route) stops working. Cannot ping anything. If I restart the firewall or VPR everything starts working again. Everything set on the default route (wireguard) works fine regardless of the state of the WAN routed clients.
I have a fairly straightforward setup, just using VPR to route a few devices through my WAN while my default gateway is Wireguard. Default firewall, no IPv6, system log does not report anything changing when the connection drops. Before the route drops, VPR routing works exactly as expected with no errors on startup, etc.
My hunch is that the alternative routing tables are destroyed when the wireguard (default route) keepalive fails and for whatever reason they are not rebuilt.
I saw the hotplug script @stangri mentioned above and will try it out. The only bummer is that I'm running OpenWRT 19.07.2 (ath79 target) so this problem doesn't appear limited to the recent snapshots.
If you need more info, let me know.
Edit: Sorry @stangri, I just saw your latest post. I will try to get some debugging output for you as it appears that my issue is similar to the other reports.
This is service startup with your debug code. WAN died about 7 minutes later with nothing in the logs.
Sat May 2 23:50:30 2020 user.notice vpn-policy-routing [1522]: Creating table 'wan/eth0.2/70.127.0.1' [✓]
Sat May 2 23:50:32 2020 user.notice vpn-policy-routing [1522]: Creating table 'wg0//0.0.0.0' [✓]
Sat May 2 23:50:32 2020 user.notice vpn-policy-routing [1522]: Routing 'jenna-laptop' via wan [✓]
Sat May 2 23:50:33 2020 user.notice vpn-policy-routing [1522]: Routing 'jenna-phone' via wan [✓]
Sat May 2 23:50:33 2020 user.notice vpn-policy-routing [1522]: Routing 'tv' via wan [✓]
Sat May 2 23:50:33 2020 user.notice vpn-policy-routing [1522]: Routing 'webserver' via wan [✓]
Sat May 2 23:50:34 2020 user.notice vpn-policy-routing [1522]: Routing 'modem' via wan [✓]
Sat May 2 23:50:35 2020 user.notice vpn-policy-routing [1522]: Routing 'ssh' via wan [✓]
Sat May 2 23:50:39 2020 user.notice vpn-policy-routing [1522]: [✓]
Sat May 2 23:50:39 2020 user.notice vpn-policy-routing [1522]: service started with gateways: wan/eth0.2/70.127.0.1 wg0//0.0.0.0
Sat May 2 23:50:39 2020 user.notice vpn-policy-routing: monitoring: wan wg0
And after service restart:
Sun May 3 00:00:23 2020 daemon.err modprobe: xt_set is already loaded
Sun May 3 00:00:23 2020 daemon.err modprobe: ip_set is already loaded
Sun May 3 00:00:23 2020 daemon.err modprobe: ip_set_hash_ip is already loaded
Sun May 3 00:00:24 2020 user.notice vpn-policy-routing [3640]: Creating table 'wan/eth0.2/70.127.0.1' [✓]
Sun May 3 00:00:24 2020 user.notice vpn-policy-routing [3640]: Creating table 'wg0/10.29.2.27' [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: Routing 'jenna-laptop' via wan [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: Routing 'jenna-phone' via wan [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: Routing 'tv' via wan [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: Routing 'webserver' via wan [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: Routing 'modem' via wan [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: Routing 'ssh' via wan [✓]
Sun May 3 00:00:25 2020 user.notice vpn-policy-routing [3640]: service started with gateways: wan/eth0.2/70.127.0.1 wg0/10.29.2.27 [✓]
Sun May 3 00:00:26 2020 user.notice vpn-policy-routing: monitoring: wan wg0
I am going to give the hotplug script a go tomorrow since I removed it to do this testing.
Edit: Just noticed a bug in the debug that wasn't logging correctly (; logger).
Here is the new output:
Sun May 3 12:02:12 2020 user.notice vpn-policy-routing [4660]: Creating table 'wan/eth0.2/70.127.0.1' [✓]
Sun May 3 12:02:12 2020 user.notice vpn-policy-routing [4660]: Creating table 'wg0/10.29.2.27' [✓]
Sun May 3 12:02:12 2020 user.notice vpn-policy-routing [4660]: Routing 'jenna-laptop' via wan [✓]
Sun May 3 12:02:13 2020 user.notice vpn-policy-routing [4660]: Routing 'jenna-phone' via wan [✓]
Sun May 3 12:02:13 2020 user.notice vpn-policy-routing [4660]: Routing 'tv' via wan [✓]
Sun May 3 12:02:13 2020 user.notice vpn-policy-routing [4660]: Routing 'webserver' via wan [✓]
Sun May 3 12:02:13 2020 user.notice vpn-policy-routing [4660]: Routing 'modem' via wan [✓]
Sun May 3 12:02:13 2020 user.notice vpn-policy-routing [4660]: Routing 'ssh' via wan [✓]
Sun May 3 12:02:13 2020 user.notice vpn-policy-routing [4660]: service started with gateways: wan/eth0.2/70.127.0.1 wg0/10.29.2.27 [✓]
Sun May 3 12:02:14 2020 user.notice vpn-policy-routing: monitoring: wan wg0
Sun May 3 12:02:14 2020 user.notice vpn-policy-routing: procd_reload_trigger
Sun May 3 12:02:14 2020 user.notice vpn-policy-routing: procd_reload_trigger
1 Like
Thanks for testing, looks like I'm not getting anything from procd_add_reload_interface_trigger.
Unfortunately the iface hotplug script did not seem to help. I'm trying the firewall hotplug script now in case this problem is triggered by miniupnpd adding rules.
Edit: Firewall hotplug script didn't help either. My next attempt at a workaround is to start lowering my wireguard keepalive to hopefully prevent the interface from dropping.
Edit 2: Just an observation, isn't there a lot of redundancy? Might be causing a lock?
procd.sh:
_procd_add_reload_interface_trigger() {
local script=$(readlink "$initscript")
local name=$(basename ${script:-$initscript})
_procd_open_trigger
_procd_add_interface_trigger "interface.*" $1 /etc/init.d/$name reload
_procd_close_trigger
}
vpn-policy-routing.init:
procd_open_trigger
for n in $ifSupported; do procd_add_reload_interface_trigger "$n"; procd_add_interface_trigger "interface.*" "$n" /etc/init.d/${packageName} reload; done;
procd_close_trigger
Seems like procd_open_trigger, procd_close_trigger, and procd_add_interface_trigger are already handled by procd_add_reload_interface_trigger.
I will test out:
for n in $ifSupported; do procd_add_reload_interface_trigger "$n"; logger -t "${packageName}" "procd_reload_trigger"; done;
Edit 3: No, that did not work either.
Hoping I am putting this in the right place. I want to route all internet bound LAN traffic to WAN directly by default (not VPN Tunnel). Then I want to create specific policies of when traffic is to be routed through the OPEN VPN Tunnel. This will be mostly based on destination and maybe a couple of ports. So far the only way I have gotten close is by
- Disable The ipset option for remote policies
- The ipset option for local policies
- Create rules for which traffic goes to VPN (based on Domain) in the top of the list and Create rules for a couple of specific machines to where traffic should go to WAN directly.
Initial tests have been positive.
However, I believe that by disabling the IPset options, the subdomains are no longer covered. Not sure where I read that. Is this correct? If so, is there another way to do this?
Also, is there a way to created that default to WAN policy for each and every single device that connects, without having to entel 150 lines?
May I ask you something unrelated? How did you get your traffic to go to WAN by default? I want to do the same thing. I want to direct all internet traffic to WAN by default in stead of the OpenVPN client. Then I will create a coupe of rules for which traffic should go through the OpenVPN client. How did you get your traffic to go to WAN by default?
Check the README for answers to both questions.
I have been doing that for days... I guess I am not so fast sorry... I am completely new to this...
Thanks!
Can you try:
for n in $ifSupported; do procd_add_interface_trigger "interface.*" "$n" /etc/init.d/${packageName} reload; done;
without the hotplug.d script then?
I guess that (For OpenVPN 2.4 and newer client config:
list pull_filter 'ignore "redirect-gateway"') takes care of the default routing. Might I ask where to add this? Do I just add this to /etc/config/vpn-policy-routing?
Or do I add it to /etc/config/network or to /etc/config/openvpn for example?
Or do I just run it on the command line?
Did not work, WAN route is still periodically dropping.
So no reloads of VPR after WAN comes back up?
No, it doesn't appear VPR is doing anything before, during, or after wan route stops working.
I think that in the interim I am just going to change my default route to WAN and let VPR move wireguard traffic with strict enforcement instead. That's good enough for me until I can test this more thoroughly next week and maybe dive into procd.
Edit: Unfortunately this doesn't seem to be working either. WAN routes still drop even when it is the default route. Wireguard route is fine.
Hi Stan, first post so first of all thanks for your work on this plugin!
I have a setup where two wireless intefaces (wlan0-1 and wlan1) are bridged to br-lan, and I have a wireguard client interface.
What I want is that clients connected to wlan0-1 should go out through the wireguard VPN and clients connected to wlan1 use the normal default route.
I can't use any IP mask or whatever, just the input device.
If I add a rule with wlan0-1 as source the resulting iptables rule sets "-s wlan0-1" and fails.
I tried adding a rule to VPR_PREROUTING manually with -i wlan0-1 but it does not intercept any packet because of the bridge.
The only way I found to make it work is to load physdev iptables filtes, set net.bridge.bridge-nf-call-iptables=1 and enable an iptables VPR_PREROUTING rule with physdev-in wlan0-1.
Is there a simpler way to do it that can be done automatically by the plugin, or am I wrong somewhere?
I've tried to implement the physical device routing, but faced the same problem you did with -i.
Which iptables rule made it work actually? I can implement it in VPR. And until I do, you can use a custom user script to insert that rule.