WiNG 5.9 DHCP on VLAN660 response inconsistent
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎09-14-2018 10:53 AM
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.
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.
6 REPLIES 6
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎09-28-2018 04:25 AM
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎09-17-2018 06:07 PM
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 Misha
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎09-17-2018 06:07 PM
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎09-14-2018 11:42 AM
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
dhcp-offer-convert
if the packet is already unicast, nothing will happen to the packet
regards
Andy
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
dhcp-offer-convert
if the packet is already unicast, nothing will happen to the packet
regards
Andy
