The first thing to check is whether a device has a correct IP configuration when it is unable to communicate on the network. This entails verifying that the device can interact with the Firebox and has the proper IP address, subnet mask, gateway, and DNS settings in a WatchGuard context. You can use both the Firebox and the client device to confirm these settings by following the instructions below.
Understand the Required Network Settings
You should be familiar with the key network details utilized in your environment before you start. By examining any computer that is already linked to the network, you can obtain this data.
You need to know:
- IP address
- Subnet mask
- Default gateway
- Whether the device uses DHCP or a static IP
- DNS server addresses
Check the TCP/IP characteristics of a Windows, macOS, or Linux device for these details. These settings allow you to validate that any device you connect, including your Firebox, is correctly configured.
Verify How the Device Receives Its IP Address
Your device can obtain an IP address through one of the following methods:
- DHCP: Most internal networks rely on DHCP. In factory configuration, fireboxes use DHCP by default on the trusted network.
- Static IP: Usually used for servers or network equipment, it is manually assigned.
- PPPoE: Some ISP’s use PPPoE to provide Internet access. If your external interface supports this, you will require the PPPoE login credentials.
An IP address in the ranges 10.x.x.x, 192.168.x.x, or 172.16–172.31 indicates that your ISP has placed you behind a NAT device when they assign it to your external interface. To prevent configuration problems, a public IP is advised for the Firebox’s external interface. If the Firebox receives a private IP on its external interface, it will be operating behind another NAT device. This results in double-NAT, which commonly breaks inbound connections, port-forwarding, and many VPN services. This arrangement complicates root-cause analysis because the network translates the traffic twice. You can solve this by placing the ISP modem in bridge mode or configuring it to pass the public IP directly to the Firebox.
Confirm the Device’s Local IP Configuration
On a Windows device, the quickest way to check the IP configuration is to run:
ipconfig
Look for:
- The device’s assigned IP address
- Subnet mask
- Default gateway
- DNS server entries
Check that:
- The IP address belongs to the correct subnet
- The subnet mask matches the Firebox’s interface
- The default gateway is the Firebox’s internal IP
- DNS servers are valid and reachable
If something doesn’t match, the device will not communicate reliably.
Test Internal Connectivity (Ping Tests)
Connectivity tests help confirm if the device is actually usable on the network. Begin internally and work outward.
Test 1: Ping an Internal IP Address
From a trusted or optional network computer:
- Ping another device on the same network (for example, a server).
- Ping the trusted interface IP address of the Firebox.
If the device cannot ping internal IPs, possible causes include:
- Incorrect local IP configuration
- DHCP misconfiguration on the Firebox
- A rogue DHCP server on the network
- Incorrect IP or subnet mask on the Firebox
- Internal routing problem
- Cable/port failure
- IP conflict
These issues need to be corrected before moving on.
Test 2: Ping the Firebox’s External Default Gateway
If the internal ping succeeds, verify routing:
- From the same local computer, ping the default gateway of the Firebox’s external interface.
- You can find this gateway in Fireware Web UI under Interfaces, or in WatchGuard System Manager.
If this test fails, check for:
- Incorrect Dynamic NAT settings
- Policies blocking outbound ping
- Routing issues from the client through the Firebox
If this fails, it means traffic cannot reach the Internet.
Test 3: DNS Resolution Check
If routing is confirmed:
- Try pinging a domain such as:
ping www.varpath.com - If that fails, ping a known public IP (e.g., 8.8.8.8).
Results:
- If the IP responds but the hostname does not, DNS is the issue.
- If neither responds, routing or firewall rules are still an issue.
The following issues commonly cause DNS failures:
- Incorrect DNS servers on the client
- Firebox policies not allowing outbound DNS traffic
Use Firebox Tools for Further Verification
WatchGuard provides several built-in tools to help identify IP-related issues:
Firebox Ping Tool
Test connectivity directly from the Firebox to internal or external hosts.
DNS Lookup Tool
Verify DNS resolution from the Firebox itself.
Traffic Monitor
Check logs for allowed or denied packets. This helps identify:
- Blocked traffic
- Routing problems
- DNS failures
- Flooding or rate-limit drops
If the logs show drops caused by packet flooding, you may need to adjust Default Packet Handling settings.
Note: Troubleshooting network configuration in a Firebox environment can involve several variables, especially when DHCP scope settings, NAT behavior, or routing policies aren’t aligned. If you need deeper diagnostics or want a specialist to verify your Firebox configuration end-to-end, we’re here to help.
Visit our Contact page to get expert assistance tailored to your setup.
