remote access openvpn cannot access the remote site of the site-to-site openvpn setup
-
@bingo600
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.1
and
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
-
@bingo600
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 somewhereYou 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
-
@bingo600
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.
-
@divsys
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.
-
@divsys
Haha!
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!