remote access openvpn cannot access the remote site of the site-to-site openvpn setup
I have site-to-site openvpn connection working between site-A and site-B. Any server in site-A can access any server in site-B and vice-versa.
Since working from home, I also setup remote access openvpn to access site-A, which also works fine. That is, I can access any servers in site-A. However, I cannot access any servers in site-B while using remote access openvpn with site-A.
To be more specific, if I use remote access openvpn to connect site-A and log into any server in site-A, I certainly can access site-B from the servers in site-A. However, I was not able to access site-B servers directly from my laptop at home even with remote access openvpn connected with site-A.
I don't have clue how to debug this issue and please help to instruct me or let me know what information is needed for you to narrow down the issue. Thanks!
Your Client VPN Server (site A) probably doesn't announce site B's nets as remote.
You could force all traffic from the Client (PC) through site A
Done on the Site A , Client OpenVPN Server
That would force all traffic (including internet traffic) through the remote VPN Server , and since site A can access Site B , you should be able to do the same.
Note: That might limit access to local nets (home nets)
@bingo600 Thanks a lot for your reply. By Client VPN Sever, I assume you meant my remote access VPN server, and yes, I have already checked that box.
Here is the diagram and some additional info.
If I tracert a site-B server from a server in site-A, say 172.18.30.222, below is the routing:
172.18.2.254 (which is the pfsense server)
If I tracert the same site-B server from home, below I got
request time out (that's it)
please let me know your thoughts, thanks a lot in advance!!!
Could be that the Site B doesn't know the route to your "Dial In VPN" on A.
In the LAN A VPN server , you have to announce your 10.0.5.0/24 as a
Remote network , so Site B knows it is "behind A".
I see you are using a /24 topology in the Site2Site VPN , so i think that involves some "push" commands.
I'm always using a /30 topology for S2S , so i don't have any experience with those push's
To verify my theory ... (Missing route) on B
Do a Diagnostic --> Routes on Site B
And check if you have a route to 10.0.5.0/24 , i think it's missing.
You could do the same on Site A , where i expect it to be present , and route out via the "Dial IN VPN" interface
@bingo600 Thank you very much!!! I made it work following your suggestions with a little changes. I added 10.0.5.0/24 as a local network (as opposed to the remote network) to site2site openvpn server at site A and then I can access site B from home directly now.
However, I have a follow up problem as shown in the updated diagram below.
I actually also setup a remote access openvpn server at site-B too. Although it works for accessing servers in site-B, I can not access site-A servers directly from home as shown in the diagram below. I have already added 192.168.30.0/24 as remote network for site2site openvpn server. And in Diagnostic->Route of the site2site openvpn server, I can see destination 192.168.30.0/24 with 10.2.105.2 as gateway too. Any clues? Thanks.
Sorry about the local/remote route confusion ... Glad you got it to work.
Re Home-D Clients , that can't access Lan-A servers.
If you have done the "Force all ipv4" traffic , on the LanB (Client VPN) , the Client routing should be fine.
Server B (S2S VPN server)
You prob. have to set up 192.168.30.0/24 as OpenVPN local network on LAN-B Server , in order to get the LAN-A server to see it as "remote via B".
You have to check on Lan-A pfsense if it has a route to 192.168.30.0/24 via Openvpn interface (Lan-B)
I'm not sure when the OpenVPN routes gets annpounced , but i think on "start" , meaning you prob. have to "restart" your openvpn server(s) , where you have made any changes.
To be accurate, at site-B, it is not a S2S VPN server, it is a S2S VPN client. The S2S VPN server is at site-A. And the S2S VPN client setting doesn't have IPv4 Local networks. It has only IPv4 Remote networks. Below is a summary of my settings regarding to Local / Remote Networks.
For S2S VPN server at site-A:
Local networks(s): 10.0.5.0/24 in addition to LAN-A
Remote network(s): 192.168.30.0/24 in addition to LAN-B
For S2S VPN client at site-B:
Remote network(s): LAN-A
Local network(s): No such options in the settings
Please advice if I miss anything. Thanks.
That should work , but i'm not sure if those announcements work , now that you have made a /24 vpn topology.
What does diagnostics --> Routes say on SiteA , and on Site B ?
shouldmust be present in both routetables.
On A .... Via B (S2S VPN tunnel)
On B ... Via D (B's home client net)
But i think stephenw10 mentioned something about those "Remote networks" not working as expected in the VPN definitions , if not using a /30 topology.
There might be some hint here
I do assume you already have made sure there are no "blocked" entries in any of the firewalls ... AKA you have permitted the ip nets to communicate with each other.
diagnostics --> Routes looks good.
on A ... Via B (S2S VPN tunnel)
Destination of 192.168.30.0/24 has 10.2.105.2 as Gateway, which is also LAN-B's Gateway
on B ... Via D (B's home client net)
Destination of 192.168.30.0/24 has 192.168.30.2 as Gateway
Does it look reasonable for you? And no, I don't have blocked entries in the firewalls.
I do have trouble in understanding the linked article. It seems to be related to S2S OpenVPN connection and since my S2S OpenVPN connection is good, it doesn't seem to apply to my situation. Do I understand it correctly?
So it seems like your routes are in place.
You say you can ping from D to a Server on B , but not a server on A.
Can you ping from D:
This is very interesting.
on Site-B, diagnostic->routes shows that the Gateway for LAN-A subnet is 10.2.105.1.
I tried to ping 10.2.105.1 from Home-D so many times, it never worked.
I never ping 10.2.105.2 from D before. It actually works.
I thought from D the traffics have to go through 10.2.105.1 before reaching 10.2.105.2, I was seriously wrong then. Please advice. Thanks.
If you can't ping 10.2.105.1 (Site A OpenVPN interface) , from D.
Then something is "fishy" (like A doesn't know the correct route to D ... via B)
Can you ping (from A)
192.168.30.2 (if that is what your D client gets)
IP traffic always goes via "next hop" (what the route table points at)
A packet from D (192.168.30.2) to A goes (passes) ... Should pass
D -> B -> B -> A 192.168.30.2 -> 192.168.30.1 -> 10.2.105.2 -> 10.2.105.1
from site-A, I cannot ping either 192.168.30.1 or 192.168.30.2 (and yes, that is what the D client gets).
To summarize the experiments,
- when send traffic from D to A, it seems to lost at 10.2.105.1 as shown below (xxx means not working).
192.168.30.2 ----> 192.168.30.1 ----> 10.2.105.2 --xxx--> 10.2.105.1
- when send traffic from A to D (to be specific: tracert 192.168.30.1 from a server at A),
the packet seems not to go anywhere, just stopped at pfsense server.
But I do have site-A diagnostics->routes showing that for destination 192.168.30.0/24, the gateway is 10.2.105.2.
What do you think could be the issue? Thanks!
- when send traffic from D to A, it seems to lost at 10.2.105.1 as shown below (xxx means not working).
I think site A can not forward packets to 192.168.30.0/24
Or they are being blocked somewhere
You have previously written that the route looks good on A
on A ... Via B (S2S VPN tunnel) Destination of 192.168.30.0/24 has 10.2.105.2 as Gateway, which is also LAN-B's Gateway
And that you see no blocks in the firewalls.
So you have permitted all nets on the A-B OpenVPN interfaces.
Based on that "it should" work
I'm out of ideas here
Hello, I hope that you still remember this post. And thank you so much for your help. I have been debugging on and off and finally I believe I may find out the reason.
The root cause is that the iroute of the server A is not properly set. Even though, I encountered a problem and can't fix it. :(
Using GUI, I did create a Client Specific Overrides with 192.168.30.0/24. Somehow it doesn't work (a bug for pfsense 2.4.2-RELEASE-p1?). So I ssh as root/admin into the server A and try to modify the configure file under /var/etc/openvpn-csc/ using vi command to add 192.168.30.0. Even though I am the owner of the file and have the write permission. vi told me this is a read-only file when I was trying to save it and suggested to use :w!. I used :w! and was told the operation is not permitted. I am again out of idea now.
If you still understand my problem and have any suggestions, please let me know. Many thanks!
@be7taname I was looking back over this thread and didn't notice whether you're using
TLS/SSL or a PreSharedKey for your client-server connections. Are your OpenVPN Servers all running on pfSense boxes? I take it at least some of the clients are on PC'S/MAC's/etc?
As a general aside, what you're describing is not out of the ordinary at all and should be relatively straightforward. I have at least one site with a "central" OpenVPN server that also connects via clients to 7 other sites. If I connect via my laptop/phone/etc to the central site I get automatic access to the other sites as well. My setups are all TLS/SSL based but beyond the creation of certificates it is pretty cut and dried to setup.
@divsys A little further diagnostic device that may be helpful:
If you can fill in this table, it should give you pretty much everything you need to configure pfsense S2S and Remote Access servers via the GUI. I have never had to resort to anything on the command line side since 2.2+(??). The CSC info should only be needed for S2S server setups where there are multiple clients connecting. As I said earlier, this works very well from the GUI if you're methodical about setting it all up.
Thank you so much for your help! I have resolved the issue already.
You are correct and the entire setup is not out of the ordinary. As a matter of fact, I could make it work using other pfsense server/client pairs except this particular troublesome one describing in this post.
I found the reason for both why the CSC Overrides in GUI not working and why I cannot modify the configure file using command line. The particular file has been set the system immutable flag schg. Even the root cannot remove or modify the file, at least not until you clear the flag. After removing the flag, everything finally works as expected.
Again, thank you so much for your kind help! @divsys
@be7taname I've never had to climb "under the hood" with this stuff for a long time now, makes me a little suspicious that something else has been mangled in your whole process.
Personally, I'd consider wiping the Server/Clients on pfsense and building new ones from scratch to eliminate possible left over muck from giving you grief down the road. At least think about creating new Server/Client sets in parallel with the existing ones and do a switch over. The GUI installs of this stuff have been clean for a long time now.
Anyhow, I know you're probably thinking "But it WORKS I'm not touching it!" (I would too...)
Just my $.02
Glad you're up and running.
And you are right again. I am not touching it. It works now and I need a break from it. ^_^
Thank you for your advice. It is a valid concern. I left the part not saying why the flag was there at the first place since the entire thing is all my fault. I added it upon suggestions from others and then I forgot. I am pretty sure that this is the only thing I messed up under the hood.
Really appreciate your consideration!