Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

enter image description here

share|improve this question
2  
I like the black cloud for the internet! –  tomjedrz Apr 18 '11 at 0:15
    
I'm confused. When you get the request timed out, you are pinging from what IP to what IP? –  Paul Apr 18 '11 at 0:16
    
Please edit the question and add more info. You will get better answers if you augment the question with the firewall hardware specifics, software specifics, and the existing tunnel specifics. –  tomjedrz Apr 18 '11 at 0:16
    
@Paul: The timeout occurs from x.15.x to x.3.x –  Darbio Apr 18 '11 at 0:30
    
I'm not familiar with the pfSense firewall but i'm sure there is some kind of log you can check to see why the traffic is not getting through. Does the traffic get through to 2.x? –  Cheekaleak Apr 18 '11 at 0:51

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
OK. So if I migrate the x.3.x subnet to the same NIC could this work? alternatively, would bridging the 2 nic's make a difference? –  Darbio Apr 18 '11 at 0:24
    
It should, although it depends how you do it. –  tomjedrz Apr 18 '11 at 4:10
    
I ended up trying all of the above, and finally created a new IPsec tunnel between x.15.y and x.3.y - this works. Thanks –  Darbio Apr 19 '11 at 2:00

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).

share|improve this answer
    
This isn't the route I took, though I think it may be the cause. For some reason my router wouldn't let me set up a manual static route between x.15.y and x.3.y. An extra IPsec tunnel between the 2 servers solved the problem and I can now see x.3.y from x.15.y –  Darbio Apr 19 '11 at 1:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.