Communication between clients from different OpenVPN networks
-
I have the following scenario
- There are 2 sites, one uses a Mikrotik, the other is a pfSense
- The pfSense box has 2 OpenVPN servers on it
- One OpenVPN server is used as a "site to site" connection, to allow hosts between
siteAandsiteBinteract with each other. That is, the Mikrotik acts as a VPN client with the respect to the server running on pfSense, the address the Mikrotik OpenVPN client gets in the pfSense OpenVPN network is10.0.14.2 - The other one (
OpenVPN2on the diagram) is used for allowing remote workers to connect tositeB. Once they connect, they can talk toHost1andHost2.
┌────────────────────┐ ┌──────────────────┐ │ 192.168.1.0/24 │ │ 192.168.13.0/24 │ │ Site A │ │ Site B │ │ │ │ ┌─────┐ │ │ │ 10.0.14.x │ │Host1│ │ │ ┌────┴──────┐openVPN┌───┴────────┐ └─────┘ │ │ ┌───────────┐ │ Mikrotik ├──────►│ pfSense │ │ │ │ Server │ │192.168.1.1│ │192.168.13.1│ ┌─────┐ │ │ │192.168.1.6│ └────┬──────┘ └───┬────────┘ │Host2│ │ │ └───────────┘ │ ▲ │ └─────┘ │ │ │ │ │ │ │ │ │ │ │ └────────────────────┘ │ └──────────────────┘ openVPN2 │ 10.0.13.x ┌────┴───┐ │ user │ └────────┘With this setup:
Host1andHost2can reachServerand vice-versausercan reachHost1andHost2
However,
usercannot accessServer- and therein lies the problem. How can this be accomplished?- In the tunnel settings for OpenVPN2 I set
IPv4 local networksto192.168.13.0/24, 192.168.1.0/24. - When
userconnects to OpenVPN2 its routing table is updated as follows:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 10.0.13.5 255.255.255.0 UG 0 0 0 tun0 192.168.3.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0 192.168.13.0 10.0.13.5 255.255.255.0 UG 0 0 0 tun0Nevertheless, I cannot ping any host in the
192.168.1.xnetwork, while traceroute tells me that it doesn't even attempt to reach the gateway, i.e.traceroute 192.168.1.6 traceroute to 192.168.1.6 (192.168.1.6), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * ...Is such a setup supposed to work, in principle? What troubleshooting methods can I use to understand the root cause of the problem?
-
@ralienpp said in Communication between clients from different OpenVPN networks:
However, user cannot access Server - and therein lies the problem. How can this be accomplished?
Possibly you're missing the route for 10.0.13.x on the Mikrotik?
-
@viragomann, if that were the case, wouldn't I at least see that the first step of the traceroute is an attempt to reach
10.0.13.5(the gateway for theOpenVPN2network)? -
@ralienpp
That depends on who the traceroute tool works.
The client has the correct route, so 10.0.13.5 should be the first hop anyway.Go on the Mikrotik and simply check the routing table to get further.
-
@viragomann, thank you for the follow-up. As I am not experienced with Mikrotik and I've inherited this system from someone else, I'd like to check one thing on a conceptual level.
If I go to its "Routes" UI it allows me to add entries of the form
dst->gateway. My understanding is that it is relative to the Mikrotik itself, so if I adddst=10.0.13.0/24, gateway=ovpnit means "packets going to 10.0.13.x should be sent via theovpninterface.I presumed you could mean that the pings from
usertoserverarrive, but the Mikrotik doesn't know how to send the response back - so I added a rule like the one above, and the problem persists.Just in case, I added a firewall rule on the Mikrotik saying that I allow traffic where
src=10.0.13.0/24 and dst=192.168.1.0/24, but the issue remains. -
@ralienpp
Since the gateway is an OpenVPN endpoint, this route should be managed by OpenVPN. But I assume, that won't make a different.
I have seen certain threads here people fighting to achieve similar set up with a Mikrotik OpenVPN endpoint. I'm also not experienced with it.But I assume, the connection sticks on the Mikrotik. You can verify by doing a packet capture. Yes, I think the request go over the site2site VPN, but no responds coming back.
However, as a workaround you could configure a masquerading rule on pfSense.
-
I ran a series of experiments and so far I've reached the point where I can confirm that the packets are indeed able to reach the Mikrotik side of the equation. Although I haven't solved the problem yet, I document what I did so others can follow:
- open a listening port on
serverwithnetcat -l -p 4200(choose a port number less likely to be used by others) - prepare the command
telnet 192.168.1.6 4200in the terminal ofuser, but do not yet execute it - in the Mikrotik UI go to Tools/Torch and set up a rule for
dst=192.168.1.6/32andport=4200forinterface=<name of openVPN interface>
Once the capture in the "Torch" tool is started, execute the command on
userand observe Mikrotik's output, you'll see some new entries on the screen that confirm that "the bullet really came out of pfSense and reached the Mikrotik".Now that the problem has been narrowed down, I'll investigate further and post another message when I've made progress. Until then, if anyone knows exactly which strings to pull and which buttons to click - I'd appreciate your help.
p.s. My attempts to use the packet sniffer tool in Mikrotik were not fruitful, and there's no
tcpdumpon it, so the Torch tool is what I managed to get by with in the end; perhaps this is not the best way. - open a listening port on
-
In a related experiment I configured the "Torch" tool to look for packets going in the other direction, so I set a filter for
src=192.168.1.6anddst=<IP address of 'user'>and observed that such traffic exists.Thus I conclude that Mikrotik is actually trying to reply, which brings the problem back to pfSense's side
-
@ralienpp said in Communication between clients from different OpenVPN networks:
Is such a setup supposed to work, in principle? What troubleshooting methods can I use to understand the root cause of the problem?
Your issue is strictly routing. The fact that VPNs are used is relevant, as when up, they simply provide an IP connection.
So, check your routes and make sure the various devices can find a route, either via default route or specific routes.
