Running two OpenVPN servers on the same pfsense box. Is that okay?
-
My bad. the 25 instead of 255 was a typo and I checked and my push does have the right syntax.
So, I see that the Static routes are to connect to another router and won't help my purpose.
I see in Diagnostic > Routes that route is generated fine but "route PRINT" on the Windows actually doesn't show the route on it so the client can't ping the other side. Or in this instance I could be wrong and there is no need for the Windows client to actually have the other sides subnet on it's route list but rather it would be able to still send all packets to the router for processing which seems to not work at the moment.
I am still stuck why the clients on both sides can't ping each other while the two pfSense routers can ping each other fine.
Thanks
-
I dont have much experience with OpenVPN using PKI (I will be experimenting over the weekend)
Since this is a site-site VPN, the clients may not have the routes, when they try to access a network outside the LAN they contact their default gateway, which would route it over the VPN/Internet connection transparently to them.
How does the windows client connect? (must connect from outside either network to work, if its a client internal on one of the networks, try just pinging without having it connect itself).Could be a rule issue.
-
I am connecting from outside with the Windows client and that works fine as it's only the client to server and not client to client which is what I have problem with. Also remember that connection does get connected as I can see in Diagnostic > Routes and the tunnel comes UP but from there on it's not working with pinging Client To Client. I think I am getting closer to the source of the problem. And I don't think it's related to PKI or PSK method.
Using either method, if I try to ping the first tunnel subnet address on the OpenVPN Server pfsense (know as the OpenVPN Server box per the pfSense book), the router freezes and it's GUI freezes. I still have access to SSH so I can restart and all works fine (Webconfigurator restart doesn't work). I did shell access and tried pinging and the network wasn't reachable.
Here is results of the ping with OpenVPN setup in PSK mode (***I had to CTRL+C after the ping command as it would not fail or ping which I thought was odd as well - And it just clicked to me that that is why my pfsense Web Interface freezes because the ping doesn't return anything - I am now taking this as a bug in the ping as it should timeout regardless of the response it gets):
tun1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500 inet6 fe80::20d:b9ff:fe1f:da54%tun1 prefixlen 64 scopeid 0x9 inet 172.31.50.1 --> 172.31.50.2 netmask 0xffffffff Opened by PID 22147 [1.2.3-RELEASE] [root@alix-red.local]/root(10): ping 172.31.50.1 PING 172.31.50.1 (172.31.50.1): 56 data bytes ^C --- 172.31.50.1 ping statistics --- 105 packets transmitted, 0 packets received, 100.0% packet loss [1.2.3-RELEASE] [root@alix-red.local]/root(11): ping 172.31.50.2 PING 172.31.50.2 (172.31.50.2): 56 data bytes ^C --- 172.31.50.2 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss [1.2.3-RELEASE] [root@alix-red.local]/root(12): ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 56 data bytes ^C --- 192.168.2.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss [1.2.3-RELEASE]</up,pointopoint,running,multicast>
Anything else comes to your mind?
Regards,
-
IF one of the boxes is freezing like you say and you have to reboot it, makes me think theres a hardware/cooling issue.
the PING command in *nix machines will go forever as if you did the -t command in windows.so thats normal.If your using 2.0, know that its still in beta and this could be a bug.
What happens when you ping the other boxes WAN IP?
I am not sure exactly what the issue is though.
-
1- It's not a cooling issue. Even ping -t gives back a time out response but when I do ping either on SHELL or through the GUI it doesn't return ANY value and that is exactly why the GUI freezes for ever. This is a bug!
2- The issue I am experiencing is Client To Client not being able to reach each other. That is there are two pfsense routers and there are two differently numbered subnets behind each pfsense router. Both routers are connected in PSK or PKI method and the ping only happens between pfsense to pfsense but not client to client or client to the other pfsense.
Thanks
-
try setting them as your default gateway for a few clients, if the issue goes away its your main router.
-
Thanks for the input. I am not sure what you mean and how to do it.
However, the ping should not be stuck no matter what mis-configuration there is.
-
the ping will fail on the computers in the LAN as their default gateway has no route to the network. But if from a shell (ssh or local) the ping fails then it is a VPN issue.
Is the VPN is seen as being up on the pfSense boxes?
Could be your PKI, if you dont know how to edit a route on your main gateway, I would suggest setting up a PSK setup first, then do a ping on one box to the other. -
Sorry, it seems that my point doesn't come across clearly.
The tunnel shows up. All my tests are done on the pfsense box rather than any clients. The pfsense box SHELL (option 8) freezes when I issue command ping to ping the client VPN side IP address. Hence, the GUI Diagnostic > Command section freezes the whole GUI because again the ping itself freezes. If it's unreachable I agree that it's my settings fault. But regardless of what the fault may be the behavior of ping command is not right. Ping should have a timeout to it that should show FAILS or Packet Received. Unless it's different on FreeBSD, all other OSs I worked with do have a timeout to ping. If this is normal behavior for FreeBSD then my assumption of it being a bug is not right.
-
since the system is locking up whenever you try to do a ping, does this happen on both systems? If you can redownload and reinstall.
-
It happens on both. I have re-downloaded and re-installed and re-did configurations from scratch and I end up the same place again. :'(