Trying to setup Site to Site VPN

Porfavorio

Good evening,

I am currently having issues setting up a site to site VPN on OpenVPN Access Server.

The setup is:

There are to sites.

- Site A: Homes LAN with Router/Modem (Fritzbox), several endpoints behind it (no VPN server). The subnet is the router's, let's say 192.168.1.0/24 (it is not this!).

- Site 2 B: Netcup (hoster) VLAN, two VPS behind. On their second NIC they have the same subnet, let's say 130.130.1.0/24, so one has 130.130.1.1 and the other 130.130.1.2

On one VPS Ubuntu with OpenVPN Access Server is configured.
From Site A I can access site B, but not the other way around (so a normal Access Server so far).

What I did so far:

- On OpenVPN Access Server under "VPN Settings" I entered site B's subnet.
- Under "User Permissions" entered the same subnet at "Allow Access" eingetragen and ticket anything there.
- There under "VPN Gateway" I entered Site A's subnet.

So far I cannot access site A from site B.

Could you please guide me to the next step? Where are there routes to be entered - Ubuntu NIC Site B, Router on Site ? What to do now?

Let me know if you need more information.

Thank you in advance.

openvpn_inc

Hello Porfavorio,

I suggest you take a look at the pictures in this page;
https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/

It shows a step-by-step of how the traffic flows in a typical site-to-site setup. That should give you an indication where the routes are to be entered. The document also explains this in detail. Also it links to a troubleshooting guide that can help you pinpoint where the traffic is getting stuck.

I suspect you didn't enter the static routes for the subnets in the respective routers.

Kind regards,
Johan

Porfavorio

This is where I got my information from. Furthermore, I don't really know where to start at troubleshooting. I need some more hints.

What I did on the router of site A is set two static routes:

- Network: 130.130.1.0, Subnet: 255.255.255.0, Gateway: IP of machine where I am connecting from
- Network: 172.27.0.0 Subnet: 255.255.240.0, Gateway: IP of machine where I am connecting from

Is this correct so far?

Porfavorio

What I possibly need to add: I do not have a static IP on site A (but DDNS, which OpenVPN does not know in this setup). Does this matter?

openvpn_inc

Hello Porfavorio,

In site A you need the subnet of site B configured as static route in your Fritz!Box router, pointing to the private IP of the machine that is making the OpenVPN connection to site B (this can be a Linux instance with OpenVPN client running and IP forwarding enabled). It also helps if you add the VPN client subnet itself to the Fritz!Box router.

Now, _normally_ in site B you do the reverse - you would normally in site B need the subnet of site A configured as static route in the router on site B, pointing to the private IP of the machine that is making the OpenVPN connection to site A (this can be the OpenVPN Access Server for example - it has IP forwarding enabled by default). It also helps if you add the VPN client subnet to the router in site B.

However, I don't think you have a router in site B. It looks like there is just 2 machines with a private LAN. And no router.

In that case, on each machine (other than the one that is running Access Server) you can add the route for the subnet in site A to the routing table, pointing to the private IP of the OpenVPN connection to site A (in this case 130.130.1.1 if I understand correctly). It also helps to add the VPN client subnet itself.

Now when the machine at 130.130.1.2 wants to reach site A, it will look at its own routing table, see that it needs to go through 130.130.1.1 to get there, and the traffic will then flow to the OpenVPN client at site A, and from there to the subnet at site A. A response from a machine in site A will go to the Fritz!Box router first, which contains a static route that says - go through the machine that is running the OpenVPN client connection in site A. Which will then pass it on to Access Server. Which will then pass it on to site B's subnet.

I hope this makes sense.

To test, use the troubleshooting guide. Install tcpdump on the machine running the OpenVPN client and on OpenVPN Access Server itself, and run it while monitoring for ICMP ping signals. Then ping from a machine in subnet A to a machine in subnet B and monitor the results.

Kind regards,
Johan

openvpn_inc

Oh one more thing. Regarding the IP of the OpenVPN tunnel termination - that's irrelevant. If the tunnel is up and running, then all is good. Then traffic can flow through it and reach the other side. The IP of the transport layer is not relevant here - only the IP of the payload.

Kind regards,
Johan

Porfavorio

Thank you for explaining that clearly.
I now tried to ping from my client to the Access Server host. As predescribed, the ping on the client says it works. However, using tcpdump in Ubuntu console doesn't tell me anything like the echo results described in the troubleshooting guide. Is this definitely what I should see there?

tcdump icmp gives me nothing while pinging from the client.

Maybe I don't use that correctly...

Porfavorio

Sorry, had to use tcpdump -i any. Will get pack to this topic.

EDIT: The output is:

[IPOFCLIENT]: ICMP echo request, id 24385, seq 2995, length 64
[IPOFCLIENT]: ICMP echo request, id 24385, seq 917, length 64

Several times an output like this (because there are a few ping requests, I think).

I don't seem to get anything more in this context.

Could it then be that there has to be added a route on Ubuntu itself? In Network Manager? I don't have a router on site B.

openvpn_inc

Hello Por,

If site B has no router, how are its packets reaching the Internet? There is a router.

Yes, you can add routes on your client OS. In Linux, "ip route add network/NM via ip.add.re.ss" Note that munging your IP addresses prevented me from giving you a real answer. Why are you hiding RFC 1918 addresses?

Routes set on the client itself would have precedence over routes on its site router. But the "via" address must be directly reachable.

regards, rob0