Site-to-Site, client problems
-
Is the client pfSense set as default gateway at the LAN hosts in 172.16.1.0/24?
-
Hiya,
Yes, I've checked a few computers and they all have 172.16.1.1 (which is my client pfSense) as their default gateway.
Do I need to create a custom NAT rule?Thanks,
-
No, if pfSense is the default gateway there is no need for nat. You only need firewall rules at the clients LAN interface and the servers OpenVPN interface which allow the access.
Do you have more than one OpenVPN instance running on one node?
Check the routing table when the VPN is connected.
-
Got the 2 firewall rules (one for the port, the other to allow all traffic inside OpenVPN tunnel) in place on both ends, pretty much identical.
Only one instace of OpenVPN on each site. It is a fresh install really.tables:
IPv4 Routes - Site1 - OpenVPN Server Server Destination Gateway Flags Use Mtu Netif Expire default 192.168.1.253 UGS 16324185 1500 em0 10.0.5.1 link#7 UHS 0 16384 lo0 10.0.5.2 link#7 UH 3 1500 ovpns1 127.0.0.1 link#6 UH 1350 16384 lo0 172.16.0.0/24 link#2 U 30884728 1500 em1 172.16.0.1 link#2 UHS 0 16384 lo0 172.16.1.0/24 10.0.5.2 UGS 16275112 1500 ovpns1 192.168.1.0/24 link#1 U 397949 1500 em0 192.168.1.250 link#1 UHS 0 16384 loIPv4 Routes - Site2 - OpenVPN Client Destination Gateway Flags Use Mtu Netif Expire default 192.168.1.254 UGS 6005809 1500 em0 10.0.5.1 link#7 UH 3 1500 ovpnc1 10.0.5.2 link#7 UHS 0 16384 lo0 127.0.0.1 link#6 UH 1419 16384 lo0 172.16.0.0/24 10.0.5.1 UGS 312134 1500 ovpnc1 172.16.1.0/24 link#2 U 2947270 1500 em1 172.16.1.1 link#2 UHS 0 16384 lo0 192.168.1.0/24 link#1 U 94309 1500 em0 192.168.1.249 link#1 UHS 0 16384 lo0It seems like it's goood. Not sure what to make of it.
By the way, the 192.168.1 subnet is because my pfSense WAN is connected to ISP modem/router which has its own NAT. Not sure if thats a problem.Many thanks for your help
-
The routes seem to be okay.
Are you sure that the access isn't blocked by the destination hosts SW firewall?
To ensure you can use packet capture (Diagnostic menu) at the servers OpenVPN and LAN interface to check if packets arrive there while pinging a host. -
Thank you,
I will try the Packet Capture feature on the Server end right now
I do not believe it is a SW firewall because I tried going to Diagnostics -> Ping on the Client site to ping the Server site (172.16.0.1) and remote Vtunnel IP (10.0.5.1) and both timed out.
And again, it pings fine the other way around. -
Did Packet capture on the Server pfsense for the OpenVPN traffic:
11:17:27.845384 IP 10.0.5.2 > 172.16.0.1: ICMP echo request, id 6828, seq 0, length 64 11:17:28.855230 IP 10.0.5.2 > 172.16.0.1: ICMP echo request, id 6828, seq 1, length 64 11:17:29.857406 IP 10.0.5.2 > 172.16.0.1: ICMP echo request, id 6828, seq 2, length 64That means the ping actually did make it but wasn't replied.
I also saw this in the Status-System Logs-Firewall-Dynamic View
Sep 2 11:31:18 ovpns1 10.0.5.2 172.16.0.1 ICMP Sep 2 11:31:19 ovpns1 10.0.5.2 172.16.0.1 ICMP Sep 2 11:31:20 ovpns1 10.0.5.2 172.16.0.1 ICMPDoes that mean the firewall is blocking it?
-
So also the ping to the servers LAN address isn't replied. That couldn't be caused by a hosts FW, off course.
So it seems the packets are dropped. FW at the server rules surely okay? -
yes, I just double checked and believe the FW are fine:
These are my Firewall Rules: (like I said, its a fresh): :)
WAN:
States Protocol Source Port Destination Port Gateway Queue Schedule Description 0/1 KiB * RFC 1918 networks * * * * * Block private networks 0/0 B * Reserved Not assigned by IANA * * * * * Block bogon networks 0/3.03 GiB IPv4 UDP * * WAN address 1194 * noneOpenVPN Rules
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions 0/0 B IPv4 * * * * * * noneBoth rules are identical on both the server and the client.
-
OK … this one of those cases where reboot works.
Rebooted the Server pfSense and all is well now.Thanks a bunch for your time and help!