1

In our office network we have a VPN setup to our datacenter. We are using a Sonicwall NAS. The VPN works fine for most cases. From our office we can connect to the servers in our DC but if I were to remote into a server in the DC and try to ping a local host then the requests time out.

We also have site-to-site tunnels between two other offices and if I remote into a machine in any of those two offices I can ping local machines.

So let's say we have our 4 networks which are as follows:

  • 10.10.10.0/24 (DataCenter)
  • 192.168.0.0/24 (Office 1)
  • 192.168.1.0/24 (Office 2)
  • 192.168.2.0/24 (Office 3)

Then the issue is that:

  • DataCenter can talk to: Office 1, Office 2
  • Office 1 can talk to Office 2, Office 3, DataCenter
  • Office 2 can talk to Office 1, Office 3, DataCenter
  • Office 3 can talk to DataCenter, Office 1, Office 2

I can't figure out why DataCenter can't talk to Office 3. As far as I can tell, all 3 tunnels are configured the same way and there is no non-standard/automatic routes, NAT rules, or firewall rules.

Unfortunately, I don't have access to the DG at the DC so I can't see the table, but the routes look like this:

Tracing route to 192.168.1.1 over a maximum of 30 hops

  1     1 ms    <1 ms    <1 ms  10.10.10.1
  2     9 ms    10 ms     9 ms  192.168.1.1

Tracing route to 192.168.2.1 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.10.10.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  ...
  30    *        *        *     Request timed out.
illvm
  • 111
  • 4
  • Are you trying to ping a local host from remote by IP or DNS? – Jason Huntley Mar 22 '12 at 20:04
  • I am trying to ping by IP. I cannot even ping our local gateway in Office 3 from the DataCenter while I can ping the gateways of Office 1 and Office 2 from the DataCenter. – illvm Mar 22 '12 at 20:28
  • What kind of server? Windows Server or Linux? – Jason Huntley Mar 22 '12 at 20:30
  • Run a tracert from the datacenter to office 3 and see what the results are. The traffic may be taking a path you're not expecting (and therefore not getting to office 3). If the path looks OK, then run a packet capture on both ends while you ping one from the other (and vice versa) to see if you're seeing the ICMP traffic going in both directions from both sides. – joeqwerty Mar 22 '12 at 20:31
  • The tracert is definitely strange. Going from DC->O1 or DC->O2 it's a straight jump from gateway -> host while going from DC->O3 we see the gateway followed by lots of hops which timeout. Is it a routing issue on the gateway in the DC? – illvm Mar 22 '12 at 20:38
  • Probably. Check the routing table on the DG at the DC to make sure it's correct. Also, run a packet capture from the DC while pinging or tracing O3 and look for ICMP redirects. It may be that traffic to O3 is being redirected unintentionally. – joeqwerty Mar 22 '12 at 20:46
  • Both our Windows Server 2008 and Ubuntu Linux boxes have the same behavior. It's not limited it ICMP traffic as RDP, HTTP, HTTPS, and SSH traffic also doesn't go through. – illvm Mar 22 '12 at 20:50
  • No, an ICMP redirect affects all traffic. It's an ICMP packet from a router telling the source host (for any and all traffic; RDP, HTTP, etc) to take another route. If there's an ICMP redirect occurring then that's definitely the issue. - http://en.wikipedia.org/wiki/ICMP_Redirect_Message – joeqwerty Mar 22 '12 at 21:06
  • From one of the linux boxes in the DC I did a tcpdump looking for icmp redirect packets but couldn't see any. – illvm Mar 22 '12 at 23:44
  • How does the routing table on the DG at the DC look? Can you post the output of a tracert from the DC to O2 and from the DC to O3 for comparison? – joeqwerty Mar 23 '12 at 17:42
  • I don't have access to the DG in the DC so I can't see the routing table, but the trace routes are posted. – illvm Mar 24 '12 at 01:28

0 Answers0