subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+3 votes
590 views 1 comments
by anonymous

Following my recent failures to get my RUT955 to connect as a client in an L2TP/IPSec site to site setup, I decided to try with OpenVPN instead. After a bit of fiddling around I actually got it to work, but once again, I couldn't for the life of me manage to actually access any devices on the RUT (client) side. 5 hours of intense research and troubleshooting later, I think I found the source of my issues.

The OVPN interface is named "tun0". Apparently the router is rather helpful and automatically adds firewall zone forwarding for this interface behind the scenes, just as I'd want (though it would be nice to have some sort of GUI hint that this happens!), but: there's a stray underscore in the interface name in that zone definition, which of course prevents it from working at all.

The fix: in the CLI, type "vi /etc/config/firewall", near the end of the file is an entry that looks something like this:

config zone

  option device 'tun_+'

  option name 'openvpn'

  option masq '1'

  option input 'ACCEPT'

  option forward 'REJECT'

  option network 'openvpn'

  option output 'ACCEPT'

simply remove the underscore in the device name so it says 'tun+' instead, save and exit (that's ESC followed by :x for those unfamiliar with vim :) ), restart the firewall (/etc/init.d/firewall restart) and things should work.

It seems that this change persists with reboots, but the whole zone definition disappeared when I tried to change something else in the GUI (network/firewall/general/zones). To get it back, I had to make a couple of dummy OVPN clients, then I could remove the underscore and it worked again.

This seems like a bit of a fragile fix, so my question is, what would be a more proper solution? I expect this to be fixed in an update ASAP, but until then I'd like a better temporary solution for increased peace of mind :) 

By the way, speaking of bugs, another one that I hope will be fixed with the next update is that connection to mobile data fails on reboots. Can be fixed by adding /sbin/ & to the startup script, but that shouldn't really be necessary.

I'm a bit surprised at these bugs, I thought that reliably working in a site-to-site VPN configuration over a mobile link would be a very common use case for these routers …

by anonymous


After all it's a teltonikanism!


Nice find, thx!  Can confirm it works on my RUTX09 after a lot of head scratching. I also found the '_' but thought it was a 'teltonikanism'. And now let's see this chg survive any mod's. I'll update when it won't. Please do also till an official fix is available.

How nice when the UI is more comlex than the thing you need to config, guess that's progress and you can't stop it...

1 Answer

0 votes
by anonymous
I've also found this tun0 bug. Looks like it's been introduced in firmware 7.00, at least for the RUTX09.

The way I got around this bug bug was to create a config using an older version of firmware 2.06.1 (without the bug in the rule creation) then upgrade to 7.00 keeping the config. You could also add a custom firewall rule like "iptables -A INPUT -i tun+ -j ACCEPT" to allow all input traffic from tun interfaces.

I haven't seen the 'mobile data fails on reboots' bug on the RUTX09 and i've rebooted it about 20 times. I guess the hardware is different enough.