[SOLVED] IPsec Site-to-Site VNP, static IP can't go through
-
IPSec doesn't care whether or not the address is statically or dynamically assigned.
Have you done packet captures whether the computer is receiving the ICMP packet from the other end of the tunnel? Have you done a packet capture on the LAN side of both firewalls to verify whether the ICMP packet is going across the tunnel?
-
I captured the wireshark traces on the pinged PC. The ICMP packet reached the destination PC, that means it went through the IPsec tunnel. It looks the incoming ICMP message have problem ("no responses found") after it passed through the VPN tunnel.
The attached wireshark screenshot was the ping from site B (10.50.200.109) to site A (10.50.196.5, static IP). The destination PC ignored the ping because the ICMP message had defect. Does pfSense IPsec make it?
-
Check everything regarding the static. Specifically, make sure the gateway is the same (pfSense) and that its firewall allows pings (connections) from foreign networks.
-
Thank you for reply. The GW is in the same subnet of pfSense (Actually the GW is the LAN interface IP of pfSense). I don't know how to let firewall allow ping from foreign networks. However my static IP (10.50.196.5) is in the scope of LAN IP (10.50.196.0/24) and the scope of the remote subnet defined in IPsec phase 2 of the other end.
In the firewall rule of LAN and IPsec, I enabled everything. The screenshot is the site A firewall rule for LAN and IPsec, and the site B IPsec phase2 settings.
-
None of this has anything to do with static vs dynamic addressing. IPsec doesn't care one bit.
As I already said, check that the static addressing (gateway, netmask, etc) is the same on the static host as it is for the dynamic clients.
-
The destination PC ignored the ping because the ICMP message had defect. Does pfSense IPsec make it?
I don't think you have an issue with your settings or the packet wouldn't have traveled across the tunnel. Why do you think the ICMP packet has a defect? Is the firewall enabled on the PC? Can you shut it off and test again?
-
I am operating on the presumption that DHCP clients CAN ping the server and static clients CAN'T. Otherwise, why have this thread at all?
If that is not the case and nobody can ping it across the tunnel, then it's the windows firewall, or the default gateway on the target server.
I don't know how to let firewall allow ping from foreign networks.
You need to google it then.
-
Thank you Derelict for the reply. The actually result is anybody (either static client or DHCP client) CAN NOT ping the server because the server is static IP, although the server IP is in the subnet of the LAN.
It looks it is not the windows firewall. Because if I change a client from static to DHCP and renew the lease, it will be able to ping DHCP clients of the other site immediately, or to be pinged by DHCP clients from the other site. If I change a client from DHCP to static, it will lose all communications, even if the static IP is in the DHCP scope.
Since all static clients are in the same subnet, and the default gateway is the LAN interface of pfSense, why we need something for "foreign networks"?
-
I'm telling you… IPsec doesn't care. You need to find the difference between the DHCP assignment and the static assignment and you will fix your problem.
-
Thank you guys. My problem is solved. After comparing the deference between static IP and DHCP IP, I found the static IP PC was using subnet mask 255.255.0.0 instead of 255.255.255.0. Then problem is gone after I changed it to 255.255.255.0.
