Why devices work locally but not across VLANs

• Clients cannot reach the device or its web interface from the network
• Time services respond on the local subnet but fail from other subnets
• Device appears intermittently reachable or drops off the network after changes

• Incorrect client or server configuration
• DHCP reassigned the device IP address after reboot, and clients or bookmarks still use the old address
• Network reachability or routing differences
• Traffic blocked by firewall rules
• Gateway, subnet mask, or routing changes after network maintenance
• NAT, VPN, or routing policies that do not pass UDP timing traffic reliably

1. Confirm the device’s current IP address.
   If the device uses DHCP, its IP address can change after a reboot or network change. Verify the current address in WinDiscovery or your DHCP lease list.
2. Verify IP addressing, subnet mask, and gateway.
   Ensure the device is on the correct subnet and has a valid gateway for traffic that must cross subnets. A wrong gateway can make the device reachable locally but not remotely.
3. Test from the same network path clients use.
   A successful local test does not confirm cross-subnet connectivity. Test from the client VLAN or remote subnet where the issue is observed.
4. Review recent network changes.
   If connectivity changed suddenly, check for VLAN, routing, ACL, or security policy updates that could block access or UDP timing traffic.

This topic commonly comes up during configuration, verification, or troubleshooting. Understanding what this behavior or setting represents helps distinguish between normal operation and an actual fault.