Link to home
Start Free TrialLog in
Avatar of Joel Sexton
Joel SextonFlag for United States of America

asked on

How do I get Windows DHCP server to bind to a second NIC/IP to respond to requests?

We are troubleshooting an IP Helper issue through a Sonicwall TZ500.  It's not consistently relaying DHCP requests to the AD server on a different subnet as the wireless clients. 

We enabled a second NIC in the AD server (2019 Server) and put it on the same VLAN as the wireless network having issues and plugged it into an untagged port in that VLAN.  The server, though, would not respond do DHCP requests on this NIC, as the DHCP server doesn't give the option to bind to this new NIC/IP.

My question is: "How do I get the DHCP server to bind to that NIC/IP to respond to requests?"

Avatar of Craig Beck
Craig Beck
Flag of United Kingdom of Great Britain and Northern Ireland image

In the DHCP Management console, if you right-click on the DHCP server and click "Add/Remove Bindings..." do you get the option to bind to the NIC?
There is no need for that, as that will make this server on two segments.

Commonly this is handled by configuring DHCP relay agents, ip helpers on the switches (level 3) or the firewall to forward DHCP requests from different segments to this DHCP server with ine IP and multiple scopes.
ASKER CERTIFIED SOLUTION
Avatar of Craig Beck
Craig Beck
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Joel Sexton

ASKER

In the Add/Remove Bindings window, I only see the original NIC in the server, not the second one.  This is even after a full reboot of the server.
Sonicwalls do DHCP like garbage in my experience, even the large NSA models.  We have the IP Helper set up there, but it's not consistent.  We can see the DHCP requests coming from the device through the AP and the switch and into the Sonicwall, but they don't end up at the server sometimes.  It's causing intermittency on the clients.
Also, all the switches in this environment are layer 2 only.  I'm getting a layer 3 switch to potentially use as another approach to fixing the issue.
Does the firewall have DHCP relay agent configured on the secobd segment?
Multi segment setup, you either have a DHCP relay agent/ip helper configured on the other segment or you don't

The presence of an ip helper/DHCP relay agent but a failure to get an Ip points to the firewall does it allow DHCP/bootp from the second segment to the DHCP server?

Debugging on the Firewall DHCP traffic to the DHCP server, wireshark on the server.
Access-list on the firewall, vlan, vlan ACL on the switch.....
AP? Does it have DHCP relay agent/ip helper configured?
What ip segment the ap is on, does it have the vlans to match the firewall?
Is the feed from the switch to the AP configured as a trunk passing all vlans?
Does the firewall have DHCP relay agent configured on the secobd segment?
     Yes
Multi segment setup, you either have a DHCP relay agent/ip helper configured on the other segment or you don't
     It's configured on the firewall, but the behavior is intermittent.

The presence of an ip helper/DHCP relay agent but a failure to get an Ip points to the firewall does it allow DHCP/bootp from the second segment to the DHCP server?
     About 30-50% of the time, it does.

Debugging on the Firewall DHCP traffic to the DHCP server, wireshark on the server.
     Done this.  That's how we narrowed down the issue to the firewall.
Access-list on the firewall, vlan, vlan ACL on the switch.....
     ACLs, VLANs on switch and firewall are correct.  The firewall is the default gateway for these VLANs.

AP? Does it have DHCP relay agent/ip helper configured?
     IP Helper/DHCP Relay is on the firewall (Sonicwall TZ500)
What ip segment the ap is on, does it have the vlans to match the firewall?
     In our case, the wifi network in question is VLAN 25 and it exists on the APs, Switches and Firewall.
Is the feed from the switch to the AP configured as a trunk passing all vlans?  
     Yes.  It is.
Confirm whether the connection to the AP is a trunk that passes all relavent traffic for the VLANS that supposed to exist there.
firewall trunk to switch trunk to the AP
at each point the VLANs that exist on the firewall, have to exist on the switch and have to exist on the AP.

Depending on your AP, it might be better if the IP helpers are defined there versus on the firewall.

Are the AP connection configured for 802.1x that distributes/assigns the devices connecting into the correct scope/vlan?
I have confirmed the VLANs existence on all relevant equipment, as this is an existing installation.  I've confirmed these items on your last post.  
These APs don't have the option for an IP Helper on them directly.  I'm using Ruckus R610s in an Unleashed configuration.  
We are not using 802.1x, just PSK and static VLANs.
the AP is connected to a switch that is tagged with the VLAN to which devices connected to this AP will be members of ?

If you connect a computer to this switch and the port is setup for the wireless VLAN, does it get the correct IP if at all?

You saying sometimes you have an issue. is it with different AP's or same IP at different times?

Meaning user A has one set SSID/PSK and can only connect to one of your APs in a specific location?
It can happen to the same device/AP/SSID within the span of minutes.  A user might connect successfully, then disconnect and reconnect to the same AP/SSID and not get an address.  

I've had this sort of issue with Sonicwalls not doing DHCP serving well before, so I am trying to find a way to remove it from that equation without a huge network redesign.
I actually have not tried the test you mentioned of untagging a physical port and testing with a PC on that VLAN.  I will try that tomorrow and see if there is the same intermittency.
The port on the switch should be tagged. And the computer should not have any changes to its network interface made.

Cursory view of the AP spc, they list types where they can be used,, did not go too far in the documents whether the environment in which they can be used a redefined vlans on the AP or merely descriptors of where they can be placed.


If you configure firewall DHCP on one of the VLANs does that resolve the issue?
If the DHCP server interface is connected directly to the switch port and it doesn't have any 802.1Q configuration, the switch port should NOT be tagged. It should be untagged.

If the AP has VLANs for different SSIDs configured the switch port should be tagged with the VLAN IDs of the SSIDs and untagged for the AP itself unless you specify that the AP management interface should be tagged.

Untagging a port on the switch to test is a good test to try. It will help determine whether the issue exists for a wired client. If it doesn't, look at the wireless setup instead.

In the Add/Remove Bindings window, I only see the original NIC in the server, not the second one.  This is even after a full reboot of the server.
Have you assigned a static IP to the second NIC on the DHCP server?
Arnold,
Running DHCP from the firewall is worse in this case than using IP Helper to do it off the DC.  That was how we had it before and the intermittency was worse, which has been my experience on this brand of firewall in the past.

Craig,
We have assigned a static IP on the second NIC on the DHCP server and attached it to an untagged port in VLAN 25.  It's pingable from other clients on that same subnet, so we know traffic is getting through, but no DHCP offers are being sent out through the port.
The issue is to identify where the issue is.
You have a level 2 switch if not mistaken, that would suggest that it should flow to the IP helper setup on the VLAN.
the issue was whether the VLAN is part of the AP or just on the L2 switch when the port identified accordingly.

If you are relying on having the system connecting to the AP tagging the VLAN on its interface, that might be where your issue is. but you noted in a few comments earlier that you do not use 802.1x so the intermittent issue has to be looked to see where it is comming from, is it isolated to a specific AP/VLAN/switch port config....

If you have multiple AP, and the issue is not identified as tracing back to one AP, Switch, etc. it is impossible to solve as you never know whether solving it for one, wrecks it for another....
I have checked the tagging for the VLANs on all of the APs and all of the ports the APs are plugged into.  Tagging isn't an issue since it works sometimes on the same AP/Port combination sometimes and sometimes doesn't.  The DHCP request packets stop at the firewall and don't get forwarded onto the AD server's subnet when the failure occurs.  The firewall is where the failure occurs because the packets end up hitting the firewall on the proper port even when the DHCP request fails.
Am I interpreting it correctly, the firewall's DHCP relay agent/ip helper gets overwhelmed with requests?
Does the issue get resolved when you reset the ip helper on the firewall?

Debugging the ip helper to see whether the DHCP broadcasts are saturating the capacity of the firewall to forward.
How many vlans/ip helpers are defined?
After some amount of time, the binding showed up in the DHCP server on the Windows Server and is working now.  I disabled IP Helper on the Sonicwall and the requests are flowing well and the wifi is working great now.