[SOLVED]cant ping from server pfsense to client pfsense. Routes in both sides!
I have spent lots of hours reading and trying to setup the following, after all these I am able to see the routes in both client pfsense and server pfsense, but still cannot ping from server to client..! Firewall rules are OK for all interfaces. permitting everything.
You can find below the configuration. Any help would be very appreciated.
Maybe am I missing something in Outbound RUles in NAT part? As far as I could understand there was a need to assign a new interface for openvsdfpnc1() named OPT1. But I do not understand there what is the difference of the OpenVPN selection and OPT1 interface which is related to the openvpn interface actually..
Actually I have something like this: https://community.openvpn.net/openvpn/wiki/RoutedLans
and I do not get why ping is working from clients to the server but not from server to the clients and clients themselves, as the routing table shows that the routes are there.. Server LAN in my case is 172.31.89.0/24 , client1 is 172.31.87.0/24 and client2 172.31.88.0/24
So for example from client1 ping 172.31.89.200 works (.200 is the server's interface) but from server ping 172.31.87.200 (client pfsense interface) does not work . And client-to-client also ..
Client additional conf:
I am not attaching client2 conf as it is similar to client1.
Please could you help!! ::) :) 8)
The first thing that looks a little odd is the:
iroute 172.31.87.0 255.255.255.0
It's not clear where that line appears. It must be in the "Client Specific Configuration" section on the Server only.
The various "route" commands in the Server config specify what possible external traffic will be handled, the "iroute" command appears for the particular client that needs that traffic.
You must create a separate CSC for each client and the name must match exactly with the client's CN in the certificate.
You can see the name if you look in "Status->System Logs->OpenVPN", you'll see the name as each client connects.
"xxx.xxx.xxx.xxx:41797 [astone-divsys-s2s-crt] Peer Connection Initiated with [AF_INET]
Where "astone-divsys-s2s-crt" is the CN created in the certificate. You can also find it by checking the Certificate Manager for the appropriate names. Just watch out for leading and trailing spaces if you cut and paste the name (I still get burned by that one from time to time).
As far as Firewall->Rules and NAT the only main requirement is an "Allow ALL" Rule on the OpenVPN tab. There is no need in general for anything under Firewall NAT if you're setting up the server on the WAN NIC. The rule to allow access to the appropriate WAN port looks like it's there and working since the clients do seem to connect.
The last major gotcha is to make sure the devices on each Lan will actually respond to pings from another network. Windows machines are notorious for firewalling pings from other subnets.
divsys really thank you! I was not aware of this thing related to the namings, thanks a lot!
I am pinging from the pfsense clients so no windows is used in this part. Now ping works from server to clients, but pinging from one client to the server stopped responding. pinging from the other client to server works normally.
Also client-to-client is not still working, maybe it is related to the problem above.
I think I am close to the end, a final ingredient is missing… ! :)
the configuration now is as below:
client1csc (on server)
Actually I do not understand why pfsense has autogenerated ifconfig-push 192.168.244.2 192.168.244.1 on both client specific overrides.
So both clients have assigned the same VPN address??
Yes, it seems that for the last part, that was exactly the problem. On one of the two client specific overrides , I manually added ifconfig-push 192.168.244.3 192.168.244.1.
The other one was not changed, it has only the iroute statement. So it seems that pfsense generated a rule for automatically allocating the same ip for both clients and that was causing a conflict.
This could be a bug ? I am using the latest version, 2.1.5-RELEASE (amd64)
built on Mon Aug 25 07:44:45 EDT 2014
Now it worked like a charm! Thanks divsys, you are my hero! Without your help I would spent lots of hours more I think!
Now this is a new problem.. in every client, although I not enter it by my self, in the corresponding csc file, the server is adding
"ifconfig-push 192.168.244.2 192.168.244.1"
This is creating conflicts, I was expecting that a new ip address would be allocated to each one of the clients..
How this can be solved? Is this a bug or am I missing something?
The second thing I would do is to create separate certificates for each client and name them differently.
You currently showing Client1 and Client2 as using the same certificates and configuration file.
Reusing the same certificate is valid, although I prefer to create a new cert for each client to keep things segregated. In your case, if you don't use a different certificate, the Server won't know that a different iroute subnet is required for Client2. It only matches on the certificate CN which you have as the same for both clients.
Create a second certificate for Client2 with a new CN and update your CSC section accordingly and see if that doesn't clean up the issue for the 2nd client.
Don't worry too much about the tunnel subnet stuff. OpenVPN in general does a good job of allocating what it needs to make the connections work. I would solve the cert issue first.
BTW, you're doing fine if this is your first foray into OpenVPN's.
It feels just like the first time I started mucking about with this stuff.
You cause more problems than you solve for a while until finally - it works ;)
Yes it is my first time in OpenVPN but I have quite experience in routing , linux admin stuff and also I there are nice guys that are helping when you are stuck ! :)
I have already done this part related to the different certificates, but I needed also to export some client configurations to give them to my colleagues, so some additional windows clients will be connected and there is a certificate especially for them.
finally I solved this problem by just removing manually the extra line ifconfig-push that is added when you click save in the additional client crc tab. This is added only when you click save, after configuring some push routes there was no need for additional modification, so I just removed the line and in this way it never overwritten (if you click save you must do it again).
No works perfectly normal, as expected!
Thanks again, problem solved..
Glad to hear you got it going.
I know the Wizard simplify's the task of getting a link up and running, but I can honestly say I've never used it in setting up OpenVPN.
I started back in the ver 1.2 days of pfSense, well before Wizards and Certificate Managers and I guess I just learned the "manual" method through much the same trial and error as you're going through now. In the end I find setting up a tunnel by hand is just as fast as the Wizard for me and I don't get "unwanted extras" added in the config files.
Just my $.02, YMMV :)
Thanks again divsys, you really saved me lot of time!