<![CDATA[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 siteA and siteB interact 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 is 10.0.14.2
  • The other one ( OpenVPN2 on the diagram) is used for allowing remote workers to connect to siteB. Once they connect, they can talk to Host1 and Host2.
 ┌────────────────────┐                  ┌──────────────────┐
 │    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:

  • Host1 and Host2 can reach Server and vice-versa
  • user can reach Host1 and Host2

However, user cannot access Server - and therein lies the problem. How can this be accomplished?

  • In the tunnel settings for OpenVPN2 I set IPv4 local networks to 192.168.13.0/24, 192.168.1.0/24.
  • When user connects 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 tun0

Nevertheless, I cannot ping any host in the 192.168.1.x network, 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?

]]>https://forum.netgate.com/topic/166753/communication-between-clients-from-different-openvpn-networksRSS for NodeFri, 12 Jun 2026 18:08:31 GMTFri, 24 Sep 2021 12:33:54 GMT60<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 01 Oct 2021 15:25:26 GMT]]>@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.

]]>https://forum.netgate.com/post/1003997https://forum.netgate.com/post/1003997Fri, 01 Oct 2021 15:25:26 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 01 Oct 2021 12:59:22 GMT]]>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.6 and dst=<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 🤷

]]>https://forum.netgate.com/post/1003968https://forum.netgate.com/post/1003968Fri, 01 Oct 2021 12:59:22 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 01 Oct 2021 10:32:48 GMT]]>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:

  1. open a listening port on server with netcat -l -p 4200 (choose a port number less likely to be used by others)
  2. prepare the command telnet 192.168.1.6 4200 in the terminal of user, but do not yet execute it
  3. in the Mikrotik UI go to Tools/Torch and set up a rule for dst=192.168.1.6/32 and port=4200 for interface=<name of openVPN interface>

Once the capture in the "Torch" tool is started, execute the command on user and 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 tcpdump on it, so the Torch tool is what I managed to get by with in the end; perhaps this is not the best way.

]]>https://forum.netgate.com/post/1003944https://forum.netgate.com/post/1003944Fri, 01 Oct 2021 10:32:48 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 24 Sep 2021 15:13:16 GMT]]>@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.

]]>https://forum.netgate.com/post/1003005https://forum.netgate.com/post/1003005Fri, 24 Sep 2021 15:13:16 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 24 Sep 2021 14:58:01 GMT]]>@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 add dst=10.0.13.0/24, gateway=ovpn it means "packets going to 10.0.13.x should be sent via the ovpn interface.

I presumed you could mean that the pings from user to server arrive, 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.

]]>https://forum.netgate.com/post/1003000https://forum.netgate.com/post/1003000Fri, 24 Sep 2021 14:58:01 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 24 Sep 2021 13:12:29 GMT]]>@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.

]]>https://forum.netgate.com/post/1002985https://forum.netgate.com/post/1002985Fri, 24 Sep 2021 13:12:29 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 24 Sep 2021 12:56:05 GMT]]>@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 the OpenVPN2 network)?

]]>https://forum.netgate.com/post/1002981https://forum.netgate.com/post/1002981Fri, 24 Sep 2021 12:56:05 GMT<![CDATA[Reply to Communication between clients from different OpenVPN networks on Fri, 24 Sep 2021 12:43:12 GMT]]>@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?

]]>https://forum.netgate.com/post/1002980https://forum.netgate.com/post/1002980Fri, 24 Sep 2021 12:43:12 GMT