WIKIABOUT

FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

Most popular tags

rut955 rut240 rut950 rutx11 rms vpn to openvpn wifi not sms trb140 firmware connection - ipsec on rutx12 rutx09 modbus
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.

Routing issues on RUT240 when used in conjunction with OpenVPN Cloud

0 votes
466 views 2 comments
by anonymous

Hi Guys,

I have been experimenting with OpenVPN cloud with my RUT240 and I had it working perfectly fine until last week and then everything stopped working all of a sudden since Monday. 

My current setup is:

                Client site                       WAN                                                                  Home

|RUT240 router (vpn connector)|<----------> |OpenVPN Cloud|<---------->|User Laptop (vpn connect)|

LAN 192.168.1.0/24

Device 1: 192.168.1.1

Device 2: 192.168.1.2

and the server has been configured to make 192.168.1.0/24 accessible by all clients. 

I had a quick look at the system log and it was throwing out a few error messages which may be the cause of the issue although I am unable to confirm as I haven't seen these messages before:

daemon.err openvpn(vpntest)[10821]: event_wait : Interrupted system call (code=4)

daemon.notice openvpn(vpntest)[10821]: SIGTERM received, sending exit notification to peer

  daemon.notice openvpn(vpntest)[10821]: net_route_v4_del: 100.96.0.0/11 via 100.96.1.17 dev [NULL] table 0 metric -1

  daemon.notice openvpn(vpntest)[10821]: net_route_v4_del: 100.80.0.0/12 via 100.96.1.17 dev [NULL] table 0 metric -1

  daemon.notice openvpn(vpntest)[10821]: delete_route_ipv6(fd:0:0:8000::/49)

  daemon.notice openvpn(vpntest)[10821]: net_route_v6_del: fd:0:0:8000::/49 via :: dev tun_c_vpntest table 0 metric -1

  daemon.notice openvpn(vpntest)[10821]: delete_route_ipv6(fd:0:0:4000::/50)

  daemon.notice openvpn(vpntest)[10821]: net_route_v6_del: fd:0:0:4000::/50 via :: dev tun_c_vpntest table 0 metric -1

  daemon.notice openvpn(vpntest)[10821]: Closing TUN/TAP interface

  daemon.notice openvpn(vpntest)[10821]: net_addr_v4_del: 100.96.1.18 dev tun_c_vpntest

  daemon.notice openvpn(vpntest)[10821]: net_addr_v6_del: fd:0:0:8101::2/64 dev tun_c_vpntest

  daemon.notice openvpn(vpntest)[10821]: SIGTERM[soft,exit-with-notification] received, process exiting

  daemon.warn openvpn(vpntest)[24532]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

  daemon.notice openvpn(vpntest)[24532]: OpenVPN 2.5.3 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]

  daemon.notice openvpn(vpntest)[24532]: library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10

  daemon.notice openvpn(vpntest)[24532]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

  daemon.notice openvpn(vpntest)[24532]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

  daemon.notice openvpn(vpntest)[24532]: TCP/UDP: Preserving recently used remote address: [AF_INET]66.203.112.173:1194

  daemon.notice openvpn(vpntest)[24532]: Socket Buffers: R=[180224->180224] S=[180224->180224]

  daemon.warn openvpn(vpntest)[24532]: NOTE: setsockopt TCP_NODELAY=1 failed

  daemon.notice openvpn(vpntest)[24532]: UDP link local: (not bound)

  daemon.notice openvpn(vpntest)[24532]: UDP link remote: [AF_INET]66.203.112.173:1194

  daemon.notice openvpn(vpntest)[24532]: TLS: Initial packet from [AF_INET]66.203.112.173:1194, sid=16c9ae4d 6b5b0b01

  daemon.notice openvpn(vpntest)[24532]: VERIFY OK: depth=1, CN=CloudVPN Prod CA

  daemon.notice openvpn(vpntest)[24532]: VERIFY KU OK

  daemon.notice openvpn(vpntest)[24532]: Validating certificate extended key usage

  daemon.notice openvpn(vpntest)[24532]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

  daemon.notice openvpn(vpntest)[24532]: VERIFY EKU OK

  daemon.notice openvpn(vpntest)[24532]: VERIFY OK: depth=0, CN=au-syd-dc1-b1.cloud.openvpn.net

 daemon.notice openvpn(vpntest)[24532]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 2048 bit RSA, signature: RSA-SHA256

 daemon.notice openvpn(vpntest)[24532]: [au-syd-dc1-b1.cloud.openvpn.net] Peer Connection Initiated with [AF_INET]66.203.112.173:1194

  daemon.notice openvpn(vpntest)[24532]: SENT CONTROL [au-syd-dc1-b1.cloud.openvpn.net]: 'PUSH_REQUEST' (status=1)

  daemon.notice openvpn(vpntest)[24532]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 100.96.1.17,ifconfig 100.96.1.18 255.255.255.240,ifconfig-ipv6 fd:0:0:8101::2/64 fd:0:0:8101::1,client-ip 219.88.67.71,ping 8,ping-restart 40,reneg-sec 3600,cipher AES-256-GCM,compress stub-v2,peer-id 8862,topology subnet,explicit-exit-notify,remote-cache-lifetime 86400,block-outside-dns,route 100.96.0.0 255.224.0.0,route-ipv6 fd:0:0:8000::/49,route 100.80.0.0 255.240.0.0,route-ipv6 fd:0:0:4000::/50,dhcp-option DNS 100.96.1.17,auth-tokenSESS_ID,auth-token-user cnBtdnBuL2Nvbm5lY3Rvci82ZTE2NDZjYy0wMjgxLTQ4ODYtYTk1OS02OGI5NDE3OWRmZDZfNzA1MzYwODQtY2UxZS00ZTU1LTliY2QtNGMwMTM2MzljNDI5'

  daemon.err openvpn(vpntest)[24532]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: client-ip (2.5.3)

  daemon.err openvpn(vpntest)[24532]: Options error: option 'reneg-sec' cannot be used in this context ([PUSH-OPTIONS])

  daemon.err openvpn(vpntest)[24532]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:13: remote-cache-lifetime (2.5.3)

  daemon.err openvpn(vpntest)[24532]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:14: block-outside-dns (2.5.3)

  daemon.warn openvpn(vpntest)[24532]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: timers and/or timeouts modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: explicit notify parm(s) modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: compression parms modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: --ifconfig/up options modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: route options modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: route-related options modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: peer-id set

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: adjusting link_mtu to 1624

  daemon.notice openvpn(vpntest)[24532]: OPTIONS IMPORT: data channel crypto options modified

  daemon.notice openvpn(vpntest)[24532]: Data Channel: using negotiated cipher 'AES-256-GCM'

  daemon.notice openvpn(vpntest)[24532]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

  daemon.notice openvpn(vpntest)[24532]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

  daemon.notice openvpn(vpntest)[24532]: net_route_v4_best_gw query: dst 0.0.0.0

  daemon.notice openvpn(vpntest)[24532]: net_route_v4_best_gw result: via 10.0.0.1 dev eth1

  daemon.notice openvpn(vpntest)[24532]: GDG6: remote_host_ipv6=n/a

  daemon.notice openvpn(vpntest)[24532]: net_route_v6_best_gw query: dst ::

  daemon.warn openvpn(vpntest)[24532]: sitnl_send: rtnl: generic error (-13): Permission denied

  daemon.notice openvpn(vpntest)[24532]: TUN/TAP device tun_c_vpntest opened

  daemon.notice openvpn(vpntest)[24532]: net_iface_mtu_set: mtu 1500 for tun_c_vpntest

  daemon.notice openvpn(vpntest)[24532]: net_iface_up: set tun_c_vpntest up

  daemon.notice openvpn(vpntest)[24532]: net_addr_v4_add: 100.96.1.18/28 dev tun_c_vpntest

  daemon.notice openvpn(vpntest)[24532]: net_iface_mtu_set: mtu 1500 for tun_c_vpntest

  daemon.notice openvpn(vpntest)[24532]: net_iface_up: set tun_c_vpntest up

  daemon.notice openvpn(vpntest)[24532]: net_addr_v6_add: fd:0:0:8101::2/64 dev tun_c_vpntest

  daemon.notice openvpn(vpntest)[24532]: net_route_v4_add: 100.96.0.0/11 via 100.96.1.17 dev [NULL] table 0 metric -1

  daemon.notice openvpn(vpntest)[24532]: net_route_v4_add: 100.80.0.0/12 via 100.96.1.17 dev [NULL] table 0 metric -1

  daemon.notice openvpn(vpntest)[24532]: add_route_ipv6(fd:0:0:8000::/49 -> fd:0:0:8101::1 metric -1) dev tun_c_vpntest

  daemon.notice openvpn(vpntest)[24532]: net_route_v6_add: fd:0:0:8000::/49 via :: dev tun_c_vpntest table 0 metric -1

 daemon.notice openvpn(vpntest)[24532]: add_route_ipv6(fd:0:0:4000::/50 -> fd:0:0:8101::1 metric -1) dev tun_c_vpntest

 daemon.notice openvpn(vpntest)[24532]: net_route_v6_add: fd:0:0:4000::/50 via :: dev tun_c_vpntest table 0 metric -1

 daemon.notice openvpn(vpntest)[24532]: Initialization Sequence Completed

daemon.info hostapd: wlan0: STA a4:c4:94:3f:28:07 WPA: group key handshake completed (RSN)

Has anyone run into this type of problem before? I am a bit puzzled by the sudden change over the weekend.. perhaps there has been some changes on the server side regarding formats on pushing options to the clients and RUT240 is unable to cope with this change? Seeking for an advice/explanation..

1 Answer

0 votes
by anonymous
Hello,

I have tested RUT240 while I was trying to connect the router to OpenVPN cloud. The connection to the could was successful and I too got the same messages, however, I was also able to ping my pc from the router and router from the PC, so these messages would not be an issue regarding the ability to reach the devices.

The addresses you mentioned, were they the actual LAN addresses or the virtual IP's given by the OpenVPN cloud server? If those are the LAN addresses of your devices, then that could be the issue you are having, since both the remote (router) and the local (PC) device networks addresses are in the same subnet. If you changed the LAN subnet on the RUT240, could you then reach the router or pc with their respective LAN IP's?

For the client devices to communicate on an OpenVPN you would require some configuration on the server side, but what those options would be I am unable to tell since that is not our platform.

Regards,

Paulius
by anonymous
Hey Paulius,

I was able to get everything working again by enabling the UDP traceroute. It was turned off for some reason and I am not sure if that's the default setting on RUT240 but all things came back to normal as soon as the option was enabled..
by anonymous
Hey,

After checking on the router, yes, the rule is indeed disabled by default on RUT240 in the new RutOS version.

However, by doing some searching on OpenWRT forums, it seems that this rule is disabled by default on the OpenWRT kernel version 20.02 which RutOS is based on.

Regards,

Paulius