0

Small business has internal Windows network on a single subnet 192.168.16.x. There is a Watchguard XTM 330 firewall appliance which routes traffic to the internet. Leased line.

Some users are having intermittent difficulty getting to an internal web application. When this happens, a ping to the address of the internal web server (which is a 192.168.16.x address) gives this result:

Pinging [local server name] [192.168.16.x] with 32 bytes of data:
Reply from 192.168.20.1: Destination host unreachable.
Reply from 192.168.20.1: Destination host unreachable.
Reply from 192.168.20.1: Destination host unreachable.
Reply from 192.168.20.1: Destination host unreachable.

There is no usage of the 192.168.20.x subnet that we are aware of so this is a mystery.

ipconfig /all reports the correct default gateway which is 192.168.16.1 (internal IP of the XTM).

One other thing: we also tried a tracert to 192.168.20.1 from the affected machines. In one case we got this:

Tracing route to 192.168.20.1 over a maximum of 30 hops

1     4 ms     6 ms     6 ms  192.168.16.1
2     7 ms     8 ms     7 ms  [public IP address of XTM]
3     *        5 ms     2 ms  192.168.20.1

In other words, the tracert went to the XTM and then to the mystery server and got a reply.

In other cases (same internal network) we got this, which is what I would expect:

Tracing route to 192.168.20.1 over a maximum of 30 hops

1     4 ms     3 ms     8 ms  192.168.16.1
2     5 ms     8 ms     6 ms  [public IP address of XTM]
3  [public IP address of XTM] reports: Destination net unreachable.

I am puzzled by this behaviour and would welcome troubleshooting suggestions.

PS:

Routes
------------
Route Table: main
-------------------
default via [public IP].57 dev eth0  metric 5 
10.0.6.0/24 dev eth6  proto kernel  scope link 
[public IP].72/29 dev eth0  proto kernel  scope link 
[public IP].56/29 dev eth0  proto kernel  scope link 
127.0.0.0/8 dev lo  scope link 
172.20.10.12 dev eth0  scope link  metric 1 
192.168.16.0/24 dev eth1  proto kernel  scope link 
::1/128 via :: dev lo 

Route Table: eth0.out
-------------------
default via [public IP].57 dev eth0  metric 1 
[public IP].56/29 dev eth0  scope link  metric 1
timanderson
  • 263
  • 1
  • 4
  • 12

1 Answers1

0

It turns out this is what happens if someone connects an ADSL router to the network in order to use it as a switch to expand the number of Ethernet ports available. DHCP was disabled on the router but it still intermittently tried to route traffic through its (disconnected) WAN port. Nobody realised it was a router and not just a switch. 192.168.20.1 was a massive clue but arp was the key troubleshooting tool.

Watchguard was working fine.

Tim

timanderson
  • 263
  • 1
  • 4
  • 12