Wireless issue

Chris Davis

Posts: 7   +0
I have an interesting issue with my wireless network. I have two wireless networks running through my building. The first is the Private Wifi and the second is the Public Wifi. Currently, I am not having any issues with my Private Wifi. Everyone in my building can connect to it and access both internet and intranet with no issues. However, the Public Wifi has started becoming an issue.

When you try to connect to the Public Wifi, it comes up with the "Do you want to set up your network?" message window. Please note that it has been working just fine for the last 3 years and it is not a new network or new router. The message does give the option of connecting to the network without setting it up with allows you to connect. However, once you do connect, it cannot reach websites like Outlook Web App which has a public facing IP address with the appropriate NAT rules in the firewall to allow it to reach the server. Again, this connection works just fine on the Private Wifi.

Looking at our Access Points, there is nothing that I can tell to be the issue. The other building that has the exact same equipment as this building has no issues with their Public Wifi. I compared the two sets of Access Points to see if there was a setting that was enabled/disabled on the building's APs that worked that were not enabled/disabled on this buildings APs that would keep it from working. I have everything set to identical settings minus the appropriate IP and DNS addresses for both. Also, I have the 6 APs in this building (the one where the Public Wifi is not working) set to channels 1, 6, and 11 in such a configuration that the APs with the same channels were not side by side. (ie: going from left to right on a building schematic: 1, 6, 11, 1, 6, 11).

I have checked the DNS and DHCP settings and cannot see anything that would explain this. This is also happening across the board with all Windows 7 computers. However, Mac OS Sierra and Android Tablet operating systems are also having issues with connectivity to the Public Wifi, they just don't give the "Do you want to set up your network?" message.

If anyone has experienced this and knows how to fix it, please impart your wisdom as I have run the gamut of my knowledge and have yet to have any success. Thank you.
 
Last edited:
First; is the private wifi connected when you are attempting to access the Public? Also, is the local Lan connected too.
Frequently, we see that once there's any connection, secondaries fail to get responses to DHCP and thus may get an IP but fail to get a DNS
 
Another thought; segregate the public vs private subnets like 192.168.1.1 vs 192.168.2.1
 
Another thought; segregate the public vs private subnets like 192.168.1.1 vs 192.168.2.1

This issue is happening when it is not connected to any other network and LAN is not connected. As far as putting them on different subnets, why would that matter if they have been working just fine in their current configuration for 3 years until last week?
 
I understand your thought there - - I'm thinking this to ensure broadcast requests (like DHCP & there are others) go only to their specific controlling devices and are not seen by the alternative.
 
Verify the TCP setup for one PC each on the public & private nets;

on a public access;
  • ipconfig /all >publicTCP.txt
on a private access;
  • ipconfig /all >privateTCP.txt
post both files as follow-up
 
Here are the documents. I did look at the access points. They show that the Public and Private Wifis are on two different VLANs so I think that they are already segregated (sorry, I only took over this system recently and networking is not my strong suit).
 

Attachments

  • privateTCP.txt
    2.5 KB · Views: 4
  • publicTCP.txt
    2.5 KB · Views: 3
Public is IPv4 only gateway; private has IPv6 also

Public DNS includes google 8.8.8.8 and should be suspect - - why is it not another address on 176.16.10.x

My gut reaction would be to disable IPv6 everywhere, but that's working for the private so hold that thought.
 
So now that you point that out, that is probably the issue. However, when you look at the access points, the DNS just says that the primary address is 10.33.1.10 with no secondary address. I tried flushing the DNS to see if maybe I pulled old settings by accident but they are the same after the flush. So I apparently don't know where to go to change the DNS settings for the Wifis as the DNS settings on the APs don't actually do anything.
 
So I apparently don't know where to go to change the DNS settings for the Wifis as the DNS settings on the APs don't actually do anything.
Should not be true.
Example from your own private net:
Default Gateway . . . . . . . . . : fe80::225:90ff:fec5:9001%11 <the IPv6 GW>
10.33.0.1 <the IPv4 GW>
DHCP Server . . . . . . . . . . . : 10.33.1.10
DHCPv6 IAID . . . . . . . . . . . : 205530562
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-93-13-29-14-DA-E9-C9-48-86
DNS Servers . . . . . . . . . . . : 10.33.1.10
10.33.1.11​
Notice the primary DNS == DHCP server; strange but workable. Frequently it is the GW address.
The primary DNS should have all the company systems and when asked for something outside, it just does a 'recursive lookup' to the ISP where it gets resolved

The public is more interesting:
Default Gateway . . . . . . . . . : 172.16.10.2
DHCP Server . . . . . . . . . . . : 172.16.10.2
DHCPv6 IAID . . . . . . . . . . . : 205530562
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-93-13-29-14-DA-E9-C9-48-86
DNS Servers . . . . . . . . . . . : 172.16.10.1
8.8.8.8​
What device does 172.16.10.2 have upstream? It should be connected to your ISP gateway and thus not route into the company via 10.33.1.x

Here's two primary TCP tests:
  1. ping 98.138.253.109 <ping by address> and it proves connectivity to the Internet
  2. ping yahoo.com <ping by name> proving dns can resolve name to address and access the internet
To see the path taken, you can use TRACERT -d 98.138.253.109
or the ping by name if it resolves

Run both 1+2 on both private & public
 
Should not be true.
Example from your own private net:
Default Gateway . . . . . . . . . : fe80::225:90ff:fec5:9001%11 <the IPv6 GW>
10.33.0.1 <the IPv4 GW>
DHCP Server . . . . . . . . . . . : 10.33.1.10
DHCPv6 IAID . . . . . . . . . . . : 205530562
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-93-13-29-14-DA-E9-C9-48-86
DNS Servers . . . . . . . . . . . : 10.33.1.10
10.33.1.11​
Notice the primary DNS == DHCP server; strange but workable. Frequently it is the GW address.
The primary DNS should have all the company systems and when asked for something outside, it just does a 'recursive lookup' to the ISP where it gets resolved

The public is more interesting:
Default Gateway . . . . . . . . . : 172.16.10.2
DHCP Server . . . . . . . . . . . : 172.16.10.2
DHCPv6 IAID . . . . . . . . . . . : 205530562
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-93-13-29-14-DA-E9-C9-48-86
DNS Servers . . . . . . . . . . . : 172.16.10.1
8.8.8.8​
What device does 172.16.10.2 have upstream? It should be connected to your ISP gateway and thus not route into the company via 10.33.1.x

Here's two primary TCP tests:
  1. ping 98.138.253.109 <ping by address> and it proves connectivity to the Internet
  2. ping yahoo.com <ping by name> proving dns can resolve name to address and access the internet
To see the path taken, you can use TRACERT -d 98.138.253.109
or the ping by name if it resolves

Run both 1+2 on both private & public

Okay. I have run both on each of the Wifis. I could ping 98.138.253.109 on both wifis just fine. When I pinged yahoo.com, the private wifi returned 98.138.253.109 and the public wifi returned 206.190.36.45. I ran the tracert -d 98.138.253.109 on both wifis and the route was different for each. They both eventually got to 98.138.253.109 but they took different paths. I am assuming that that is normal though seeing that yahoo is a pretty big website.

On a curious note, I ran tracert -d yahoo.com on the private wifi and it came up with the ip address of 206.190.36.45 so my guess is that the ip I got when I pinged yahoo.com on the public wifi is an acceptable ip address for yahoo and all of this was for naught.
 
Also, the ISP gw address is a 209.60.x.x address so definitely not the 172.16.10.2 that the public wifi is pointing to.
 
Also, the ISP gw address is a 209.60.x.x address so definitely not the 172.16.10.2 that the public wifi is pointing to.
The 172.16... is your AP address, the 209.60... is its ISP GW

On a curious note, I ran tracert -d yahoo.com on the private wifi and it came up with the ip address of 206.190.36.45 so my guess is that the ip I got when I pinged yahoo.com on the public wifi is an acceptable ip address for yahoo and all of this was for naught.
Sorry you feel that way. These are positive results that strongly contradict your original assertion that the Public "is not working".

Yes, most BIG sites have multiple servers and based upon your location you will get different DNS resolutions.

The public use of 8.8.8.8 is coercing the Google DNS; In a well configured system, a standard setup does not need to coerce the DNS.
 
Sorry you feel that way. These are positive results that strongly contradict your original assertion that the Public "is not working".

Okay. Let's back up then and try again. Yes, the public wifi can get to sites like Google and Facebook. However, when I try to reach my Staff Portal (staff.3cisd.com) which should be able to be reached from any wireless network, it times out saying the the site cannot be reached. It does this with the Outlook Web App as well which is set up in a similar fashion.
 
AHH! That's a routing issue.

First, I assumed that your public vs private were intended along standard network design.
  • The Private Lan is strictly dedicated to company servers and shares. In no case should an external user coming from the Internet be able to access any company infrastructure data
  • The Public interface would be for all such external users, be strictly limited and heavily monitored
To allow the Staff Portal (staff.3cisd.com) to be accessed from the Public interface violates that design UNTIL you add some routing and a proxy controller to verify that only employees are making these requests.

I suppose you're going to say "but it was working" -- in which case you lost the routing.
 
I'm going to bow out on this as there's significant architecture decisions required to find the right fit for your company.
A simple networking route IMO is the wrong way to go.

Assuming that your Staff Portal (staff.3cisd.com) is intended to provide remote support and/or development,
the Public access should ONLY be to one client system working with one server where the real resources for the job(s) can be mounted and given the appropriate access controls.

I recommend that you escalate this thru your manager as the implementation can have company wide security implications.
 
Back