Domain-based VPN Routing Script

[Viktor Jaep]

You know, you were actually onto something, I think a 2nd policy with the other interface will work. It will just have lower priority than the higher interface in the IP Rules but if the main one is down then it will work.

It would sound like to me like you would need five different configuration files (based on his screenshot), one for each interface. That's why it might be just simpler to just dynamically edit the configuration file based on which VPN slot is chosen?

 

[js28194]

Here's a little Proof-of-concept... but you get the idea. This needs to be placed in your "/jffs/scripts/openvpn-event" file... You would need to edit the path to your .conf file so that it's correct... but then "theoretically", each time your VPN slot changes and the route comes up, it will modify your "domain_vpn_routing.conf" file to reflect the correct ovpnc#. Not quite sure if the vpn routing script needs a kickstart after this... but hopefully this gets you a little closer.

#!/bin/sh

confpath="/jffs/scripts/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

#PoC
#vpn_id=2
#sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath"

I can confirm this to work correctly. Fully tested and I for one love it!!!!

Made a backup of my /jffs/scripts/openvpn-event file.

Before modification:

#!/bin/sh

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

After modification:

#!/bin/sh
#!/bin/sh

confpath="/jffs/configs/domain_vpn_routing/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

#PoC
#vpn_id=2
#sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath"

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

In VPN director, I clicked on the button to stop OVPN1, then clicked on OVPN4 to start, observed the /jffs/configs/domain_vpn_routing/domain_vpn_routing.conf and it indeed change the interface name to ovpn4. Sweet!!! The logs reflect accordingly and a tracert just for giggles looks great!

Thanks a ton!

 

[Viktor Jaep]

Thanks a ton!

You're welcome... it's what we like to do around here. Nice job getting this working!

 

[Viktor Jaep]

I can confirm this to work correctly. Fully tested and I for one love it!!!!

After modification:

Here's a cleaned up version to get rid of the other stuff:

#!/bin/sh

confpath="/jffs/configs/domain_vpn_routing/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

 

[js28194]

Perfect. Thank you once again.

 

[ComputerSteve]

Here's a cleaned up version to get rid of the other stuff:

#!/bin/sh

confpath="/jffs/configs/domain_vpn_routing/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

Maybe this can be integrated into the script? @Ranger802004

 

[Viktor Jaep]

Maybe this can be integrated into the script? @Ranger802004

Just FYI... I believe this would also help make it work with VPNMON-R2 in this case... as VPNMON resets/randomizes to a different VPN client slot, this script will keep all your routing rules intact!

 

[ComputerSteve]

Just FYI... I believe this would also help make it work with VPNMON-R2 in this case... as VPNMON resets/randomizes to a different VPN client slot, this script will keep all your routing rules intact!

Exactly this could then become a very good replacement for x3mrouting.

 

[js28194]

I got lost in X3mrouting documentation... too many if then this that and notes to remember. I am sure it has a use case, but this solution is just way simplier and elegant. Solves all my requirements as you can see from my screen shot previously. I only have one server exposed to internet and it truley is not really exposed as it sits behind reverse caddy ssl proxy.

 

[Ranger802004]

I got lost in X3mrouting documentation... too many if then this that and notes to remember. I am sure it has a use case, but this solution is just way simplier and elegant. Solves all my requirements as you can see from my screen shot previously. I only have one server exposed to internet and it truley is not really exposed as it sits behind reverse caddy ssl proxy.

Thank you for the feedback!

 

[ComputerSteve]

I got lost in X3mrouting documentation... too many if then this that and notes to remember. I am sure it has a use case, but this solution is just way simplier and elegant. Solves all my requirements as you can see from my screen shot previously. I only have one server exposed to internet and it truley is not really exposed as it sits behind reverse caddy ssl proxy.

x3mrouting is a great script i'm just worried it will eventually stop working and this can hopefully be a replacement for some of the loss functionality.

 

[Olivier L]

Is there an equivalent of this script for wireguard ?

 

[js28194]

Is there an equivalent of this script for wireguard ?

I don't see why this script would not work. You should try it. When you create a policy, it reads the current interfaces so for your instead of showing ovpncXX it would most likely show wgcXXX. At least that is what I think will happen, do not have WG to test.

 

[Ranger802004]

Is there an equivalent of this script for wireguard ?

I am working to add wireguard soon

 

[Olivier L]

That would be great

 

[Ranger802004]

That would be great

Stay tuned soon

 

[Ranger802004]

***RELEASE*** v2.0.0-beta3
Enhancements:
- SSH UI
- Interfaces will now list the friendly name of the interface instead of the tunnel / physical interface name.
- Querying policies will take low CPU priority automatically.
- Cron Jobs will now be added to wan-event.
- NVRAM Checks have been integrated to prevent lock ups.
- Domain VPN Routing will now be called from wan-event in addition to openvpn-event.
- Global Configuration Menu.
- Developer Mode available for testing beta releases.
- Enhanced update function.
- If the IPV6 Service is disabled, IPV6 IP Addresses will not be queried or added to policies. In addition, existing IPv6 IP Addresses in policy files will be removed for optimization.
- Added WireGuard VPN Clients for support
- Changed dark blue text prompts to light cyan for easier reading.

Fixes:
- Visual errors when domain fails to perform DNS lookup.
- Fixed bug introducted in earlier beta for deleting old routes when WAN interface was selected.

 

[ComputerSteve]

***RELEASE*** v2.0.0-beta3
Enhancements:
- SSH UI
- Interfaces will now list the friendly name of the interface instead of the tunnel / physical interface name.
- Querying policies will take low CPU priority automatically.
- Cron Jobs will now be added to wan-event.
- NVRAM Checks have been integrated to prevent lock ups.
- Domain VPN Routing will now be called from wan-event in addition to openvpn-event.
- Global Configuration Menu.
- Developer Mode available for testing beta releases.
- Enhanced update function.
- If the IPV6 Service is disabled, IPV6 IP Addresses will not be queried or added to policies. In addition, existing IPv6 IP Addresses in policy files will be removed for optimization.
- Added WireGuard VPN Clients for support
- Changed dark blue text prompts to light cyan for easier reading.

Fixes:
- Visual errors when domain fails to perform DNS lookup.
- Fixed bug introducted in earlier beta for deleting old routes when WAN interface was selected.

Do you think you can incorporate the fix for in the VPN client is changed @Viktor Jaep: gave this this that needs to be placed in your "/jffs/scripts/openvpn-event" file:

#!/bin/sh

confpath="/jffs/configs/domain_vpn_routing/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

 

[Ranger802004]

Do you think you can incorporate the fix for in the VPN client is changed @Viktor Jaep: gave this this that needs to be placed in your "/jffs/scripts/openvpn-event" file:

#!/bin/sh

confpath="/jffs/configs/domain_vpn_routing/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

That is more of a function for VPNMON then it would be this script, I am in talks with @Viktor Jaep about this.

 

[ComputerSteve]

That is more of a function for VPNMON then it would be this script, I am in talks with @Viktor Jaep about this.

I would say yes if it was only specific to VPNMON. However, I don't think your script is updating the routing tables if you just toggle the client through the regular web interface. Meaning without VPNMON installed.