[solved] Enabling communication between two openvpn instances
-
Hello all,
I successfully configured seven pfSense machines to create a site-to-site vpn using this howto: http://forum.pfsense.org/index.php/topic,12888.0.html
All the sites look like this:
| Site-to-Site VPN network: | 10.254.10.0/24 |
| Site A: | 192.168.100.0/24 |
| Site B: | 192.168.110.0/24 |
| Site C: | 192.168.120.0/24 |
| Site D: | 192.168.130.0/24 |…and so on.
All sites are able to ping and reach each other, everything fine with site-to-site so far.
Now I want my homeoffice users to connect to our main site using an additional openvpn server on the pfsense box of the main site.
The homeoffice server is configured like this:| Homeoffice VPN network: | 10.10.20.0/24 |
As a homeoffice VPN user I am able to connect to the openVPN server and I am able to ping the network of the main site, but I can not reach any of the other networks.
I ensured:
-
A Firewall rule allowing 10.10.20.0/24 to any LAN and OpenVPN network on all sites is enabled.
-
Routes are pushed via advanced config like "push "route 192.168.100.0 255.255.255.0"; and so on.
A traceroute a host on a specific site network the trace hangs directly after the first hop, which is my pfSense at the main site.
Because of that it seems to me those two tunnels are not routed properly. Does anyone have an idea on this? In case you need additional information, I'll be happy to provide it, didn't want to flood the post with useless information in the first place.Cheers,
toskala -
-
I suspect that your SiteA, SiteB etc offices do not know about the HomeOffice subnet - they have no route back to it. Add 10.10.20.0/24 to their client Remote Network/s field (that field is now a comma-separated list of remote networks).
Also, you do not need "push route" stuff any more in the Advanced box. You can do all that in the Loacl Network/s and Remote Networks/s fields by putting comma-separated lists of the networks that are reachable at the respective ends of the tunnel/s.
-
Hi Phil,
I suspect that your SiteA, SiteB etc offices do not know about the HomeOffice subnet - they have no route back to it. Add 10.10.20.0/24 to their client Remote Network/s field (that field is now a comma-separated list of remote networks).
You are right about the missing route, after checking the routing tables at the remote sites there is no route to 10.10.20.0/24. But I can't add something to the "Remote Network/s" field, since the site-to-site is configured as "Remote Access" type, so there is no such field.
Cheers,
toskala -
Phil, what you wrote helped a lot!
What I did is simply add the following two statements in the advanced field:
route 10.10.20.0 255.255.255.0;
push "route 10.10.20.0 255.255.255.0;This fixed it!
Thank you very much! :)
toskala -
route 10.10.20.0 255.255.255.0; push "route 10.10.20.0 255.255.255.0;
You don't need (or want) both statements, because it might one day mess something up at the other end, your client trying to push the route to the server at the other end. I think you just want at the client:
route 10.10.20.0 255.255.255.0;
which tells the client itself that this VPN is a route to 10.10.20.0/24
You should also be able to add 10.10.20.0/24 to the Local Network/s field at the server end - and that information will be pushed from the server to each client, so they get to know the server is a route to 10.10.20.0/24. That way removes any need to use the Advanced box.
But if it's working and you don't want to risk breaking it, then leave it as is!