Clients cannot communicate with each other.
-
Actually, I think what I just wrote isn't going to work. If traffic originates in HQ it will not know the proper tunnel to go through if sending traffic to a branch office.
-
So what is the solution?
-
You might need to switch to SSL/TLS instead of pre-shared key and use Client Specific Overrides:
https://forum.netgate.com/topic/126091/openvpn-site-to-site-multisite -
I understand. Thank you.
-
@yumcheese said in Clients cannot communicate with each other.:
You might need to switch to SSL/TLS instead of pre-shared key and use Client Specific Overrides:
https://forum.netgate.com/topic/126091/openvpn-site-to-site-multisiteNope you don't. We have many clients that we do support for, that are using shared-key tunnels from OpenVPN just fine. There's something other missing here. The tunnel itself shouldn't be a problem. For the problem of Site A not being able to Ping Site B and vice versa I'd check the following steps:
- are there rules on the OVPN interface tabs active on any site?
- check routes on HQ and Sites A/B and check if all Sites actually have all required routes set and if the gateways are right.
- check your NAT settings so your VPN tunnel won't get accidentally NATted when it shouldn't
Greets
-
"all required routes"? Are you referring to static routes?
-
@scilek said in Clients cannot communicate with each other.:
"all required routes"? Are you referring to static routes?
Yes, your OVPN configuration as you described in the OP should take care of them and both remote networks (in every location) should show in your system routing table (diagonstics / routes) with the OVPNx interface as Gateway
-
I tried that too, but it did not work. Maybe I was not able to get the hang of it. Could you kindly give an example of a static route entry for the HQ router?
-
@scilek said in Clients cannot communicate with each other.:
I tried that too, but it did not work. Maybe I was not able to get the hang of it. Could you kindly give an example of a static route entry for the HQ router?
You tried what? Just have a look into Diagnostics/Routes. If your VPN config is right, there should be routes. Can you show that?
Otherwise as you didn't post any configuration, I can only guess, but as you have to shared key tunnels, you should probably have two OVPN servers defined in your HQ config, so there should be something like ovpns1 and ovpns2 in your routing table. Something along the lines of
172.16.1.1/24 10.0.0.1 UGS 4273856 1500 ovpns1 172.16.2.1/24 10.0.1.1 UGS 4273856 1500 ovpns2 -
I see... I have already taken care of the issue by creating a mesh network among the routers. Each router is a server to all others. But I will have another go at it when I get the chance.
-
on HQ ssh in select option 8 and run "netstat -rn -f inet |grep -i tap" It may be tun in place of tap I don't remember off the top of my head. Anyway that should show you if the vpn networks have routing table entries that use the tun interface. If that doesn't show anything you need to go back and make sure your openvpn config is correct.
Remember the vpn networks routing entries need to use the tunnel interface. Or have a next hop ip address of the far end of the vpn tunnel. They won't be routed correctly if the exit interface isn't the tunnel.
-
@scilek said in Clients cannot communicate with each other.:
I have already taken care of the issue by creating a mesh network among the routers.
With OpenVPN? What did you set up?
Each router is a server to all others. But I will have another go at it when I get the chance.
That sounds nothing like a typical OVPN setup?
-
First I set up an OpenVPN [Remote Access (SSL/TSL)] server on each of the routers. Then I created two clients to the other routers. Now I can ping any client from any other. It took me about an hour to get it working. Do you happen to know a good tutorial that explains and exemplifies all this?
-
I have found something that might be a clue to what goes wrong. In the "OpenVPN" tab of my system logs, I found this entry:
ERROR: FreeBSD route add command failed: external program exited with error status: 1It seems that for some reason FreeBSD refuses to add the new route. I took care of the problem by adding the routes manually. But why does this happen? Does anyone have any idea why? What is the solution?
NB: Took care of the problem by creating static routes to LANs.
-
@scilek
I've seen the FreeBSD route add command failed error before also. I think in my situation, it was related to it trying to add the same route twice. I had to look above in the log to see the same route numbers added twice. I think I had something in Client Specific Overrides that duplicated some other setting elsewhere. -
@yumcheese
I hope the issue will be solved in the next version. -
@scilek said in Clients cannot communicate with each other.:
First I set up an OpenVPN [Remote Access (SSL/TSL)] server on each of the routers. Then I created two clients to the other routers. Now I can ping any client from any other. It took me about an hour to get it working. Do you happen to know a good tutorial that explains and exemplifies all this?
Huh? You made one server on every router with two clients to every other server? How is that supposed to work? Doesn't make any sense to me. Per your logic you have:
- HQ: One server, two clients to Site A and B
- Site A: One server (with connection from site B and HQ) but ALSO two clients TO HQ and side B?
- see above
That logic makes no sense at all and isn't anything like a "Mesh".
The simple way to do what you described in your OP would be:
- Check which site (A/B) has the bigger or more stable connection
- HQ: create two shared keys OVPN site2site VPN servers
- Site A: create a client S2S with the shared key from HQ's ovpns1 connection
- Site A: create a server for connection with Side B, again shared key S2S setup like the two in HQ
- Site B: create two clients S2S, one with HQ, one with Site A's server.
Now you've got your triangle complete. If you don't need SiteA-SiteB interconnect but want to route it through HQ, you can skip the server/client setup between Site A and B, just add the appropriate routes to the HQ tunnel and be done (but keep in mind your HQ line will get the traffic twice, inbound and outbound if you have traffic from A to B).
That's it. Simple and smooth. Setups with RemoteAccess Setup are more complicated as the routes must be mapped to the appropriate client, interface etc. because RA server type isn't a 1:1 Site2Site connection with clear endpoints. So you're making your life harder than it has to. I've got clients running setups like this with around two dozens of remote offices and sites around the globe, some only to HQ, some with each other without any problems. So nothing that "has to be fixed in the next version". Just use the tools at hand the way they work :)
-
Actually, I figured out that the reason why my original setup had failed was because there is something wrong with the pfSense 2.4.4_p3 OpenVPN tab; it won't just create the necessary routes as defined in the configuration; or maybe something wrong the FreeBSD route creation command. I solved the problem by creating static routes and now my hub-and-spoke topology works fine. Thanks for the advice, though. Appreciated...
-
@scilek said in Clients cannot communicate with each other.:
because there is something wrong with the pfSense 2.4.4_p3 OpenVPN tab; it won't just create the necessary routes as defined in the configuration; or maybe something wrong the FreeBSD route creation command. I solved the problem by creating static routes and now my hub-and-spoke topology works fine. Thanks for the advice, though. Appreciated...
I'm telling you that either pfSense or FreeBSD do route creation with OpenVPN just fine. And I could post several configurations from our clients (if I were free to do so) doing what you'd like to do in your first post without any problems with route creation at all. So as I have multiple clients running multi-site-to-site tunnels without a hitch, I'm leaning towards saying "you have an error in your configuration". But as long as you don't post anything to help, that's as far as we can come. You say you set it up right and pfsense has some sort of routing bug. I claim multiple clients of our company running dozens of site2site tunnels even in mesh/web-like configurations without any routing problems so the error would be somewhere in your setup. So I agree to disagree ;)
If you'd like to solve your problem - help us find the error. If you'd like to manually set routes that should be set up automatically if configured the right way - feel free. But that make break the next time you change your setup in any way or perhaps with a future update of OVPN in pfSense. :)
-
I did exactly as I explained in my original post and it did not work. I followed the example demonstrated by the Youtuber but what worked for him failed for me. I don't mind the administrative overhead.
