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:
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/ndisconn.sh & 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 …