Blind DHCP server

PeterUKPeterUK Member Posts: 634  Guru Member
edited June 18, 2019 11:52PM in ZyWALL USG Series

Ok I have a interesting setup using NETGEAR M4100-D12G and Mirror Interface ACL (nothing like you do for your switches) with a USG 40 doing server DHCP to a LAN on ZyWALL 110 WAN that the USG 40 is not directly on with the ZyWALL 110 as the virtual gateway for clients of a wireless AP setup.

Ok here's the thing it works right up until it try to renew the IP which fails because the USG 40 would like to ARP the client which it can't do. But oddly the client sends Discover you get a offer then request and ACK and off the client goes working. But between that time the connection is lost with packet loss till its up and running again.

Would it be possible to disable the ARP check on DHCP renew? I know that my ISP DHCP does not do ARP check on DHCP renew so I'm thinking its possible.

My current workaround is just have the lease set to infinite.

Thanks

«1

Comments

  • zyman2008zyman2008 Member Posts: 91  Ally Member

    Here are the CLI to disable it,

    Router(config)# no ip dhcp arp_check

    Disable DHCP check with arp.

    Router(config)# show ip dhcp arp_check

    DHCP check with arp query: no

    Router(config)# write

  • PeterUKPeterUK Member Posts: 634  Guru Member

    Thanks but it seems its set to no already when I put in:

    show ip dhcp arp_check

    It says

    DHCP check with arp query: no

  • PeterUKPeterUK Member Posts: 634  Guru Member

    Well I think I worked around it.

    What I did was make a VLAN67 as a general interface type on the USG40 with the MAC the same as the virtual gateway 192.168.254.1 on the ZyWALL 110 and with the NETGEAR M4100-D12G Mirror Interface ARP of clients like who has 192.168.254.1 tell 192.168.254.3 to the VLAN67 on the USG40 but not send ARP from the USG40 with 192.168.254.1 is at MAC as the virtual gateway on the ZyWALL 110 does that.

    But interestingly I'm not sending the ARP who has 192.168.254.3 tell 192.168.254.1 by the USG 40 to the client just the getting the ARP for who has 192.168.254.1 tell 192.168.254.3 is enough to make the renew work.

  • Zyxel_StanleyZyxel_Stanley Zyxel Official Agent Posts: 718  mod

    Hi @PeterUK

    It’s good to know you found the workaround in your environment.

    Would you share detail information of your Interface and switch setting?

    Maybe we can learn more explanation from it.

  • PeterUKPeterUK Member Posts: 634  Guru Member

    I might do that but its a lot of config.

    But one question about the packet capture above is why the USG is not replying to DHCP request for a renew? It has the source MAC to reply to but it seem to need either a who has 192.168.254.1 tell 192.168.254.3 or who has 192.168.254.3 tell 192.168.254.1 but surely the DHCP server can work with needing that.

  • PeterUKPeterUK Member Posts: 634  Guru Member
    edited June 21, 2019 3:17AM

    Theirs a oddness with proxy arp in this setup due to a routeing rule which is needed and likely nothing can be done but it some what works just not the way it would ideally work like my other setup here.

    https://businessforum.zyxel.com/discussion/comment/8229/#Comment_8229

    I have a AP with Wireless Client Security Separation with proxy arp on the Zywall 110 so clients can connect to each other.

    Heres what happens from the Zywall 110 packet capture on OPT interface when my phone 192.168.254.2 pings 192.168.254.3 PC

    From PC

    routing rule

    If the next hop was diffarent then incoming interface then the PC would see ping from 192.168.254.2 and not 192.168.254.1. But the rule is needed for clients to get internet.

  • PeterUKPeterUK Member Posts: 634  Guru Member
    edited June 21, 2019 10:15PM

    So this is some of the setup that will work but I got real DMZ setup so incoming traffic would come by the bridge and not OPT but the setup works without needing real DMZ.

    Edit Solved the ARP proxy oddness by adding another routing rule have updated image.

  • Zyxel_StanleyZyxel_Stanley Zyxel Official Agent Posts: 718  mod

    Hi @PeterUK  

    Thanks for shared your configuration and scenario of it.

    According to your question, USG40 DHCP serve will send ARP request before reply DHCP ACK to client when ARP table has expired.


    Current DHCP server behavior will consider clients and servers are able communicating bidirectional(See my lab testing packet capture below).

    From the packet screenshot you shared, it seems the broadcast/ ARP can’t be forwarded to each other for some reason

    So we suspect that after adding the additional Proxy ARP server, the USG110 will help to forward the ARP packets through your environment to the USG40 and the USG40 did receive the replied packet, then it works afterward. 


  • PeterUKPeterUK Member Posts: 634  Guru Member
    edited June 22, 2019 4:03AM

    No the proxy ARP has nothing to do with DHCP ARP problem I solved it with the NETGEAR M4100-D12G Mirror Interface of ARP packets of clients that do who has 192.168.254.1 tell 192.168.254.3 to the VLAN67 for USG 40 under the same MAC as the OPT on the ZyWALL 110. Like I said the USG40 is not directly on the LAN with the ZyWALL 110 WAN as the virtual gateway for clients of a wireless AP setup so I Mirror Interface of ARP to the USG40 to keep the DHCP server happy.

    You don't need to send who has 192.168.254.3 tell 192.168.254.1 to the clients from the DHCP server just the clients on AP who has 192.168.254.1 tell 192.168.254.3 to the DHCP server will be fine.

    The reason your seeing 192.168.254.2 is at MAC is the Virtual interface 192.168.254.1 on the ZyWALL 110 is sending the who has 192.168.254.2 tell 192.168.254.1 and the NETGEAR M4100-D12G Mirror Interface the ARP packets from clients of a wireless AP to the VLAN67 but never do a Mirror Interface the ARP packets to the clients from the USG40.

  • PeterUKPeterUK Member Posts: 634  Guru Member

    But on another note what is “no ip dhcp arp_check” meant to do? Because to me its still doing the ARP check DHCP should be DHCP only not we need to ARP check the DHCP.

Sign In to comment.