Ping from subnet over IPSec

Question

I have set up a distributed network as in the figure below. The subnet x.15.x is a remote subnet, connected to the internal LAN via IPsec VPN. The Firewall has 3 interfaces, one connected to the net, one connected to the x.2.x subnet and one connected to x.3.x subnet.

1. When I ping 192.168.3.25 from 192.168.2.10 I get a response.
2. When I try and ping 192.168.3.25 on it's external IP address from 192.168.15.50 I get a response.

However;

1. When I try and ping it from a client on the IPsec connection (e.g. 192.168.15.50) I get a request timed out.

Am I missing a principal of IPsec networking? How can I get it to send data to the x.3.x subnet?

The firewall is a pfSense, and the servers are Windows Server 2008 R2. The tunnel is a IPsec tunnel through the internet.

Answer 1

I suspect that, because the two networks are on different interfaces on the firewall, the x.2.x subnet and the x.3.x subnet will require separate IPSec VPNs to the x.15.x subnet on the other side.

---

Response to OP comment: So if I migrate the x.3.x subnet to the same NIC could this work?

It might, but I don't know for sure. If you mount both interface IPs on the same NIC, you will likely need to have two tunnels. But if you increase the size of the x.2.x subnet by making the subnet mask 1 bit smaller (255.255.254.0), you can put the x.3.x devices onto the x.2.x physical network. It should work as long as you can update the VPN to have the smaller subnet mask. There will likely be other considerations, such as DHCP and the default gateway for the x.3.x devices. I suspect building a second tunnel will be cleaner.

Answer 2

This is most likely a routing problem.

The firewall must route traffic for the x.15.y subnet into the tunnel, and it must route traffic coming out of the tunnel to the relevant subnets (this should happen automatically, since these subnets are connected directly.

In addition, the router on the other side must route traffic for both the x.2.y and the x.3.y networks into the tunnel.

At the moment it looks like the router on the x.15.y network doesn't do that. The timeout occurs, because the router on the x.15.7 side does not have a specific route and therefore tries to send the packets via the default route (i.e. into the public internet, where they are not routable and therefore get lost).