Connect two different OpenVPN network?
-
Is it possible to make visible one two the other, the clients of two differnet OpenVPN connected networks? I try to explain: in my office (192.168.10.0/24) I've a pfSense with two OpenVPN Server, one for road warrior clients (single Mac's that connect using Tunnelblick 10.0.8.0/24) and another for Peer to Peer connections (10.0.7.0/24). The two server uses two differnet ports 1194, 1195, and now they work perfectly. The problem is that sometime I need to reverse access the road warrior clients form the peer to peer client (my small home office 192.168.17.0/24). I tried to add to the road warrior OpenVPN Server the push "route 10.0.8.0 255.255.255.0", but it seems it didn't have any effect, and if I try to traceroute to a road warrior client, route loses the way somewhere outside my router. So:
traceroute to 10.0.8.5 (10.0.8.5), 64 hops max, 52 byte packets 1 pfsense.abs.lan (192.168.17.1) 0.451 ms 0.462 ms 0.306 ms 2 192.168.1.1 (192.168.1.1) 0.918 ms 1.014 ms 0.772 ms 3 * * * 4 * * *
If I trace to an office client, I get this (without passing my home router 192.168.1.1):
traceroute to 192.168.10.100 (192.168.10.100), 64 hops max, 52 byte packets 1 pfsense.abs.lan (192.168.17.1) 0.400 ms 0.355 ms 0.240 ms 2 10.0.7.1 (10.0.7.1) 61.594 ms 60.735 ms 60.667 ms 3 server.sta.lan (192.168.10.100) 64.949 ms 61.571 ms 60.828 ms
Can I make some configuration to have something like this?
traceroute to 10.0.8.5 (10.0.8.5) 1 pfsense.abs.lan (192.168.17.1) 2 10.0.7.1 (10.0.7.1) 3 10.0.8.1 (10.0.8.1) 4 10.0.8.5 (10.0.8.5)
-
That should work fine as long as proper routes are pushed to both clients.
-
That should work fine as long as proper routes are pushed to both clients.
Is what I did, at this time, but things didn't change… I add config screenshot, maybe there's something that escapes me.
And I noticed another strange thing: from my home-office (client peer-to-peer), many times I can't use the office SMTP server (mail didn'd have response from server), even I can ping and trace route to it. Mostly it happens with heavy attachments, but if I disconnect pfSense OpenVPN, and connect with Tunnelblick (software client) from my Mac (to roadwarrior server), it works flawless.
![pfSense OpenVPN Peer to Peer Client.png](/public/imported_attachments/1/pfSense OpenVPN Peer to Peer Client.png)
![pfSense OpenVPN Peer to Peer Client.png_thumb](/public/imported_attachments/1/pfSense OpenVPN Peer to Peer Client.png_thumb)
![pfSense OpenVPN Peer to Peer Server.png](/public/imported_attachments/1/pfSense OpenVPN Peer to Peer Server.png)
![pfSense OpenVPN Peer to Peer Server.png_thumb](/public/imported_attachments/1/pfSense OpenVPN Peer to Peer Server.png_thumb)
![pfSense OpenVPN Peer to Peer Server.png](/public/imported_attachments/1/pfSense OpenVPN Peer to Peer Server.png)
![pfSense OpenVPN Peer to Peer Server.png_thumb](/public/imported_attachments/1/pfSense OpenVPN Peer to Peer Server.png_thumb) -
Shared key mode doesn't "push" routes - it just has normal route statements. The "push" statement only works on SSL/TLS server instances.
-
Shared key mode doesn't "push" routes - it just has normal route statements. The "push" statement only works on SSL/TLS server instances.
OK, and in this case what do you suggest? Should I go to SSL/TLS for Peer-to-Peer VPN too, or what other? I used Shared key because it seemed more reliable, but now I discovered that the cause of many problems was the office router, should I turn back to SSL/TLS?
-
Keep what you have, just use route statements, not push route statements.
-
Keep what you have, just use route statements, not push route statements.
Sorry, I tried and googled, but I was not able to setup the thing. Can you explain which are the right commands on client and server site?
-
Perhaps I didn't get the routing all clear, it would be better if you had a diagram with IPs and such.
If I'm reading it right:
On the peer-to-peer client, add:
route 192.168.8.0 255.255.255.0
On the peer-to-peer server, remove the push there.
On the server for the tunnelblick clients, if it's PKI, add this to the server:
push "route 192.168.17.0 255.255.255.0"
If that's shared key, you'll need to add this to the client config config in tunnelblick:
route 192.168.17.0 255.255.255.0
That should allow the tunnelblick clients to reach the network at the peer-to-peer client site.
-
Perhaps I didn't get the routing all clear, it would be better if you had a diagram with IPs and such.
192.168.17.x – computer from which I would admin
192.168.17.1/10.0.7.2 -- firewall pfSense OpenVPN Client
#tunnel OpenVPN 1# -- PSK
10.0.7.1/192.168.10.1/10.0.8.1 -- firewall pfSense OpenVPN Server
#tunnel OpenVPN 2# -- SSL/TLS
10.0.8.y -- software client (road warrior) to adminP.S. I tried your suggestion, even with some adjustment, but didn't work.
-
You might need to check the routing table at each leg, and do packet captures in each direction, to figure out where the traffic is or isn't going like it should.
The only thing that wouldn't work with just routes, is if you're trying to reach a network behind a SSL/TLS client, then you might also need iroutes.
-
The only thing that wouldn't work with just routes, is if you're trying to reach a network behind a SSL/TLS client, then you might also need iroutes.
Since I am trying to administer a 10.0.8.y client from 192.168.17.x network (through both VPN), I think I'm in the case above. I'll give a look to iroute command.
But what about bringing both VPN's to SSL/TLS? I guess it can be better bringing both too use PSK, but since I've more clients on SSL/TLS to setup, I prefer to avoid this way. -
You can use SSL/TLS everywhere if you want, it's just a little more overhead to setup.
http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29
-
You can use SSL/TLS everywhere if you want, it's just a little more overhead to setup.
OK, but will this simplify the route setup?! The goal is not to use SSL/TLS over PSK or viceversa, but it is to admin the clients of a VPN form the LAN connected over another OpenVPN tunnel. Any suggestion to solve this problem is welcome… Any other is good for my, and maybe others, knowledge.
-
It won't simplify it, the routing on PSK is much simpler than SSL/TLS. The rest is a matter of preference.