03-16-2016 01:16 PM - edited 03-08-2019 04:59 AM
I am trying to debug a configuration that has been working until recently. Someone edited the configuration file without backing it up, and I am now trying to troubleshoot the issue.
I have a Cisco 880 router which defines two subnets, 192.168.1.0/24 and 192.168.2.0/24. The first is assigned to the native VLAN, connects to a big switch and serves our wired computers. The second (on it's own VLAN) connects to a 1040 wireless access point. Both networks should have the same NAT settings, allowing access to the outside internet. However, the problem is that devices connected to the the wireless network (through the access point, on the 192.168.2.0 subnet) cannot access the outside internet. They can successfully connect to the access point as well as the router. Client devices on the wired network (192.168.1.0 subnet) can access the internet without issue. I am attempting to troubleshoot this problem, and would appreciate any insight or troubleshooting advice that y'all can offer!
Attached are the configuration files for both the router and the access point, with all keys redacted.
Thanks a ton for your help!
Solved! Go to Solution.
03-16-2016 03:34 PM
Can the users on the untrusted network not get out, or simply not get DNS resolution?
Have one of them try something like "tracert -d 8.8.8.8" - this will see if they have connectivity but will not attempt to resolve DNS at each hop. It looks like the client addresses on "untrusted" being farmed out are pointing to the 880 for name resolution; not sure if the 880 can do name resolution.
03-16-2016 03:34 PM
Can the users on the untrusted network not get out, or simply not get DNS resolution?
Have one of them try something like "tracert -d 8.8.8.8" - this will see if they have connectivity but will not attempt to resolve DNS at each hop. It looks like the client addresses on "untrusted" being farmed out are pointing to the 880 for name resolution; not sure if the 880 can do name resolution.
03-17-2016 03:12 AM
Which configuration was edited? The Router or the AP?
I would start by seeing if clients can ping their default gateway, i.e. the router on 192.168.2.1.
If so, do a traceroute and see where it stops.
Try and ping a hostname, are they getting DNS resolutions for www.google.com.
When clients on the wireless subnet try to access the internet, can you see entries from them in the NAT table?
#show ip nat translations
You need to narrow down the issue, start closest to the clients and work away from there.
03-18-2016 10:31 AM
Thanks for this advice! Very good troubleshooting suggestions. Running a traceroute showed that the problem was with dns resolution. In fact, the problem turned out to be an incorrect dns server setting on the "Untrusted" subnet in my router configuration file. Thanks a lot for your help!
03-18-2016 10:29 AM
The "Untrusted" dns server was set to point to the router. I changed this to match the dns server settings for "Trusted", and this fixed the problem. Running tracert -d 8.8.8.8 did itrace the route to the intended desination though it had at least one unresponsive node along the way. This seemed consistent with a DNS problem to me. Thank you!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide