[TRB500] OpenVPN connected but not access to LAN

Teltonika Networks
1

Hi,

I established an OpenVPN “site-to-site” connection between my Teltonika TRB500 router (which is the client) and a pfSense router (which is the server). The tunnel works. Please see the OpenVPN config in attach.

The problem is : I cannot access to the LAN of Teltonika TRB500 router from pfSense (example : ping does not respond).

LAN Teltonika: 192.168.2.0/24
Network tunnel: 10.90.200.0/24

The tunnel works because the two routers manage to ping each other on their addresses used for the tunnel.

  • Ping 10.90.200.1 (pfSense) => 10.90.200.2 (Teltonika) work
  • Ping 10.90.200.2 (Teltonika) => 10.90.200.1 (pfSense) work

But ping 192.168.2.1 (Teltonika device LAN address) from 10.90.200.1 (pfSense) not working!

The routing tables are nevertheless good :

I think it’s a problem in the firewall.
On the pfSense side, I authorize everything for OpenVPN.
On the Teltonika side, I left the default rules that were created (please see https://i.ibb.co/wB0kkYT/firewall.jpg).

OpenVPN Client config in Teltonika :

openvpn-client copie
openvpn-client copie1241×2592 284 KB

3

Hello,

The firewall and routes look okay. If you have updated the device to the latest firmware version with ‘keep settings’ option enabled, this may have caused the issue. Could you please try the same things as mentioned in this post here and let me know about the results?

Kind Regards,

4

Hello,

I just did a factory reset of my TRB500 router and reconfigured my OpenVPN TUN site-to-site connection. The tunnel is up. Already, I can ping the TRB500 (which is an OpenVPN client) from the server (pfSense) and also from TRB500 to pfSense on their IP addresses used for the tunnel, but impossible to ping the LAN address (192.168.2.1) of the TRB500 from the server (pfSense).

It’s seems, the TRB500 does not forward packets coming from the tunnel to the LAN (or the firewall is blocking something?).

I installed tcpdump (please see bellow) and we see that ping on the tunnel IP address works, but we don’t see any ping request when I tried to ping to “192.168.2.1”.

However, on the server side (pfSense), in my routing table, I have a route 192.168.2.0/24 which sends to the tunnel gateway (10.90.200.2) (and conversely in the TRB500 I have a route from back).

What else can I try?

Thanks for your help

   ____        _    ___  ____
  |  _ \ _   _| |_ / _ \/ ___|
  | |_) | | | | __| | | \___ \
  |  _ <| |_| | |_| |_| |___) |
  |_| \_\\__,_|\__|\___/|____/
---------------------------------
    Teltonika TRB5 series 2023
---------------------------------
   Device:     TRB500
   Kernel:     4.14.319
   Firmware:   TRB5_R_00.07.05
   Build:      fbfe39de21
   Build date: 2023-10-05 10:07:09
---------------------------------
root@TRB500:~# opkg update
Downloading https://downloads.openwrt.org/releases/21.02.0/targets/sdxprairie/generic/packages/Packages.gz
*** Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/targets/sdxprairie/generic/packages/Packages.gz

Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/routing/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/telephony/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/vuci/Packages.gz
*** Failed to download the package list from https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/vuci/Packages.gz

Downloading http://opkg.teltonika-networks.com/1cea26e83f9e63789112c95393d0586301318cd1dc122cde40715025f69abfb9/Packages.gz
Updated list of available packages in /var/opkg-lists/tlt_packages
Downloading http://opkg.teltonika-networks.com/1cea26e83f9e63789112c95393d0586301318cd1dc122cde40715025f69abfb9/Packages.sig
Signature check passed.
Collected errors:
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/targets/sdxprairie/generic/packages/Packages.gz, wget returned 8.
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/21.02.0/packages/arm_cortex-a7_neon-vfpv4/vuci/Packages.gz, wget returned 8.
root@TRB500:~# opkg install tcpdump
Installing tcpdump (4.99.4-1) to root...
Downloading http://opkg.teltonika-networks.com/1cea26e83f9e63789112c95393d0586301318cd1dc122cde40715025f69abfb9/tcpdump_4.99.4-1_arm_cortex-a7_neon-vfpv4.ipk
Configuring tcpdump.
root@TRB500:~# 
root@TRB500:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 20:97:27:08:2F:7E  
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::2297:27ff:fe08:2f7e/64 Scope:Link
          inet6 addr: fd49:97fb:78bd::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11492 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9692 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1193053 (1.1 MiB)  TX bytes:7458185 (7.1 MiB)

ecm0      Link encap:Ethernet  HWaddr 20:97:27:08:2F:7F  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 20:97:27:08:2F:7E  
          inet addr:169.254.4.1  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::2297:27ff:fe08:2f7e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11492 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9672 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3497923809 (3.2 GiB)  TX bytes:7455916 (7.1 MiB)
          Interrupt:41 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:462 errors:0 dropped:0 overruns:0 frame:0
          TX packets:462 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:39842 (38.9 KiB)  TX bytes:39842 (38.9 KiB)

rmnet_data0 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:100.119.158.252  Mask:255.255.255.255
          inet6 addr: fe80::dd37:57ac:9bd1:a534/64 Scope:Link
          UP RUNNING  MTU:1500  Metric:1
          RX packets:1231 errors:0 dropped:0 overruns:0 frame:0
          TX packets:878 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1309358 (1.2 MiB)  TX bytes:91094 (88.9 KiB)

rmnet_ipa0 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet6 addr: fe80::244d:b113:85eb:56c2/64 Scope:Link
          UP RUNNING  MTU:9216  Metric:1
          RX packets:505 errors:0 dropped:0 overruns:0 frame:0
          TX packets:878 errors:0 dropped:13 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1319206 (1.2 MiB)  TX bytes:98118 (95.8 KiB)

tun_c_OVPNSKS Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.90.200.2  P-t-P:10.90.200.2  Mask:255.255.255.0
          inet6 addr: fe80::d641:c8d6:3a37:f177/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:504 (504.0 B)  TX bytes:808 (808.0 B)

root@TRB500:~# tcpdump -i tun_c_OVPNSKS icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun_c_OVPNSKS, link-type RAW (Raw IP), snapshot length 262144 bytes
13:37:42.380191 IP 10.90.200.1 > 10.90.200.2: ICMP echo request, id 1341, seq 0, length 64
13:37:42.380429 IP 10.90.200.2 > 10.90.200.1: ICMP echo reply, id 1341, seq 0, length 64
13:37:42.957589 IP 10.90.200.1 > 10.90.200.2: ICMP echo request, id 1341, seq 1, length 64
13:37:42.957699 IP 10.90.200.2 > 10.90.200.1: ICMP echo reply, id 1341, seq 1, length 64
13:37:43.980880 IP 10.90.200.1 > 10.90.200.2: ICMP echo request, id 1341, seq 2, length 64
13:37:43.981003 IP 10.90.200.2 > 10.90.200.1: ICMP echo reply, id 1341, seq 2, length 64
6 packets captured
6 packets received by filter
0 packets dropped by kernel
5

Please put here your OpenVPN server config file.

6

Hi @mirco

Below is the server-side OpenVPN config (pfSense) :

dev ovpns2
verb 1
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 178.32.45.57
tls-server
server 10.90.200.0 255.255.255.0
client-config-dir /var/etc/openvpn/server2/csc
ifconfig 10.90.200.1 10.90.200.2
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'OpenVPN+Server' 1"
lport 10500
management /var/etc/openvpn/server2/sock unix
push "route 10.90.100.0 255.255.255.0"
remote-cert-tls client
route 192.168.2.0 255.255.255.0
capath /var/etc/openvpn/server2/ca
cert /var/etc/openvpn/server2/cert 
key /var/etc/openvpn/server2/key 
dh /etc/dh-parameters.2048
data-ciphers AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression no
topology subnet
explicit-exit-notify 1
7

The only thing that i think i did differently was to explictly route the interested ip (in my case, 192.168.1.186) like this:

route 192.168.1.186 255.255.255.255

And in the relative ccd file also, but with iroute

iroute 192.168.1.186 255.255.255.255

But it shouldn’t change so much.

Is the ccd file named correctly?

1 Like
8

Is the ccd file named correctly?
client-config-dir “/var/etc/openvpn/server2/csc” is empty on my pfSense.

I have doubts that the problem comes from the OpenVPN configuration because as shown, the tunnel works and both routers know how to ping each other on their OpenVPN network IP addresses. I have the feeling that it is at the RutOS level that there is something blocking access to the LAN.

9

Yes, I understand. I’ll give some info I found anyway about ccd.

I refer to this snippet of the OpenVPN server sample configuration

# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.

More info on ccd usage on https://community.openvpn.net/openvpn/wiki/HOWTO#ExpandingthescopeoftheVPNtoincludeadditionalmachinesoneithertheclientorserversubnet

Don’t know if it can help you.

1 Like
10

iroute 192.168.2.0 255.255.255.255

You were right, this is the solution!

In the OpenVPN server (pfSense), I create a file with the name of the CN of the client certificate in the “client-config-dir” directory and adding “iroute 192.168.2.0 255.255.255.255” and it’s work !

Thanks a lot for your help!

However, I don’t understand why pfSense not created the iroute?
Do you have an explanation ?

1 Like
11

Glad I could help!

I think it wasn’t supposed to do it automatically, you have to do it manually as stated by the guide I posted before and this that I posted below.

1 Like
12

This topic was automatically closed after 15 days. New replies are no longer allowed.