FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
604 views 2 comments
by anonymous

Trying to set up an OpenVPN client connection to a server at my workplace.  This VPN was working with an earlier RUT955 configuration and with other routers.  I have got the thing to connect and can see in the RUTX12 router table that the routes are there.

If I ping a server in the corporate network from the router itself, no problems:

PING 192.168.0.220 (192.168.0.220): 56 data bytes
64 bytes from 192.168.0.220: seq=0 ttl=63 time=71.509 ms
64 bytes from 192.168.0.220: seq=1 ttl=63 time=50.035 ms
64 bytes from 192.168.0.220: seq=2 ttl=63 time=60.364 ms
64 bytes from 192.168.0.220: seq=3 ttl=63 time=60.218 ms
64 bytes from 192.168.0.220: seq=4 ttl=63 time=63.026 ms
--- 192.168.0.220 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 50.035/61.030/71.509 ms

but this does not seem to be handled if performed from a client PC on the local LAN here.

ping -4 192.168.0.220
Pinging 192.168.0.220 with 32 bytes of data:
Request timed out.
Request timed out.
Ping statistics for 192.168.0.220:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),

Traceroute gives similar symptoms.  From the router:

traceroute to 192.168.0.220 (192.168.0.220), 30 hops max, 38 byte packets
1  10.21.21.1  36.765 ms
2  192.168.0.220  34.850 ms

And from a PC in the LAN:

tracert -d 192.168.0.220
Tracing route to 192.168.0.220 over a maximum of 30 hops
  1    <1 ms    <1 ms    <1 ms  10.66.99.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

I have tried just about anything I can think of, firewall rules, routes etc but no joy:

The routes are in the router pushed from the VPN server and they look ok to me.

Any hints or thoughts as to how I can resolve this?

by anonymous

This is the current routing table from the RUTX12

NETWORK TARGET IPV4-GATEWAY METRIC TABLE

(qmimux0) 0.0.0.0/0 1 main

(qmimux9) 0.0.0.0/0 2 main

wan 0.0.0.0/0 3 main

(tun0) 10.0.0.0/24 1 main

(tun0) 10.21.21.1 0 main

(tun0) 10.21.21.26 0 main

lan 10.66.99.0/24 1 main

(qmimux9) 10.114.10.208 2 main

(tun0) 10.168.0.0/24 1 main

(qmimux0) 10.230.44.197 1 main

(tun0) 172.16.141.0/24 1 main

(tun0) 172.40.2.0/24 1 main

(tun0) 192.168.0.0/24 1 main

wan 192.168.2.0/24 3 main

(tun0) 192.168.3.0/24 1 main

(tun0) 192.168.16.0/24 1 main

(tun0) 192.168.17.0/24 1 main

(tun0) 192.168.22.0/24 1 main

(tun0) 192.168.23.0/24 1 main

(tun0) 192.168.61.0/24 1 main

(tun0) 192.168.128.0/24 1 main

(tun0) 213.229.248.0/24 1 main

1 Answer

+1 vote
by anonymous

Ahah, it looks like the openvpn firewall helper script adds rules with node tun_+ whereas the tunnel is actually created as tun0, so changing them all to tun+ works perfectly.

Now I need to work out how to persist the change needed.

Also noted that the manual non-ovpn file configuration in the RUTX12 ignores the tls-auth key direction setting.  Think that is another bug.

The firewall errors are in 

/usr/lib/lua/ubus/services/openvpn.lua  where it has the line:    device  = 'tun_+'

/etc/config/firewall where it has the section:

config zone
        option device 'tun_+'
        option name 'openvpn'
        option input 'ACCEPT'
        option network 'openvpn'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option masq '1'

And I suspect one is derived from the other.

by anonymous
Thanks, Bro!!
You saved my, day after 4 hours of troubleshooting!

But I had only to change the file: /etc/config/firewall
If I change the openvpn.lua, I can not login any more via WebUI.