FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

12730 questions

15120 answers

24265 comments

47319 members

0 votes
243 views 0 comments
by

A VPN connection from an RUT240 (RUT2_R_00.07.02.2) to an OpenVPN server is established to access devices behind it.
eth0 and eth1 are bridged and an embedded device is connected to eth0 and a PC to eth1. The PC can access the webpage of the device without problems. The PC can be accessed (TCP and ICMP) from the other side of the VPN connections without problems (icmp was limited to local network on the PC and was unblocked in the firewall of the PC).
Also the router can be accessed through the tunnel without problems, of course.
PC and device get the IP addresse from DHCP server of the router.

The device access is limited to the local network and cannot be configured, so SNAT is needed for accessing the device.
I created a SNAT rule and it worked only half way. With tcpdump on eth0 I saw the device answering the ICMP request from the routers IP but the response did not come back through the tunnel. The same problem was for TCP as well.
I tried the other approach of using the masquerading switch for lan->openvpn in the firewall zone setting (mentioned in this forum) but I got the same result. Old SNAT rule was deactivated, of course.

I made the same test with the PC and got a response without problems. With tcpdump on eth1 I saw the icmp packets with the IP address of the router. Ping worked also with icmp limited to local network on the PC, because of the masquerading. That is what I want for the device too.

With tcpdump on all interfaces I can see the the ICMP packets coming from the tunnel, get masqueraded, going to the device with a response back which is finally not nated and therefore not coming back through the tunnel:

18:09:14.635642 IP 10.111.111.1 > 192.168.165.1: ICMP echo request, id 59774, seq 9472, length 30
18:09:14.635978 IP 192.168.165.0 > 192.168.165.1: ICMP echo request, id 59774, seq 9472, length 30
18:09:14.636036 IP 192.168.165.0 > 192.168.165.1: ICMP echo request, id 59774, seq 9472, length 30
18:09:14.638069 IP 192.168.165.1 > 192.168.165.0: ICMP echo reply, id 59774, seq 9472, length 30
18:09:14.638162 IP 192.168.165.1 > 192.168.165.0: ICMP echo reply, id 59774, seq 9472, length 30
18:09:14.638069 IP 192.168.165.1 > 192.168.165.0: ICMP echo reply, id 59774, seq 9472, length 30

With the PC it looks like this:

18:09:20.154068 IP 10.111.111.1 > 192.168.165.2: ICMP echo request, id 59774, seq 10496, length 30
18:09:20.154381 IP 192.168.165.0 > 192.168.165.2: ICMP echo request, id 59774, seq 10496, length 30
18:09:20.154531 IP 192.168.165.0 > 192.168.165.2: ICMP echo request, id 59774, seq 10496, length 30
18:09:20.154717 IP 192.168.165.2 > 192.168.165.0: ICMP echo reply, id 59774, seq 10496, length 30
18:09:20.154717 IP 192.168.165.2 > 192.168.165.0: ICMP echo reply, id 59774, seq 10496, length 30
18:09:20.154923 IP 192.168.165.2 > 10.111.111.1: ICMP echo reply, id 59774, seq 10496, length 30

I also switched the ports: eth0->PC; eth1->device but it made no difference.

I set the IP config of the device manually with IP, mask, and gateway, but with no difference.

I made a pcap with tcpdump on any interface to find a difference between the icmp packets of the device and the PC and cannot figure out what the difference is. Unfortunately, the pcap does not include the MAC layer.

Why is there a difference in behavior? And what can I do to find the reason?
It must be something stupid easy, otherwise I would have found it.

2 Answers

0 votes
by

Hello, 

I will need some diagrams if possible with IP addresses and SNAT addresses to better understand the issue. On the other hand, I have other questions.

  1. Why can the device only be reached by the local network? It is not connected to the tunnel? Why don't you try port forwarding instead of a SNAT rule?
  2. Why are the eth0 and eth1 interfaces bridged? What do you want to achieve with this?
  3. Because of what you say. The ping may travel from the router to the device over the LAN. But not back to the tunnel, maybe because there is no route to reach the device on the other side of the tunnel? It is possible that the PC does not have a problem because it is connected as a VPN client.

Because instead of using a SNAT, you first add the device to the VPN. If you do not want to do this. Why don't you add the route from the VPN to the end device? This should solve your problem. 

0 votes
by
Ok, I found the problem, and it was stupid.

192.168.165.0 (I gave to the router) is not a valid host address for subnet /24 and smaller. It is the network identifier.

With 192.168.165.1 everything works fine without any NAT at all. The routers IP is used as gateway and the embedded device will not work with a network identifier as gateway, while other devices don't bother.

It would be interesting to know how this looks like on MAC level, but I don't know how to get this without to much effort.

Many Thanks!