WiNG 5.9 DHCP on VLAN660 response inconsistent

  • 0
  • 1
  • Question
  • Updated 2 months ago
  • Answered
I have a question about our NX5500 with WiNG 5.9
We have configured 3 VLANs with 2 of them working fine with a DHCP scope on a Juniper firewall. The 3rd VLAN has a DHCP scope on a Linksys router and this one is not performing consistently. We do get the occasional address if we're lucky but at least 75% of the request from a phone for instance fails.
Our partner has now implemented the following solution: it will let the AP's request a DHCP address on this VLAN and now all request are working fine.
But there's a drawback; now I can see the web-interface of all the AP7532's showing in a network scan. There's no danger as we cannot log on to the web-interface, luckily.
Would there be another solution to stabilize the DHCP service in this specific VLAN without serving the AP's an IP address?
How about adding a route in this specific VLAN to the gateway serving the DHCP addresses? 
You're thoughts on this are very much appreciated.
Photo of Ronald Groenewegen

Ronald Groenewegen

  • 366 Points 250 badge 2x thumb

Posted 2 months ago

  • 0
  • 1
Photo of Andrew Blomley

Andrew Blomley, Employee

  • 1,112 Points 1k badge 2x thumb
There is no requirement to add a virtual interface on the access point. 

The issue is the linksys router which is using broadcast as a method to issue DHCP address, compared to unicast of the Juniper firewall.

if you edit the firewall rules on the AP (below is from our best practice) you will see a dhcp offer convert 

this converts DHCP packets from broadcast to unicast  

firewall-policy default 
no ip dos smurf
no ip dos twinge
no ip dos invalid-protocol
no ip dos router-advt
no ip dos router-solicit
no ip dos option-route
no ip dos ascend
no ip dos chargen
no ip dos fraggle
no ip dos snork
no ip dos ftp-bounce
no ip dos tcp-intercept
no ip dos broadcast-multicast-icmp
no ip dos land
no ip dos tcp-xmas-scan
no ip dos tcp-null-scan
no ip dos winnuke
no ip dos tcp-fin-scan
no ip dos udp-short-hdr
no ip dos tcp-post-syn
no ip dos tcphdrfrag
no ip dos ip-ttl-zero
no ip dos ipspoof
no ip dos tcp-bad-sequence
no ip dos tcp-sequence-past-window
no ip-mac conflict
no ip-mac routing conflict

if the packet is already unicast, nothing will happen to the packet 


Photo of Ronald Groenewegen

Ronald Groenewegen

  • 366 Points 250 badge 2x thumb
Thanks Andy, I will have a look at your suggestion next week and report back.
Photo of Ronald Groenewegen

Ronald Groenewegen

  • 366 Points 250 badge 2x thumb
Hi Andy, I've checked our config and we have had the DHCP broadcast to unicast option enabled from the beginning so this is not a fix for us.
Do you happen to have any other suggestions?
Photo of Michael (Misha) Elin

Michael (Misha) Elin, SE

  • 658 Points 500 badge 2x thumb
Hello Ronald,

1. Like Andy already mentioned there is no reason to have more than one IP address on AP.
2. In case you're mixing APs with regular clients in a same VLAN (not recommend) there is a best practice to have a separate management policy in APs profile with "no https server"
3. Please check "service show dhcp-lease" to make sure the "incorrect" address was served from linksys but not other DHCP occasionally serving the same VLAN

Photo of Ronald Groenewegen

Ronald Groenewegen

  • 366 Points 250 badge 2x thumb
Hi Misha,

1. I agree but this has stabilized our DHCP config so I'm looking for the correct solution.
2. I will look into this. I guess this should shield the internal webserver so definitely interesting.
3. I don't have any incorrect addresses, it's just failing to renew the adres.

Regards, Ronald.
Photo of Ronald Groenewegen

Ronald Groenewegen

  • 366 Points 250 badge 2x thumb

Hi Andrew, Misha,

Thanks again for you input.
It seems there was some misunderstanding about the purpose of the DHCP addresses on the VLAN.
It did not influence the DHCP requests at all so I have disabled the option.
Now my DHCP still works fine on VLAN660 and the access points don't require an address form this network anymore.
#case solved.

Regards, Ronald.