@stangri @dk4dk4 What would be cool is to have maybe a check box to add a "Monitored domain/ip" or even a "Dynamic IP" rule in VPR. So that perhaps every 5-10 minutes (or user specified value), a lookup against the domain is run and if the IP has changed since the rule was implemented it drops the old rule and adds the new rule. Not sure if there would be any firewall rule stacking issues with that though since I assume the rules are stacked top to bottom and any new rule would be appended to the bottom of the firewall list?
I'm trying to get my Plex server to be accessible via WAN. I have the port forwarded on the router, but I'm not sure what vpn policies I need to allow external WAN access to my Plex server. My router is at 192.168.1.1 and my Plex server is at 192.168.1.30. Port 32400 is forwarded at the router to the Plex server. My VPN provider is Mullvad connected via Wireguard.
I had a similar set-up a while ago, but my recollections are vague. Nevertheless, you'll need to ensure responses from your Plex server are sent back over the WAN rather than over the VPN; so you'll need a rule to enforce this. You could potentially restrict this to port 32400 so that all other traffic from that machine goes over the VPN. E.g.:
-s 192.168.1.30 -p tcp --sport 32400
I'd recommend starting by requiring all traffic from your Plex server to be sent over the WAN, and then try restricting by port once you've got it working.
Hey @stangri - just wanted to mention, the SSH option is now working 
tried it now with the 0.0.4 release and the output chain option worked finally. Great!
I can currently only split the openSSH client and not dropbear but.. well I'll figure that out. Thanks for your patience!
@stangri I am having some problems with VPR.
- It wont auto start with the boot process, even if I set the boot timeout to 30 or more. It just halts the boot for that amount of time and then exits and never starts again unless manually started. Can you create the service as a daemon so it keeps running in the background just like openvpn and mwan3? They do a better job of being a service and keep running in the background and do not halt the boot process while VPR stays in the foreground and halts the boot process.
- Now VPR is also not reloading after running for a few hours even when the VPN or WAN connection gets reloaded/reconnected and it doesn't change the IP in VPR and so the policies don't work. I manually needed to stop/start it. I even changed a policy but it didn't reload the vpn address even if I put the vpn interface in supported interfaces section.
Hopefully you can fix these issues. Thanks
A few clues might help you get some assistance. ie read the first post on supplying debug info.
You might also question why others haven't reported similar problems previously to this. ie what's different about your configuration/hardware/software to other users.
1 Like
Is there any way to set an exception to the routing policy table? My use case is that I want all traffic that goes outside to go via VPN, but I also have three vlan subnets in my home, and I would like to allow routing between them to take place (printer, etc). Thanks!
I also experience the second point, I sometimes have to restart the policies I set up. Haven't figured out what exactly needs to act as a trigger - if that can be pinpointed, that could be handled by the init-script.
1 Like
I am using mwan3 as a trigger to reload VPR for now. I basically deleted most of the config in mwan3 so it just detects whether an interface is up or down through ping and in the notification script I put a few lines of code to reload VPR whenever the vpn gets ifup notification. Seems to be going well for a few days now.
Edit: It also helps with my issue 1 because I dont really need to start VPR with boot it will get started automatically once mwan3 script reloads it.
Hi @ahmar16
Would you mind sharing your mwan3 config and notification script? I'm seeing similar behaviour: if I have to reboot my router, I also have to reload VPR manually.
Thanks!
Hi @tectonic, here is the mwan3 config /etc/config/mwan3:
cat /etc/config/mwan3
config globals 'globals'
option mmx_mask '0x3F00'
option rtmon_interval '5'
config interface 'wan'
option enabled '1'
option family 'ipv4'
option timeout '2'
option down '3'
option initial_state 'online'
list track_ip '8.8.4.4'
list track_ip '8.8.8.8'
option track_method 'ping'
option reliability '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option failure_interval '5'
option recovery_interval '5'
option up '3'
option flush_conntrack 'never'
option count '3'
option interval '10'
config rule 'https'
option sticky '1'
option dest_port '443'
option proto 'tcp'
option use_policy 'balanced'
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'balanced'
config interface 'vpn'
option enabled '1'
option initial_state 'offline'
option family 'ipv4'
list track_ip '8.8.8.8'
option track_method 'ping'
option reliability '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '2'
option failure_interval '5'
option recovery_interval '5'
option down '3'
option up '3'
option flush_conntrack 'never'
option count '3'
option interval '10'
As you can see I dont use mwan3 for any traffic shaping or for multi-wan purposes. It just runs to provide info about the connected interfaces and also keeps my VPN alive sort-of-thing.
Also you need to change the /etc/mwan3.user file (notification script) to suit your needs:
#!/bin/sh
#
# This file is interpreted as shell script.
# Put your custom mwan3 action here, they will
# be executed with each netifd hotplug interface event
# on interfaces for which mwan3 is enabled.
#
# There are three main environment variables that are passed to this script.
#
# $ACTION
# <ifup> Is called by netifd and mwan3track
# <ifdown> Is called by netifd and mwan3track
# <connected> Is only called by mwan3track if tracking was successful
# <disconnected> Is only called by mwan3track if tracking has failed
# $INTERFACE Name of the interface which went up or down (e.g. "wan" or "wwan")
# $DEVICE Physical device name which interface went up or down (e.g. "eth0" or "wwan0")
if [ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "vpn" ]
then
{
# reload VPR every time VPN interface gets connected
/etc/init.d/vpn-policy-routing reload
}
fi
if [ "$ACTION" = "disconnected" ] && [ "$INTERFACE" = "vpn" ]
then
{
# automatically restart OpenVPN if mwan3 thinks it is not connected or ping errors out
/etc/init.d/openvpn restart
}
fi
if [ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "wan" ]
then
{
# In SNAPSHOTS there is an issue with pppoe-wan LED not getting turned on so
/etc/init.d/led reload
}
fi
1 Like
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.