Question

Does anyone have any idea about the Teltonika RUT240?

I have the following problem:

All connected devices on the RUT (LAN & WLAN) are only accessible in an internal network. So there is no internet available. There is no tunneling from the LAN / WLAN over the OpenVPN.

Initial situation:

- Internet is available via mobile

- RUT is connected as OpenVPN client with my server.

 (I can also access the admin interface of the RUT from outside via the VPN)

Can someone say how possibly the local devices can also use the OpenVPN connection (and thus the Internet)?  I have already tried several things (e.g. TRaffic Rules), but it does not work. (Possibly also incorrectly configured)

I have already tested the openVPN with another device. There everything works. So it must be a configuratiosn error in the RUT.

Comments

Hello,

Could you please describe in a little bit more detail what exactly doesn't work regarding this configuration? Does the internet stop working on all devices (connected to the router) when you connect to the VPN server or does the router simply not route traffic from devices in LAN to the VPN server?

Also, traffic rules in this case may not be necessary because, as far as I understand, you'd like to simply use the OpenVPN server as a proxy service for all of your devices in LAN, is that correct?

Best regards,

Tomas.

Answer 1

Hi,

I'm running into a similar issue.

RUTX11

Firmware version	RUTX_R_00.02.06.1
Firmware build date	2021-02-11 16:38:18

 

I have configured an OpenVPN connection towards NordVPN, I can see in the GUI that the tunnel is up and running (connected).

When I open a terminal to the X11 router I see the route:

root@Teltonika-RUTX11:/etc# ip r

0.0.0.0/1 via 10.8.0.1 dev tun0

default via 10.40.1.1 dev eth1 proto static src 10.40.1.157

default dev qmimux0 proto static scope link src 83.162.50.2 metric 1

10.8.0.0/16 dev tun0 proto kernel scope link src 10.8.0.135

10.40.0.0/16 dev eth1 proto kernel scope link src 10.40.1.157

83.162.50.2 dev qmimux0 proto static scope link metric 1

128.0.0.0/1 via 10.8.0.1 dev tun0

192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1

217.23.2.31 via 10.40.1.1 dev eth1

I can ping from the router to the internet and a traceroute shows me that the connections goes via my NordVPN tunnel.

 1  10.8.0.1 (10.8.0.1)  5.827 ms  5.576 ms  5.469 ms

 2  customer.worldstream.nl (217.23.2.216)  5.585 ms  customer.worldstream.nl (217.23.2.215)  5.621 ms  customer.worldstream.nl (217.23.2.216)  5.559 ms

So far so good. Tunnel is up and running and the X11 router can connect via the tunnel the rest of the world.

However, my laptop which is connected via a cable to the LAN1 port is NOT able to connect the internet, yes I can connect to my router 192.168.1.1 but no connection to the outside world.

Any ideas how to solve this?

Answer 2

This is a known issue and we're aiming to have it fixed in future firmware release 7.2. 

As a workaround, currently it'd be enough to execute the following commands via SSH/CLI on the router and then modify firewall settings slightly. The following commands should be executed in order:

uci set network.vpn1='interface'

uci set network.vpn1.ifname='tun0'

uci set network.vpn1.proto='none'

uci set network.vpn1.metric='100'

uci commit

/etc/init.d/network restart

Once done, navigate to Network>Firewall>General settings (default window), edit the "openvpn" zone and next to the "Covered networks" section select "vpn1". Additionally, make sure "Allow forward to destionation zones" has a "wan" zone specified (screenshot). Then, save & apply settings and try to restart the VPN (turn it off and on) and see if it works after these steps. I'm also attaching a screenshot how the "openvpn" zone should look like when configured this way.

Please note that this workaround may not solve these issues if more than one VPN tunnel configured at a time. As an additional way to make sure this issue does not occur often, it's recommended to include the following option in OpenVPN configuration file if possible:

dev tun0

This is only useful when configuring multiple OpenVPN interfaces. Please note that uci commands must be adapted accordingly to this "dev tun0" interface. If only one OpenVPN tunnel exists then it shouldn't be necessary to assign a static virtual interface name for this tunnel.

Best regards,

Tomas.

Comments

Hi Tomas,

Thanks for your prompt reply!

Do I have to execute the commands with a running tunnel connection or first execute the commands and then enable the tunnel?

This works like a charm, thanks for your support!

---

It's recommended to create the VPN tunnel first and enable it, then execute the commands in CLI and configure firewall rules. The connection should be established the moment firewall rules are configured. It shouldn't be necessary to turn off the tunnel and re-enable it but in the case connection doesn't come up even after the CLI commands and the firewall rules have been configured, I'd recommend disabling and enabling the VPN tunnel.

The reason why it's convenient to do it this way is because "tun0" interface is created the moment the VPN tunnel is created.

Let me know if there's any other issues regarding this configuration.

Best regards,

Tomas.

---

OpenVPN tunnel was active on tun0, A hotspot (10.30.30.0/24) was created and active, connected to the hotspot and all traffic followed the tunnel.

0.0.0.0/1 via 10.8.2.1 dev tun0
default via 10.40.1.1 dev eth1 proto static src 10.40.1.157 metric 2
default dev wwan0 proto static scope link src 83.161.172.122 metric 3
10.8.2.0/24 dev tun0 proto kernel scope link src 10.8.2.11
10.30.30.0/24 dev tun1 proto kernel scope link src 10.30.30.10
10.40.0.0/16 dev eth1 proto static scope link metric 2
83.161.172.122 dev wwan0 proto static scope link metric 3
128.0.0.0/1 via 10.8.2.1 dev tun0
192.168.1.0/24 dev br-lan proto static scope link metric 1
217.138.197.235 via 10.40.1.1 dev eth1

But after a reboot the hotspot claims tun0 and the OpenVPN can only use tun1 in this case which makes the OpenVPN tunnel to fail again.

I hope that issue will be solved as well. I have the router now for 2 days and already discovered multiple bugs.


Update:
I started all over again with the router set up factory defaults and with firmware 7.01.2

First the Setup wizzard completed, then created a hotspot and tested it. The hotspot is on tun0.
Now setup my OpenVPN connection and applied the proposed settings as above (from Thomas) but used tun1

uci set network.vpn1='interface'
uci set network.vpn1.ifname='tun01'
uci set network.vpn1.proto='none'
uci set network.vpn1.metric='100'
uci commit
/etc/init.d/network restart


Now the setup works as expected even after a reboot.

The functionality should not be depended on the order how it was created.

---

Hello,

Just to clarify - the "tunX" interface is dynamic, meaning that if there is already "tun0" and "tun1" tunnel, adding a new one will make the new tunnel name "tun2". However, OpenVPN has a built-in option to specify a static interface name. This way it'd be possible to assign a static interface name (for example "tun50") so that the VPN tunnel name always point to the correct interface name. 

In order to do this, it's recommended to either login to the router and set the interface name of VPN tunnel in the OpenVPN configuration at Services>VPN>OpenVPN [edit the tunnel], find the "Extra options" field and enter the following command:

dev tun50

Save the configuration when done and in the already provided rules specify the following:

uci set network.vpn1='interface'

uci set network.vpn1.ifname='tun50'

uci set network.vpn1.proto='none'

uci set network.vpn1.metric='100'

uci commit

/etc/init.d/network restart

The same is also possible to do in the ".ovpn" configuration file, simply add a line "dev tun50" (without quotation marks) and save the .ovpn file, then upload it again and save & apply the configuration on the router.

This configuration part will make sure that the specified OpenVPN tunnel will always have a static interface name alongside with it. However, like mentioned before, this is only necessary if you're using multiple OpenVPN tunnels or other services which rely on "tun" interface naming method.

Best regards,

Tomas.

Answer 3

The last tip from Tomas works fine, I have modified all my .ovpn files and changed 'dev tun'  into 'dev tun10'

Added the uci commands and now the tunneling + Hotspot seems to work fine afer a reboot.