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
3,108 views 8 comments
by anonymous

Hi all,

I established an OpenVPN connection between 2 sites - 192.168.0.0/24 (HQ) and 192.168.2.0/24 (Remote office). In between there is a  transfer network.
From the HQ, the remote address of the router (10.5.0.6) in the transfer network can be reached (ICMP) but nothing else. 

I basically have 2 issues:

  1. I can ping a device on the HQ network only with active masquerading. When switching off masquerading the ping is not working anymore from a LAN device just from the routers console when using the transfer network address.
  2. No device on the remote network can be reached from the HQ; I created even a rule <From VPN to LAN> with any-any; and vice-vers with any-any.

Maybe if the first issue could be solved the 2nd on would be gone as well.





root@bus:~# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

10.5.0.1 10.5.0.5 255.255.255.255 UGH 0 0 0 tun_c_pep

10.5.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun_c_pep

192.168.0.0 10.5.0.5 255.255.255.0 UG 0 0 0 tun_c_pep

192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan

Note: any WAN addresses are removed from the table

I believe it is related to the routing.

Many thanks for any hint!

ps. I set Forward = Accept under General Rules meanwhile but no change...

1 Answer

+1 vote
by anonymous

Hello,

1. Try to add VPN forward to LAN zone.

2. You need to add TLS client to server to learn client internal subnet.

by anonymous

Hello,

Forwarding has been enabled and it generally works as long as I use "masquerading". When turning off masq... it fails.
I believe it is related to the routing. Unfortunately the VPN server is not a Teltonika but I will ask there Admin to check your 2. point regarding the TLS Client internal network.

But additionally I am wondering why I cannot ping from the client network the remote IP of the transfer network.
Ping from e.g. client 192.168.2.100 to 10.5.0.6 works fine but to 10.5.0.5 it doesn't.

10.5.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun_c_pep
192.168.0.0 10.5.0.5 255.255.255.0 UG 0 0 0 tun_c_pep
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan

Is that related to your suggestion as well?

Thanks!

by anonymous
Btw, we are not using TLS...
by anonymous
It's just example, server should know how to reach RUT lan. Usually openvpn use ccd with iroute option.

Anyway, try to ssh to router and use tcpdump  on vpn interface. If you see packets leaving router with proper IP's it means server side won't forward replies.

If packets are not leaving router then there will be something in firewall forwarding between lan and vpn zones.
by anonymous
SImonas,

Here the output of TCPDUMP:

root@bus:~# tcpdump -i tun_c_pep -vv
tcpdump: listening on tun_c_pep, link-type RAW (Raw IP), capture size 262144 bytes
13:56:32.666731 IP (tos 0x0, ttl 127, id 10227, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.2.133  > 192.168.0.240: ICMP echo request, id 1, seq 607, length 40

1 packet captured
1 packet received by filter
0 packets dropped by kernel
root@bus:~#

Network 192.168.2.0 is remote office and 192.168.0.0 the central office.

For me it is not clear whether the packet is leaving the router or not. I am not a Unix expert at all...

Thanks!
by anonymous
Looks like tunnel is fine and RUT is forwarding your ping.

If packet can't leave it won't show up in tcpdump log.

You need to check your central office server, why ping reply can't reach RUT.

I think your server does not have route to 192.168.2.0/24 over VPN.
by anonymous
Ok, great, many thanks. Now we can continue troubleshooting on the central site. It helped definitively a lot!
by anonymous
I will let you know the root cause and when issues is solved.
by anonymous
Still fighting on counterpart's site...