VPN policy based routing possible?


#38

If I type the commands, nothing happens, no output…

root@turris:~# grep ‘vpn’ /var/log/messages
root@turris:~# grep ‘vpn-policy-routing’ /var/log/messages


#39

I found this manually in the messages log:

2018-06-13 21:17:48 notice [2221]: Creating table ‘VPN_Client/tun0/0.0.0.0’ [✗]
2018-06-13 21:17:48 notice [2221]: Routing ‘Local_IP’ via VPN_Client [✓]
2018-06-13 21:17:48 notice [2221]: Routing ‘IP Range’ via wan [✓]
2018-06-13 21:17:48 notice [2221]: service started on wan/eth1/XXX.XXX.XX.X with errors [✗]
2018-06-13 21:17:48 err kresd[2025]: [priming] cannot resolve address ‘m.root-servers.net.’, type: 1
2018-06-13 21:17:48 notice [2221]: ERROR: Failed to set up ‘VPN_Client/tun0/0.0.0.0’
2018-06-13 21:17:48 notice [2221]: service monitoring interfaces: wan VPN_Client [✓]
2018-06-13 21:17:48 info smartd[3554]: smartd 6.5 2016-05-07 r4318 [armv7l-linux-4.4.134-8f7f4132dc88fb7034ce9648e5961be5-0] (localbuild)
2018-06-13 21:17:48 info smartd[3554]: Copyright © 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
2018-06-13 21:17:48 info smartd[3554]: Opened configuration file /etc/smartd.conf
2018-06-13 21:17:48 info smartd[3554]: Configuration file /etc/smartd.conf parsed.
2018-06-13 21:17:48 info smartd[3554]: Device: /dev/hdb, open() failed: No such device
2018-06-13 21:17:48 info smartd[3554]: Monitoring 0 ATA/SATA, 0 SCSI/SAS and 0 NVMe devices
2018-06-13 21:17:48 info smartd[3557]: smartd has fork()ed into background mode. New PID=3557.
2018-06-13 21:17:48 emerg turris[]: Router Turris successfully started.
2018-06-13 21:17:48 info procd[]: - init complete -
2018-06-13 21:17:50 notice netifd[]: Interface ‘VPN_Client’ is enabled
2018-06-13 21:17:50 notice netifd[]: Network device ‘tun0’ link is up
2018-06-13 21:17:50 notice netifd[]: Interface ‘VPN_Client’ has link connectivity
2018-06-13 21:17:50 notice netifd[]: Interface ‘VPN_Client’ is setting up now
2018-06-13 21:17:50 notice netifd[]: Interface ‘VPN_Client’ is now up

Does this help? (I XXX’ed the IP in the post)

Edit: When I then manually reload I get this (XXX’ed the IP’s again):

2018-06-13 21:32:58 notice [4143]: Creating table ‘wan/eth1/XXX.XXX.XX.X’ [✓]
2018-06-13 21:32:58 notice [4143]: Creating table ‘VPN_Client/tun0/XX.XX.X.XXX’ [✓]
2018-06-13 21:32:58 notice [4143]: Routing ‘Local_IP’ via VPN_Client [✓]
2018-06-13 21:32:58 notice [4143]: Routing ‘IP Range’ via wan [✓]
2018-06-13 21:32:58 notice [4143]: service started on wan/eth1/XXX.XXX.XX.X VPN_Client/tun0/XX.XX.X.XXX [✓]
2018-06-13 21:32:58 notice [4143]: service monitoring interfaces: wan VPN_Client [✓]

Is it the problem that he creates a table with 0.0.0.0 for tun0 at the beginning?


#40

Thanks for investigation. I’ve asked to grep certain things as I was hoping the name of the service would also be in the log, alas it was not.

Anyways, to solve the boot-up problem you can try running (once):
sed -i '$i \sleep 20 && /etc/init.d/vpn-policy-routing reload &' /etc/rc.local

That won’t fix automatic reload for when OpenVPN goes down and then back up tho.

Can you guys tag Turris devs in this thread?

I’m using PROCD on 17.x/18.x to be notified when some interfaces are up: https://github.com/stangri/openwrt_packages/blob/master/vpn-policy-routing/files/vpn-policy-routing.init#L550-L556

This doesn’t seem to work on Turris. Do I need to dynamically create hotplug scripts then?


#41

@Pepe

Hi Pepe, can you answer stan’s question? Would be great if we would get VPN PBR working on Turris!


#42

I’m not dev, but I’ll get this sorted out. When I was at train I was looking at this thread.


#43

Hi Stan. Thanks, that solved the reboot problem! Now I hope that we also get the automatic reload sorted out!


#44

@Pepe Hi Pepe, could you get Stans question sorted out with the devs?


#45

@stangri

luci-app-vpn-policy-routing git-18.181.76096-1fd3…-24
vpn-policy-routing 0.0.2-6

Following appears not working

  1. if a tun connection is lost and with option strict_enforcement '1' set the clients designated to be routed trough the tun only will be routed through wan after a short while (say in the range of 1 - 2 minutes). That is not expected.

  2. if a tun connection is lost and clients are routed through wan again (see 1) and the tun then being restablished the clients designated for routing via tun remain on wan until /etc/init.d/vpn-policy-routing reload

Has someone from the TO developer team been in touch meantime?


#46

This is a result of PROCD triggers not working on TO OS. Directly related to the question I’ve asked.

No.


#47

@Pepe

what happened to?


#48

Hello,
I’ve never forgotten about it. I’ve already passed it over two times, but sometimes it’s complicated because we’re solving also other issues and doing our best, what we can do.

We know about this issue and somebody will reach @stangri soon.


Listening to physical port connection/disconnection events
#49

Well, thank you for the feedback, at least.


#50

OK, thanks. I hope we get the issue sorted out.


#51

is there any news on

? Or will this be dragged out till TOS 4 (end of year maybe)?


#52

@Pepe 30 days since this post that somebody will reach out soon. @stangri heard anything from the devs?


#53

Hello guys,

Since turris project stated that it will base TOS 4 on a upstream, updated version of OPEN-WRT, wouldn’t this mean they can easily implement an easy to use, robust OpenVPN client in the frontend GUI?

I know there are workarounds for now, but I’m really amazed by the fact they did not implement this. What am I missing here? This should be one of the most fundemental and basic things in a router.


#54

This seems a bit off topic as the thread pertains to VPN policy based routing which is not just covering OpenVPN.

There are perhaps other threads in the forum covering OpenVPN client integration into Foris.


#55

For some reasons I’ve stopped receiving e-mail notifications on new posts from this forum.

If you have any questions, please head to the OpenWrt forum (follow the direct link in the README on github), just make sure to indicate you’re running VPR on a TOS device.

PS. No, nobody has reached out.
PPS. If anyone has a use case for the Tor-related policies or the policies affecting the local interface (for example you’ve created the guest network you want to route via specific tunnel), please let me know. While Tor code isn’t quite ready, I believe the interface-targeting policies code is ready, I need testers.


#56

It is not working since a while with wireguard as causing a kernel panic and subsequent reboot loop https://github.com/stangri/openwrt_packages/issues/24


#57

The above mentioned kernel panic is still present with TOS 3.10.8 / kmod-wireguard 4.4.161+0.0.20180918-…2-1 / kernel 4.4.161-0a333a8e606ab056173befac424900d2-1