SG1100: routes seem correct, but not working
-
I have two instances of a pfSense OpenVPN client running on a netgate SG1100. Each client is connected to a different pfSense OpenVPN Server. Both server instances are each running on a different netgate SG1100. The client (Z) can access local IP on one of the servers (X) correctly, but not the other server (Y), despite the routes (shown further below) appearing to be setup in the same manner. Here is the network configuration:
Pfsense OpenVPN Server Tunnel pfsense OpenVPN Client 10.55.83.0/24 OpenVPN Server X VPN Tunnel 10.55.201.0/24 192.168.2.0/24 OpenVPN Client Z pfSense router LAN IP: 10.55.83.10 pfSense router LAN IP: 192.168.2.1 10.55.73.0/24 OpenVPN Server Y VPN Tunnel 10.55.203.0/24 192.168.2.0/24 OpenVPN Client Z pfSense router LAN IP: 10.55.73.10 pfSense router LAN IP: 192.168.2.1Working as expected: On Client Z, I can ping the Server X router at 10.55.83.10, and access other local IPs on the server X side (EX: 10.55.83.192). On client Z, when I do a traceroute to a server X side local IP, I see that the first hop is 192.168.2.1, and the second hop is 10.55.201.1
Not Working as expected: From Client Z, I can ping the Server Y router at 10.55.73.10, but can not successfully ping or access other local IPs on the Server Y side. The applicable routes are shown below. Everything looks correct, and I’m not seeing what could be different that is causing access to local X IP to work, but not access to local Y IP (other than the Y pfSense router local IP). Any help is much appreciated.
Applicable OpenVPN Client Z routes :
10.55.73.0/24 10.55.203.1 UGS 15 1500 ovpnc3 10.55.203.0/24 link#15 U 13 1500 ovpnc3 10.55.203.250 link#7 UHS 14 16384 lo0 10.55.83.0/24 10.55.201.1 UGS 12 1500 ovpnc1 10.55.201.0/24 link#14 U 10 1500 ovpnc1 10.55.201.250 link#7 UHS 11 16384 lo0 -
@wmcneil said in SG1100: routes seem correct, but not working:
From Client Z, I can ping the Server Y router at 10.55.73.10, but can not successfully ping or access other local IPs on the Server Y side.
Even from the client router itself or from devices behind it?
Is Z the default gateway in the remote network?
-
@viragomann said in SG1100: routes seem correct, but not working:
@wmcneil said in SG1100: routes seem correct, but not working:
From Client Z, I can ping the Server Y router at 10.55.73.10, but can not successfully ping or access other local IPs on the Server Y side.
Even from the client router itself or from devices behind it?
A traceroute from either the Client Z local pfSense router(192.168.2.1), or another 192.168.2.xxx client, to Server Y client 10.55.73.191 reports the first two hops as follows, then times out on subsequent hops:
1 10.55.203.1 (10.55.203.1) 35.639 ms 33.945 ms 32.847 ms
2 10.55.73.191 (10.55.73.190) 28.918 ms 31.699 ms 36.744 msDespite this, I can not reach 10.55.73.191 with Remote Desktop Connection from a 192.168.2.xxx client. (The same scenario from the same 192.168.2.xxx client to server X client 10.55.83.192 does work for remote desktop connection)
Is Z the default gateway in the remote network?
yes:
Default Gateway . . . . . . . . . : fe80::f2ad:4eff:fe1e:87c8%10
192.168.2.1 -
I realized the server Y client I was using in the scenario above is not actually capable of responding to a ping, so I switched to a different Y client(10.55.73.193) which is capable. I am still not reaching the Y client from the Z windows client, but the results of traceroute indicate I may be reaching it from the Z pfsense router():
traceroute from Z pfSense router(192.168.2.1) to Y client 10.55.73.193:
1 10.55.203.1 (10.55.203.1) 29.594 ms 31.028 ms 32.122 ms 2 10.55.73.193 (10.55.73.193) 63.680 ms 33.712 ms 34.563 ms 3 10.55.73.193 (10.55.73.193) 34.344 ms 28.973 ms 34.907 mstracert from Z windows client (192.168.2.135) to Y client 10.55.73.193:
1 1 ms <1 ms <1 ms cabin_pfSense.localdomain [192.168.2.1] 2 33 ms 31 ms 39 ms 10.55.203.1 3 * * * Request timed out.The traceroute from the Z pfSense router is not timing out (max number of hops is set to 5, and it is reaching the target on hop2 (and hop3), so it appears to be reaching the target. I don't know why the traceroute shows the Y client being reached in both hops 2 and 3 (why is it not stopping after hop2)?
Given the routes listed further above, I don't understand why the tracert from the Z windows client is not reaching the target. The first two hops are as expected, and consistent with the routes shown in the posts further above.
-
@wmcneil
Does the remote device allow the access?Did you configure a CSO for the client?
-
@viragomann said in SG1100: routes seem correct, but not working:
@wmcneil
Does the remote device allow the access?Yes. If I connect the Z client (192.168.2.135) via a different OpenVPN client (use Windows OpenVPN client connected via cell phone network instead of via the Z pfsense OpenVPN client), everything works. Note that in this case I am still using the Y pfsense OpenVPN Server.
Did you configure a CSO for the client?
I do have a CSO on the Y OpenVPN server side that allows Y clients to access the Z OpenVPN client local IP network, and this access is working. I'm not understanding why this is relevant? (My problem is the opposite direction: OpenVPN client side (Z) access to OpenVPN server side (Y) local IP, and CSO is not used for that direction, unless I do not understand something?)
-
@wmcneil said in SG1100: routes seem correct, but not working:
I do have a CSO on the Y OpenVPN server side that allows Y clients to access the Z OpenVPN client local IP network, and this access is working.
You didn't mention that before.
I'm not understanding why this is relevant? (My problem is the opposite direction: OpenVPN client side (Z) access to OpenVPN server side (Y) local IP, and CSO is not used for that direction, unless I do not understand something?)
Yes, for accessing the remote site from devices behind the Y router, the CSO is necessary though. And this is, where you have issues according to your posts.
The CSO not needed for access from the client itself, which obviously works.But if you can access devices behind the Y router from Z local network, the CSO should be applied properly.
Then the only thing I get into mind is, that there is something wrong with the routes at Y, but need to see the whole routing table.
-
@viragomann said in SG1100: routes seem correct, but not working:
@wmcneil said in SG1100: routes seem correct, but not working:
I do have a CSO on the Y OpenVPN server side that allows Y clients to access the Z OpenVPN client local IP network, and this access is working.
You didn't mention that before.
I'm not understanding why this is relevant? (My problem is the opposite direction: OpenVPN client side (Z) access to OpenVPN server side (Y) local IP, and CSO is not used for that direction, unless I do not understand something?)
Yes, for accessing the remote site from devices behind the Y router, the CSO is necessary though. And this is, where you have issues according to your posts.
I'm not trying to be argumentative, and I appreciate your help, but you seem to have the directions reversed from what I have described. I believe I have been consistent in all that I have written previoulsy, but I'll try again: Y is where the pfsense OpenVPN server and router are located. Z is where the pfSense OpenVPN client and router are located.
I agree with your statement that devices behind Y router require a CSO to access local IP of devices behind the Z router. You are not correct in stating this is where I have issues. Rather, as previously communicated, this direction is working correctly.
As previously stated, my issue is devices behind Z router not being able to access devices behind Y router.
The CSO not needed for access from the client itself, which obviously works.
I agree with your statement that CSO is not needed for access from the client side, which is Z. However, your statement that this obviously works is not correct. As previously stated, my issue is devices behind Z (OpenVPN client) router not being able to access devices behind Y (OpenVPN server) router.
But if you can access devices behind the Y router from Z local network, the CSO should be applied properly.
No, I cannot access devices behind the Y router from Z local network. This is the problem. And CSO does not apply to access of devices behind the Y router from Z local network, it applies in the opposite scenario, for access of devices behind the Z router from Y local network.
Then the only thing I get into mind is, that there is something wrong with the routes at Y, but need to see the whole routing table.
Here are all the routes at Y, which is the OpenVPN server side:
default HIDE_IP UGS 7 1500 mvneta0.4090 10.55.73.0/24 link#10 U 1 1500 mvneta0.4091 10.55.73.10 link#7 UHS 3 16384 lo0 10.55.83.0/24 10.55.201.1 UGS 13 1500 ovpnc1 10.55.201.0/24 link#14 U 11 1500 ovpnc1 10.55.201.251 link#7 UHS 12 16384 lo0 10.55.203.0/24 link#13 U 8 1500 ovpns2 10.55.203.1 link#7 UHS 9 16384 lo0 HIDE_IP link#12 U 4 1500 mvneta0.4090 HIDE_IP link#12 UHS 6 1500 mvneta0.4090 HIDE_IP link#7 UHS 5 16384 lo0 127.0.0.1 link#7 UH 2 16384 lo0 192.168.2.0/24 10.55.203.2 UGS 10 1500 ovpns2 209.18.47.61 link#12 UHS 6 1500 mvneta0.4090 209.18.47.63 link#12 UHS 6 1500 mvneta0.4090Here are all the routes at Z, which is the OpenVPN client side:
default HIDE_IP UGS 9 1500 mvneta0.4090 8.8.4.4 link#12 UHS 5 1500 mvneta0.4090 8.8.8.8 link#12 UHS 5 1500 mvneta0.4090 10.55.73.0/24 10.55.203.1 UGS 15 1500 ovpnc3 10.55.83.0/24 10.55.201.1 UGS 12 1500 ovpnc1 10.55.201.0/24 link#14 U 10 1500 ovpnc1 10.55.201.250 link#7 UHS 11 16384 lo0 10.55.202.0/24 link#13 U 6 1500 ovpns2 10.55.202.1 link#7 UHS 8 16384 lo0 10.55.203.0/24 link#15 U 13 1500 ovpnc3 10.55.203.250 link#7 UHS 14 16384 lo0 HIDE_IP link#12 U 1 1500 mvneta0.4090 HIDE_IP link#7 UHS 4 16384 lo0 127.0.0.1 link#7 UH 2 16384 lo0 192.168.2.0/24 link#10 U 3 1500 mvneta0.4091 192.168.2.1 link#7 UHS 7 16384 lo0 -
@viragomann I am sorry, I have been confusing CSO with "server route". So my prior statements about CSO not mattering for OpenVPN client to server routing were not correct. (I was incorrectly thinking of server route statements, which do in fact apply only in the server to client direction.)
That said, I do have a CSO in place on server Y, and it specifies tunnel network 10.55.203.250/24 and remote network 192.168.2.0/24. So that should be exactly correct.
Note that I also have an additional server X (as described previously), and the CSO in place on server X calls out tunnel network 10.55.201.250/24 and remote network 192.168.2.0/24. As stated previously, local accesses to devices behind router X from behind router Z are working correctly.
Because Z to X is working correctly (and Z to Y is not), I have been digging through and comparing every pfSense setting between router/server X and router/server Y to try and find a difference that would provide a hint as to the problem with Y, and I have not been able to find anything.
-
I've crawled through the routing tables (previously posted), and I find nothing incorrect. The tracert result from a client behind the Z router/OpenVPN client to a client behind the Y router/OpenVPN server shows the correct first two hops, and I can see no reason why it should not find the final destination (10.55.73.193):
@wmcneil said in SG1100: routes seem correct, but not working:
tracert from Z windows client (192.168.2.135) to Y client 10.55.73.193:
> > 1 1 ms <1 ms <1 ms cabin_pfSense.localdomain [192.168.2.1] > 2 33 ms 31 ms 39 ms 10.55.203.1 > 3 * * * Request timed out.