Site-to-site
-
I added the NAT rule to the LAN interface and it still can't ping.
Would you show us?
When I tracert from the Server's LAN the packet goes (obviously) through the gateway PFsense router, but then request times out. Shouldn't it be looking to the client router(10.5.0.2);
Whats about the firewall rules?
How can I forward these packets to the other router?
And how can I do a packet trace on each router so that I can monitor further the problem?
The packets should be routed and the routes are obviously correct.
You can use Diagnostic > Packet capture for troubleshooting. You can do a capture on clients vpn interface while you ping from servers site to see if packets arrive.
-
I tried to do a reverse vpn topology:
-The previous client became the server
-The previous server became the clientI am not OK with this setup, this is just for debugging purposes. Both VPN instances(client and server) have an allow all rule. I have NATed the server's network so that I can see it from the server because it is not the default gateway as I stated on a previous thread(then it was the client).
Two Xanaxes(pills ;D ;D ;D) later, I noticed that:
Again the server cant ping the client's network(Diagnostics->Tools).
I can ping the server's network from the client but only from the CLIENT VPN INTERFACE.
SO does that mean that I cant pass traffic from VPN interface to LAN interface, and maybe that is the problem?
-
Usually that means that the server has no route set for the clients LAN network.
-
Would you show us?
I am attaching the LAN rules table, the NAT rule you asked (and thank you very much by the way).
The VPN interface consists only from one rule which is allow any to any IPv4.
Thank you



 -
Usually that means that the server has no route set for the clients LAN network.
Ok, that is something. But how do I add that route? Static route doesn't seem to work.
-
Okay, that rule tells me that on the clients LAN anything is allowed. But what's on the clients OpenVPN interface or that one you've assigned to the client, where the packets should come in?
In the NAT rule the source should be any. If you access from the servers LAN the packets will have a source IP of 192.168.1.0/24.
The routes are set by the openvpn module. If they still looks like in the screenshot they should be okay and no NAT rule should be necessary in this case.
-
In the NAT rule the source should be any.
Changed! Didn't notice that one.
I am attaching from the client both the LAN rules and the client VPN interface.
But how do I permit traffic between the two interfaces(LAN interface and VPN assigned interface)?
Thinking out loud, this could be the solution so that the CLIENT's LAN communicates with the SERVER's LAN.Of course this does not work the other way around, but it would be a start.
Thank you.



 -
Traffic is permitted by filter rules on the firewall > rules > interface tab. The traffic is controlled on the incoming interface.
So since you have a rule on openvpn interface which allow any from any to any, all devices connected to this interface have access to anywhere. So this rule permits also the access from the vpn servers LAN to the clients LAN.
However, on servers site this traffic is also controlled by rules on the LAN interface. -
Yes but since I have a LAN rule on both sides that allows any to any,with protocol any, why can't I ping the other network?
Should I define any mysterious gateway perhaps?
-
The gateways are already set by OpenVPN and are shown in the routing tables.
I already suggested to use packet capture for troubleshooting. For instance take a capture on the client on the OpenVPN interface, set the protocol to ICMP, start it and try a ping from the server to a LAN host behind the client. After stopping you should see the packets. Then try a ping from a servers sites LAN device. I you still see the packets, change the interface to LAN and check if you see the ping requests and the responses from the LAN device.
-
OK, while I was pinging from server's LAN (pinging from VPN's interface works ok), I packet captured client's VPN interface (ICMP only) and indeed I captured packets. But when I captured LAN interface no packets were recieved.
So in order to be clear:
SERVER PING from VPN INTERFACE–-->CLIENT packet capture on VPN INTERFACE16:30:11.577687 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59656, length 8
16:30:11.581641 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17796, length 8
16:30:11.581667 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17796, length 8
16:30:11.633149 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 59656, length 8
16:30:12.078581 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59657, length 8
16:30:12.080301 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17797, length 8
16:30:12.080326 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17797, length 8
16:30:12.250552 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 59657, length 8
16:30:12.580604 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59658, length 8
16:30:12.587870 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17798, length 8
16:30:12.587892 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17798, length 8It seems to reply but my ping fails (100% PACKET LOSS)
SERVER PING from LAN INTERFACE ---->CLIENT packet capture on VPN INTERFACE
18:07:04.700947 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 29354, length 8
18:07:04.700969 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 29354, length 8
18:07:04.820259 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 9629, length 8
18:07:04.875810 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 9629, length 8Exactly the same. It seems to reply but ping fails.
SERVER PING from LAN INTERFACE ---->CLIENT packet capture on LAN INTERFACE
Nothing gets captured.SERVER PING from VPN INTERFACE ---->CLIENT packet capture on LAN INTERFACE
Nothing gets captured.I am posting the LAN Firewall Rules on Client.
So if rules are allow all from any to any protocol on client's LAN, why can't I ping anything from the server's LAN to client's LAN.
What am I doing wrong here?
 -
Of course I am not pinging VPN tunnel IPs but client's LAN IPs. This is not visible on the packet capture logs.
-
I guess you have messed up your NAT. ???
To illuminate this, please post all your NAT rules (port forwarding, 1:1, outbound) from server an client. -
OK here are the attachments.
Npt and 1:1 are black in both routers.NAT is in Hybrid mode.
I am grateful for your time.
Thank you,




 -
SERVER PING from LAN INTERFACE –-->CLIENT packet capture on VPN INTERFACE
18:07:04.700947 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 29354, length 8
18:07:04.700969 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 29354, length 8
18:07:04.820259 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 9629, length 8
18:07:04.875810 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 9629, length 8If the source address of ping is LAN there should be shown ICMP requests from coming from 192.168.1.1.
I can find no reason in your NAT rules why the address should be translated.SERVER PING from VPN INTERFACE–-->CLIENT packet capture on VPN INTERFACE
16:30:11.577687 IP 10.5.0.2 > 10.5.0.1: ICMP echo request, id 60760, seq 59656, length 8
16:30:11.581641 IP 10.5.0.1 > 10.5.0.2: ICMP echo request, id 54791, seq 17796, length 8
16:30:11.581667 IP 10.5.0.2 > 10.5.0.1: ICMP echo reply, id 54791, seq 17796, length 8
16:30:11.633149 IP 10.5.0.1 > 10.5.0.2: ICMP echo reply, id 60760, seq 59656, length 8
It seems to reply but my ping fails (100% PACKET LOSS)This capture shown ping requests from the client to the server, not backwards. ???
I think all the pings shown here come from gateway monitoring (dpinger). To get a feasible outcome you should deactivate gateway monitoring on the vpn GWs in System > Routing > Gateways and rerun the test.
-
OK, after disabling Gateway Monitoring(Checked the box Disable Gateway Monitoring), and disabling the reverse test connection(server as client, client as server, different tunnel network) here are the results:
SERVER VPN INT to CLIENT VPN INT:
Nothing gets captured.CLIENT VPN INT to SERVER VPN INT:
20:16:08.987196 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 0, length 64
20:16:08.987779 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 0, length 64
20:16:10.045360 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 1, length 64
20:16:10.045857 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 1, length 64CLIENT LAN INT to SERVER VPN INT:
Nothing gets captured.CLIENT VPN INT to SERVER LAN INT:
20:17:30.889581 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
20:17:30.889655 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192
20:17:33.177124 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 0, length 64
20:17:33.177610 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 0, length 64
20:17:34.236385 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 1, length 64
20:17:34.236938 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 1, length 64
20:17:35.297149 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 2, length 64
20:17:35.298138 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 2, length 64
20:17:35.957371 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
20:17:35.957446 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192After that test I tried setting both outbound NATs to manual and deleting all the mappings. Then switched back to Hybrid NAT on both. Exactly the same results.
Of course I have backed up both, before deleting outbound NAT rules.
-
I am attaching the NAT rules now.



 -
It also matters where the captures are taken from, client or server, vpn or LAN?
CLIENT VPN INT to SERVER VPN INT:
20:16:08.987196 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 0, length 64
20:16:08.987779 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 0, length 64
20:16:10.045360 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 1, length 64
20:16:10.045857 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 1, length 64This show pings from the clients vpn interface to a server sides LAN device.
CLIENT VPN INT to SERVER LAN INT:
20:17:30.889581 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
20:17:30.889655 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192
20:17:33.177124 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 0, length 64
20:17:33.177610 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 0, length 64
20:17:34.236385 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 1, length 64
20:17:34.236938 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 1, length 64
20:17:35.297149 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 2, length 64
20:17:35.298138 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 2, length 64
20:17:35.957371 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
20:17:35.957446 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192Same here. Were you pinging 192.168.1.201?
-
Yes, both lans have a test machine always open and their ips end with 201.
So for client's lan this is 192.168.0.201.
For server's lan 192.168.1.201.But I can't understand.
If NATs are back to default, gateways are normal, routes are normal, why can't I ping from the one LAN to the other and vice versa.This is getting so frustrating.
I even tried to set a Client Specific Override, but no luck.
I actually doubt that this was right, because my client's VPN int ended up getting 10.5.0.0 as an IP. :'(I am also attaching the server routes just in case you see something odd.
My priority right now is to be able to see client's net from server's net.
And I too far from that.Thanks again for your concern, I am really grateful.

 -
That is the clients routing table, not the servers.
Unless you tell me where the packets taken from, there is no way to interpret the captures correctly.