Connect two different OpenVPN network?
-
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.0On 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.0That 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.
