What's new

Merlin 386.3: VPN director rule disappears on reboot

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

eponymous

New Around Here
Since upgrading to 386.3, I have been having a strange issue with VPN Director. I'm probably not understanding something correctly, so hopefully someone can clear this up.

I am running my OpenVPN client with the setting:

Redirect Internet traffic through tunnel: VPN Director mode + killswitch rather than Yes (all). T

Incidentally, the Redirect Internet traffic through tunnel: Yes (all) results in my x3mRouting configuration (to bypass the tunnel for specific domains) not work anymore, in case this is useful to anyone. If I try to visit the bypassed domains with Yes (all) turned on, the browser just hangs forever. Using VPN Director with policy rules does allow x3mRouting settings to work as before, while still directing the remaining traffic through the tunnel.

However, the issue I am having is that the policy rule I add to VPN Director (to route all traffic through the tunnel) disappears after each router reboot.

My rules just before reboot:

Screen Shot 2021-08-09 at 7.40.17 PM.png


My rules just after reboot:

Screen Shot 2021-08-09 at 7.43.46 PM.png


This is not just cosmetic, indeed the traffic no longer passes through the tunnel until I add the rule back in using the console. Once I do, all traffic goes through the tunnel once more.

I was using policy rules in earlier versions of the firmware with just these rules, so the configuration does work as-is. The rules did not disappear at each reboot in the past.

You can see there is a rule that does not disappear - which passes traffic from my VPN Server 1 to the VPN Client 1. This never disappears, and was also configured using x3mRouting.

While poking around in the file system, I checked the file /jffs/openvpn/vpndirector_rulelist and I see the rule is present after adding it manually via the console, so something is being written to the jffs file system:

<1>VPN Server 1>10.8.0.0/24>>OVPN1<1>Route traffic through tunnel>192.168.50.0/24>>OVPN1

Thanks for any suggestions you can offer. I wonder if there is some weird interaction with x3mRouting going on, and perhaps I should delete/uninstall it and reinstall to fix this issue.
 
Since upgrading to 386.3, I have been having a strange issue with VPN Director. I'm probably not understanding something correctly, so hopefully someone can clear this up.

I am running my OpenVPN client with the setting:

Redirect Internet traffic through tunnel: VPN Director mode + killswitch rather than Yes (all). T

Incidentally, the Redirect Internet traffic through tunnel: Yes (all) results in my x3mRouting configuration (to bypass the tunnel for specific domains) not work anymore, in case this is useful to anyone. If I try to visit the bypassed domains with Yes (all) turned on, the browser just hangs forever. Using VPN Director with policy rules does allow x3mRouting settings to work as before, while still directing the remaining traffic through the tunnel.

However, the issue I am having is that the policy rule I add to VPN Director (to route all traffic through the tunnel) disappears after each router reboot.

My rules just before reboot:

View attachment 35625

My rules just after reboot:

View attachment 35626

This is not just cosmetic, indeed the traffic no longer passes through the tunnel until I add the rule back in using the console. Once I do, all traffic goes through the tunnel once more.

I was using policy rules in earlier versions of the firmware with just these rules, so the configuration does work as-is. The rules did not disappear at each reboot in the past.

You can see there is a rule that does not disappear - which passes traffic from my VPN Server 1 to the VPN Client 1. This never disappears, and was also configured using x3mRouting.

While poking around in the file system, I checked the file /jffs/openvpn/vpndirector_rulelist and I see the rule is present after adding it manually via the console, so something is being written to the jffs file system:

<1>VPN Server 1>10.8.0.0/24>>OVPN1<1>Route traffic through tunnel>192.168.50.0/24>>OVPN1

Thanks for any suggestions you can offer. I wonder if there is some weird interaction with x3mRouting going on, and perhaps I should delete/uninstall it and reinstall to fix this issue.

I’d been using option 3, the OpenVPN Event & x3mRouting Script, to route an OpenVPN server through a client, but with 386.3 I experienced the same issue that all my VPN Director entries disappeared on reboot.

I’ve uninstalled x3mRouting and this no longer happens. I’ve also noted that I no longer need the option 3 script installed - simply routing the VPN server subnet through a client in VPN Director is enough.

An unexpected bonus is being able to route the IPSEC server (with IKEv2) via an OpenVPN client, which means I can use the lighter Strongswan app to connect from my Android phone (or the native VPN interface in iOS).
 
I’d been using option 3, the OpenVPN Event & x3mRouting Script, to route an OpenVPN server through a client, but with 386.3 I experienced the same issue that all my VPN Director entries disappeared on reboot.

I’ve uninstalled x3mRouting and this no longer happens. I’ve also noted that I no longer need the option 3 script installed - simply routing the VPN server subnet through a client in VPN Director is enough.

An unexpected bonus is being able to route the IPSEC server (with IKEv2) via an OpenVPN client, which means I can use the lighter Strongswan app to connect from my Android phone (or the native VPN interface in iOS).
VPN Client GUI page display properly after uninstall x3mRouting. The one thing I miss with x3mRouting is the ability to create ipset rule. I route everything to VPN and leak ipset to WAN so that these program can work without geoblocking issue. Now these are broken.
 
VPN Client GUI page display properly after uninstall x3mRouting. The one thing I miss with x3mRouting is the ability to create ipset rule. I route everything to VPN and leak ipset to WAN so that these program can work without geoblocking issue. Now these are broken.

As a followup to this - I uninstalled x3mRouting, rebooted a few times, and then added the policy rule (routing all traffic through VPN) to VPN Director. Now the rule stays after each reboot. So this is consistent with what Spud reported above.

I also use x3mRouting to bypass the VPN using ipset rules (similar to what chongnt said above), so I wanted to see if I could get it to work with x3mRouting. I reinstalled x3mRouting option 3 and confirmed it was working to bypass the VPN for specific domains. After a reboot, both seem to be working - the VPN Director rule (routing all traffic through VPN) stays in place and x3mRouting config (bypassing VPN for specific domains) is still working as well.

Perhaps the solution is that x3mRouting does not play nicely with VPN Director during migration from earlier firmware, but uninstalling x3mRouting, configuring VPN Director as needed, then reinstalling x3mRouting does the trick. At least, this seems to have worked for me. I'll update if this changes.

I'm now having another issue that I haven't figured out - the only remaining concern with 386.3. If I do a reboot from the console, the router doesn't boot up properly. I can't connect to my wifi networks. This happens reliably every time I reboot from the console. In contrast, if I reboot by power cycling the router, things seem to come up fine (albeit a bit slower than they did before). The system log appears to reset after each reboot, so I don't know what error is happening on reboot from the console.

Not sure if others are seeing this? Any suggestions on debugging a boot issue?
 
As a followup to this - I uninstalled x3mRouting, rebooted a few times, and then added the policy rule (routing all traffic through VPN) to VPN Director. Now the rule stays after each reboot. So this is consistent with what Spud reported above.

I also use x3mRouting to bypass the VPN using ipset rules (similar to what chongnt said above), so I wanted to see if I could get it to work with x3mRouting. I reinstalled x3mRouting option 3 and confirmed it was working to bypass the VPN for specific domains. After a reboot, both seem to be working - the VPN Director rule (routing all traffic through VPN) stays in place and x3mRouting config (bypassing VPN for specific domains) is still working as well.

Perhaps the solution is that x3mRouting does not play nicely with VPN Director during migration from earlier firmware, but uninstalling x3mRouting, configuring VPN Director as needed, then reinstalling x3mRouting does the trick. At least, this seems to have worked for me. I'll update if this changes.

I'm now having another issue that I haven't figured out - the only remaining concern with 386.3. If I do a reboot from the console, the router doesn't boot up properly. I can't connect to my wifi networks. This happens reliably every time I reboot from the console. In contrast, if I reboot by power cycling the router, things seem to come up fine (albeit a bit slower than they did before). The system log appears to reset after each reboot, so I don't know what error is happening on reboot from the console.

Not sure if others are seeing this? Any suggestions on debugging a boot issue?
I have done the same. Uninstall x3mRouting then reinstall with option 3. Everything is working fine now.
I don't have wifi issue with console reboot. I cannot recall whether scribe/uiscribe create a symlink for /tmp/syslog.log -> /opt/var/log/messages. The messages log stored in thumb drive won't be lost after reboot. This way you can look into the boot messages.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top