Clients not redirected to Auth portal

[david_mayor]

Hello,

I have setup a WLC in the DMZ (anchor) and created EoIP tunnels with foreign WLC's.

My users can obtain an IP address given by the anchor WLC, but, they are not redirected to the authentication portal hosted on the anchor WLC.

• The DNS are the ones from Google (8.8.8.8). I cannot do a nslookup on 8.8.8.8. (this explains why the user is not redirected to auth page).
  
• I can reach the auth page by typing the IP address of the virtual IP (https://x.x.x.x/login.html) and I can successfully login.
  
• But even after being authenticated, I cannot do anything, no access to Internet (even by typing IP addresses of the websites) nor do any nslookup.
  
• When I am authenticated, I can successfully ping the "guest" interface of my Anchor WLC.
  

I have already built 2 other similar setup for other regions of the world and it works perfectly. Do you have any idea where the problem can come from ?

I am running 6.0.202.0 on the anchor WLC (5508) and 6.0.199.4 on the foreign WLC (5508).

Many thanks for your help !

David

[Justin Kurynny]

David,

If you plug in a wired ethernet client directly into the DMZ network (where your anchor controller's guest WLAN interface is bound), can the client get to the Internet?

You can trigger the authentication by typing in the virtual IP of the controller, but this doesn't say anything about your pathway beyond the anchor controller out to the Internet.

Justin

[daviwatk · Accepted solution]

If you can reach your gateway (dynamic interface) after you manually web-auth redireced, then it sounds like these clients just don't have internet access.  I would highly suggest looking at the next hop and making sure you can ping successfully with a ping sourced from the applicable vlan/network.  The symptoms you describe just sound like lack of internet connectivity.

1. You have an IP

2. You can't nslookup (ie. DNS queries are either not making it to DNS server, or answers are not coming back)

3. You can reach default gateway (wired dynamic interface gateway); so WLC is out of the picture at this point

Since you can't nslookup, but you can reach your wired gateway, definitely focus on internet connectivity for this subnet/vlan.  This is not a wireless problem.  Perhaps this is a "new" network scheme added and you have not adjusted your NAT ACL statements to properly NAT this new network?  Firewall not allowing traffic to pass or return?

[david_mayor]

Hello,

It is indeed a new network and we have corrected something in the routing to make the network advertised over the Internet. This changed a bit the client status (Windows 7 asked if we want to recognize this SSID as Home, Office or Public network, this was not happening before). I can not reach the firewall by trying to reach the FW, so this subnet is now correctly advertised and routed over the Internet.

However, my clients still cannot do DNS queries and thus are not redirected to the authentication portal. After having obtained an IP address, if the client does nslookup, what is the source IP address of the dns queries ? Will it be the NATed IP of the guest client IP or will it be the Mgmt IP of the WLC ? In my FW, the source seems to be the guest IP (which is then NATed).

Thanks a lot,

David

[Justin Kurynny]

David,

Your clients will use the the DNS servers you assign them from the DHCP scope definition. When the client does a DNS lookup, if it is using a public DNS server outside your network, then it will forward the traffic to the default gateway, and to the next gateway, and so on until the query reaches the firewall. If NAT is configured correctly on your firewall, then your client's source IP will be replaced with an IP on the outside of your firewall--this is usually the outside firewall interface IP, but it is whatever you defined for the NAT pool. When that packet goes out to the Internet, it looks like it's coming from your firewall.

When the query is returned by the DNS server, it sends it to that same outside address of your firewall. Once this return packet reaches your firewall, the destination IP header is replaced with the original client's IP (the client that made the original DNS query). Finally, the packet is routed back through the inside of your network until it reaches your client.

You need to check the following (at a minimum):

• Are your clients, upon completing DHCP, receiving known working DNS server addresses?
• Are your clients receiving a correct default gateway IP, and can a test client ping the gateway?
• Is the IP pool that your clients are in correctly defined for NAT rules on your firewall? Without a NAT rule specifically for those client IP addresses, the firewall won't perform the NAT
• Does your firewally have any ACLs that would prevent the traffic from going through to the Internet?
• Do you have any asymmetric routing anywhere? I.e., can you verify that there is just one path out (IP-to-IP) and just one path back from the client all the way to the edge of your network?
• If you plug in a wired client onto this very same wireless client network, does everything work normally?
• What do your firewall logs say? If it's an ASA, you can open the Monitoring window and view live debugging logs and filter on the test client's IP address. Those live logs are very useful and will indicate if your issue lies in FW configuration (95% of the time, anyway).

Justin

[david_mayor]

Hello,

Finally I could make it work. The problem was not related to the WLC setup but from the NAT address which was not correctly routed/advertised over the Internet.

So it is done correctly and everything works like a charm.

Thanks a lot !

David