MSM Controllers - DNS issues with DNS Interception

MVP Expert
MVP Expert
Problem:

Troubleshooting potential DNS issues on MSM controllers -

  • Affects all versions of MSM software.
  • Affects only MSM controllers.
  • Affects  only Access-Controlled wireless users.
  • Affects SNTP/NTP time services on MSM controllers.
  • Involves MSM controller's "DNS Interception" service for users.

When using MSM controllers and Access-Controlled VSCs (SSIDs), then you are tunneling client traffic from the AP directly to the controller or controller Team.

The clients are then relying on the controller to act as DHCP server, default gateway and DNS server for them to operate normally.

Under this Access-Controlled mode on VSCs, some conditions may exists that cause DNS services to stop working, or not work at all;

  1.  You're running an older version of MSM software with known DNS bugs.
  2.  DNS is not configured or not properly configured.
  3.  The upstream network Intrusion Detection or Firewall is preventing DNS requests from getting to private DNS servers or public DNS servers.
  4.  DNS responses are not getting back to the MSM controller, or to the users. 
  5.  Not enabling DNS Interception.  (is NAT enabled ?)

 



Diagnostics:

 You're running an older version of MSM software with known DNS bugs -

When you run older MSM software, it's possible to encounter bugs or memory leaks (if the MSM uptime is greater than 180 days).

It is advisable to review the latest MSM software Release Notes to determine if an upgrade is needed or not.

(Note that only customer-reported bugfixes are listed in the release notes.  Other bugfixes may be included in the SW release).

 

 DNS is not configured or not properly configured -

In order for the MSM controller to operate properly, (such as getting Internet timestamp), you need to have the DNS configured correctly.

If DNS is configured correctly, pointed to valid upstream DNS servers, then you can use DNS Interception for Access-controlled clients correctly.

By not configuring DNS, or not configuring it correctly, then the MSM timestamp may drift and not keep correct time.

This can impact synched APs, Active Directory LDAP services, and Access-controlled clients, etc.

 

 The upstream network Intrusion Detection or Firewall is preventing DNS requests from getting to private DNS servers or public DNS servers -

There have been customer cases where DNS seems to fail for all users periodically.

This turned out to be some Firewall IDS service upstream from the MSM that has imposed DNS requests/sec limits.

Some IDS / firewall solutions has DNS requests/sec limits set, which gets exceeded.

On busy MSM controllers with many Access-Controlled users, sending many DNS requests, cause this limit to be reached.

Thus, further DNS requests are being blocked for all users.

This is because the MSM controller has NAT enabled, and all DNS requests come form the same source IP / source port.

 

 DNS responses are not getting back to the MSM controller, or to the users - 

If the MSM controller is configured with NAT disabled, then it's left to the routing service in the MSM to forward all DNS requests upstream un-masked.

That means if your wireless users are on subnet 192.168.1.x, then their DNS source addresses will have the same subnet when sent upstream.

This then assumes the upstream network knows how to route the DNS responses back to the MSM controller.

If it does not know where 192.168.1.x subnet is, then the response will be dropped by the upstream routers and nothing is sent to the MSM.

 

 Not enabling DNS Interception - 

If you disable DNS Interception, then the Access-Controller users will be forwarding their DNS requests directly upstream.

But the DNS address they are assigned by the MSM will be private (i.e. 192.168.1.1), and this DNS IP may not exist on the upstream network.

Also, access-controlled clients are assigned to a private subnet, (i.e. 192.168.1.x) and these source addresses may not have a route in the upstream network.

 



Solution

You're running an older version of MSM software with known DNS bugs -

It is recommended that you upgrade your MSM to the latest maintenance release.

This will provided the latest bugfixes and wireless optimizations and many 100s of customers are already running this.

Go to HPE My Networking website or ask your support contact for assistance.

Be sure to read the release notes first for upgrade instructions.

 

 DNS is not configured or not properly configured -

Under the Controller-->Network-->DNS tab, you need to confirm the following for DNS to work properly.

- If DHCP is used on the Internet port that "Dynamically Assign DNS" is populated with valid DNS addresses.

- If static configuration is used, that the "Override" checkbox is enabled and you manually add valid DNS addresses and click Save.

 

 The upstream network Intrusion Detection or Firewall is preventing DNS requests from getting to private DNS servers or public DNS servers -

If some device (Firewall or IDS) is blocking DNS requests when threshold limits are reached, you need to confirm that the MSM is actually sending DNS requests.

While the problem is occurring,  go to Controller-->Tools-Network Trace and set the following parameters (below) and start the trace.

(Port selection will depend on the route path of the DNS requests).
The results will show only DNS requests and responses to/from upstream.  If it only shows DNS requests, then something upstream is blocking the DNS requests.

Collect the trace (Save as PCAP) and contact your network administrator and provide the trace proof that the MSM is sending valid DNS requests, and getting no responses.

The administrator may be able to raise or defeat the DNS threshold limits and solve the problem.

 

 DNS responses are not getting back to the MSM controller, or to the users - 

The Upstream network needs an a return route to a know subnet.

This is usually accomplished by assigning a valid subnet IP (of the upstream network to the Internet port.

Next, make sure that NAT is enabled on the Internet port, (so as to hide the wireless user's subnet)

All users traffic will be NATed by the IP address assigned to the Internet port.

The upstream network will then be able to find this Internet port IP and forward responses to it.

 

 Not enabling DNS Interception - 

When DNS Interception is enabled, all wireless user DNS requests will be intercepted by the MSM and forwarded to the configured DNS addresses.

If DNS Interception is disabled, then the wireless user DNS requests will be routed out the default route, using the user's assigned DNS address.

However, when a user gets a private DHCP address, they also get a private DNS address.

But when the user tries to use this private DNS address routed out the MSM, the upstream network will not recognize it.

Make sure that DNS Interception is enabled to avoid this problem.

Version history
Revision #:
1 of 1
Last update:
‎05-13-2019 01:38 PM
Updated by:
 
Comments

Can you please clarify re "DNS Interception" on legacy (but still not EoS) HP MSM Wireless controllers

I noticed that when DNS Interception enabled it resolves all names to 123.123.123.123. This is discussed in few forums. Apparently this IP owned by China Telecom and blocked on some antiviruses. It is also hardcoded and one can not change it. Is there any good reason for keeping DNS Interception for central switched guest net? We only got WPA pass as a control and no HTTP splash page. All we want for guests is to have internet and no LAN.

 


@esupport wrote:

 

 Not enabling DNS Interception - 

When DNS Interception is enabled, all wireless user DNS requests will be intercepted by the MSM and forwarded to the configured DNS addresses.

If DNS Interception is disabled, then the wireless user DNS requests will be routed out the default route, using the user's assigned DNS address.

However, when a user gets a private DHCP address, they also get a private DNS address.

But when the user tries to use this private DNS address routed out the MSM, the upstream network will not recognize it.

Make sure that DNS Interception is enabled to avoid this problem.


 

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: