I’m not dev, but I’ll get this sorted out. When I was at train I was looking at this thread.
1 Like
Hi Stan. Thanks, that solved the reboot problem! Now I hope that we also get the automatic reload sorted out!
luci-app-vpn-policy-routing git-18.181.76096-1fd3…-24
vpn-policy-routing 0.0.2-6
Following appears not working
-
if a
tunconnection is lost and withoption strict_enforcement '1'set the clients designated to be routed trough thetunonly will be routed throughwanafter a short while (say in the range of 1 - 2 minutes). That is not expected. -
if a
tunconnection is lost and clients are routed through wan again (see 1) and thetunthen being restablished the clients designated for routing viatunremain on wan until/etc/init.d/vpn-policy-routing reload
Has someone from the TO developer team been in touch meantime?
This is a result of PROCD triggers not working on TO OS. Directly related to the question I’ve asked.
No.
1 Like
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.
1 Like
Well, thank you for the feedback, at least.
OK, thanks. I hope we get the issue sorted out.
is there any news on
? Or will this be dragged out till TOS 4 (end of year maybe)?
@Pepe 30 days since this post that somebody will reach out soon. @stangri heard anything from the devs?
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.
1 Like
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.
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.
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
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
Odd, I am not having any issues or kernel panics with wireguard and routing. ** replaced for my IP to be hidden
Creating table 'wan/**.**.22.1' [✓]
Creating table 'VPSCLOUD/192.168.88.2' [✓]
Routing 'DREAMLINK1' via VPSCLOUD [✓]
Routing 'DREAMLINK2' via VPSCLOUD [✓]
Routing 'HTTP' via VPSCLOUD [✓]
Routing 'HTTPS' via VPSCLOUD [✓]
Routing 'TELNET' via VPSCLOUD [✓]
Routing 'SSH' via VPSCLOUD [✓]
Routing 'IPTV1' via VPSCLOUD [✓]
Routing 'IPTV2' via VPSCLOUD [✓]
Routing 'IPTV3' via VPSCLOUD [✓]
Routing 'SSH2' via VPSCLOUD [✓]
Routing 'CL' via wan [✓]
vpn-policy-routing 0.0.2-28 started on wan/**.**.22.1 VPSCLOUD/192.168.88.2 [✓]
vpn-policy-routing 0.0.2-28 monitoring interfaces: wan VPSCLOUD [✓]
root@mom:/etc/config/policy#I would head over to the strangri forum he mentioned. He is pretty helpful (he helped me personally on a different router) when I had issues.
Indeed, and he is aware of the issue. But I am not sure whether he is still maintaining the code. The github repo does not indicate much activity lately and even his activity in the OpenWRT (formerly LEDE) forum seems to have ceased.
you named the wireguard interface VPSCLOUD, as in
config interface 'VPSCLOUD' ?
And all outbound tcp traffic (port 80 aka http / port 443 aka https), except CL is routed through the wireguard tunnel?
Is the remote VPN endpoint provided by a VPN service provider or your own controlled/setup server?
Hello, yes, my wireguard is called VPSCLOUD. Only name I could think of at the time LOL.
You are correct, ports 80/443/22/23 are through the Wireguard interface as is IPTV which uses certain ports. CL is a game, that also uses a certain port, but added just to make sure it goes out the wan, really isn’t needed as all traffic that is not specified goes out the wan interface.
I currently use a cloud VPS server (Ubuntu 18) for wireguard. I have used Mullivad services before, and it works with them as well. I use a VPS with Kamatera now, but did use Digital Ocean as the VPS server at one time, both you can destroy when needed, took me about 15-20 minutes to setup on a new server.
I made a .sh file on the router, that switches out the policy and routes everything through wan if I need it. Sometimes when I purchase things, some places do not like VPNs. I am unsure of your problem however and why you are getting a kernel panic. Are you able to bring the interface up at all, without the policy routing? I manually edit my policy file, I don’t use LuCI to edit the ports on the router for the policy routing. The only “issue” I see is the manual reloading of the policy routing, but have a cron that does that after boot (after 3 minutes) that does this for me.
Strange issue you have.
Here is my interface. If you need help I will try my best, but it is working here:
http://prntscr.com/l6wwwp (admin, hope it is ok to post a screenshot, please delete if not ok).
L
So do I
Yes, the wg iface is up and running, the VPS is accessible and all traffic from TO can be routed through it, with no issues and it is inexplicable to me why VPBR is causing the kernel panic but it does, as soon as activating any traffic rule for the wg iface. It is causing this
alert kernel[]: [ 4591.684808] Unable to handle kernel paging request at virtual address 312f736d
alert kernel[]: [ 4591.692084] pgd = ea5a4000
alert kernel[]: [ 4591.694796] [312f736d] *pgd=00000000
emerg kernel[]: [ 4591.698432] Internal error: Oops: 5 [#1] SMP ARM
General VPBR config
Summary
config vpn-policy-routing 'config'
option verbosity '2'
option ipv6_enabled '0'
option udp_proto_enabled '1'
option strict_enforcement '1'
list ignored_interface 'guest'
list ignored_interface 'tun'
option dnsmasq_enabled '0'
option ipset_enabled '1'
option enabled '0'