Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
11495
Views
15
Helpful
13
Replies

Client Not Receiving DCHP Offer

Go to solution
tresdodi
Level 1
Level 1

‎12-24-2021 09:00 AM - edited ‎12-24-2021 09:07 AM

Hello. I'd appreciate any assistance solving the following problem. This is a basic layout of the network:

EDIT: I'm working with real devices, not on Packet Tracer.

 

Capture.JPG

 

Wireless clients on VLAN 200 obtain IPs from a DHCP server on VLAN 1 through a router acting as DHCP relay. Oddly, one of the clients won't receive the DHCP Offer. I verified that the DHCP server receives the DHCP Discover and replies with the DHCP Offer, which makes it through the router. But the WLC debugging does not show the offer; only continuous DCHP Discover from the client:

>debug client D0:73:D5:02:63:B9
[...]
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP received op BOOTREQUEST (1) (len 556,vlan 1, port 1, encap 0xec03)
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP   xid: 0x8d5347e7 (2371045351), secs: 0, flags: 8000
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP   chaddr: d0:73:d5:02:63:b9
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:28:56.694: d0:73:d5:02:63:b9 DHCP successfully bridged packet to DS
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP received op BOOTREQUEST (1) (len 556,vlan 1, port 1, encap 0xec03)
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP   xid: 0x8d5347e7 (2371045351), secs: 0, flags: 8000
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP   chaddr: d0:73:d5:02:63:b9
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:29:00.091: d0:73:d5:02:63:b9 DHCP successfully bridged packet to DS
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP received op BOOTREQUEST (1) (len 556,vlan 1, port 1, encap 0xec03)
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP   xid: 0x8d5347e7 (2371045351), secs: 0, flags: 8000
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP   chaddr: d0:73:d5:02:63:b9
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:29:08.819: d0:73:d5:02:63:b9 DHCP successfully bridged packet to DS
...

 

The router passes the DHCP Discover through the Zone-Based Firewall and handles the Offer reply from the server. The entry "FIBipv4-packet-proc: packet routing failed" seems noteworthy but the same whole sequence is registered for another clients that get DHCP fine.

#access-list 10 permit 192.168.1.14
#debug ip packet detail 10
Dec 24 10:29:04.430 EST: %FW-6-PASS_PKT: (target:class)-(IOT-SELF_ZP:DHCP_REQUEST_CMAP) Passing udp pkt 0.0.0.0:68 => 255.255.255.255:67 with ip ident 1
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, input feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Common Flow Table(5), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, input feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Stateful Inspection(8), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, input feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Ingress-NetFlow(35), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, input feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Virtual Fragment Reassembly(39), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, input feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Virtual Fragment Reassembly After IPSec Decryption(57), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, input feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, MCI Check(109), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: FIBipv4-packet-proc: route packet from Vlan1 src 192.168.1.14 dst 192.168.200.1
Dec 24 15:29:04.430: FIBfwd-proc: Default:192.168.200.1/32 receive entry
Dec 24 15:29:04.430: FIBipv4-packet-proc: packet routing failed
Dec 24 15:29:04.430: IP: tableid=0, s=192.168.1.14 (Vlan1), d=192.168.200.1 (Vlan200), routed via RIB
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1 (Vlan200), len 328, output feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, NAT Inside(8), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1 (Vlan200), len 328, output feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Common Flow Table(29), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1 (Vlan200), len 328, output feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, Stateful Inspection(30), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, rcvd 4
Dec 24 15:29:04.430:     UDP src=67, dst=67
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, stop process pak for forus packet
Dec 24 15:29:04.430:     UDP src=67, dst=67
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, enqueue feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, CCE post NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
Dec 24 15:29:04.430: IP: s=192.168.1.14 (Vlan1), d=192.168.200.1, len 328, enqueue feature
Dec 24 15:29:04.430:     UDP src=67, dst=67, CCE Firewall(3), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
...

 

Wireshark capture on the DHCP server:

258	2021-12-24 10:29:02.434256	192.168.200.1	192.168.1.14	DHCP	590	DHCP Discover - Transaction ID 0x8d5347e7
259	2021-12-24 10:29:02.434529	192.168.1.14	192.168.200.1	DHCP	342	DHCP Offer    - Transaction ID 0x8d5347e7
308	2021-12-24 10:29:05.831715	192.168.200.1	192.168.1.14	DHCP	590	DHCP Discover - Transaction ID 0x8d5347e7
309	2021-12-24 10:29:05.831867	192.168.1.14	192.168.200.1	DHCP	342	DHCP Offer    - Transaction ID 0x8d5347e7
563	2021-12-24 10:29:14.560057	192.168.200.1	192.168.1.14	DHCP	590	DHCP Discover - Transaction ID 0x8d5347e7
564	2021-12-24 10:29:14.560198	192.168.1.14	192.168.200.1	DHCP	342	DHCP Offer    - Transaction ID 0x8d5347e7
...

I'm at a loss because it looks like the router is sending the DHCP offer to the client network but the WLC does not register it, which apparently means that the packet is not making it to the client network.

Labels:
1 Accepted Solution

Accepted Solutions

Go to solution
tresdodi
Level 1
Level 1

‎01-17-2022 07:40 PM

Solved!

After the above, I had a hunch that this was some kind of interoperational bug between ZBFW and DHCP relay. Then I found DHCP Client or Server with ZBF Router Configuration, which prompts to pass DHCP requests and replies from and to the router when working with the built-in DHCP server or when the router is a DHCP client. It also refers to bug  CSCso53376 - ZBF inspect doesn't work for broadcast traffic which succinctly states that "ZBF with DHCP currently does not work" and the solution is to "manually allow DHCP [...] from and to the router."

So, I modified the policy between the self and the Iot zone (where the lightbulb is) to pass DHCP reply and the problem was resolved instantly, meaning that the bulb successfully got an IP after the DHCP offer broadcasted by the relay made it to it through the ZBFW. The previous policy only inspected everything and curiously, clients that set the bootp flags on the DHCP Discovery to Unicast always worked fine, which happened to be all the devices I had had. As soon as I brought the Lifx bulb, which sets the flags to Broadcast, I hit the bug.

This is the working config now:

ip access-list standard PERMIT_ANY
permit any
ip access-list extended DHCP_REPLY
 permit udp any any eq bootpc

policy exists on zp SELF-IOT_ZP
  Zone-pair: SELF-IOT_ZP

  Service-policy inspect : PASS_DHCP_REPLY_AND_INSPECT

    Class-map: DCHP_REPLY_CMAP (match-any)
      Match: access-group name DHCP_REPLY
        4 packets, 1232 bytes
        30 second rate 0 bps
      Pass
        4 packets, 1232 bytes

    Class-map: ALL_TRAFFIC_CMAP (match-any)
      Match: access-group name PERMIT_ANY
        0 packets, 0 bytes
        30 second rate 0 bps

   Inspect

    Class-map: class-default (match-any)
      Match: any
      Drop
        0 packets, 0 bytes

View solution in original post

13 Replies 13

Go to solution
Georg Pauwen
VIP
VIP

‎12-24-2021 09:05 AM - last edited on ‎01-18-2022 01:39 AM by Community Manager

Hello,

 

post your "zipped Packet Tracer project (.pkt)" file...

0 Helpful

Go to solution
tresdodi
Level 1
Level 1
In response to Georg Pauwen

‎12-24-2021 09:08 AM

Hello Georg. Sorry, I didn't clarify that I'm working with real devices, not with Packet Tracer.

Go to solution
Georg Pauwen
VIP
VIP
In response to tresdodi

‎12-24-2021 09:13 AM

Hello,

 

sorry about that, you mentioned that in your post. The 'problem' client is the mobile device on Vlan 200 ?

 

Can you post the running config of the router ?

0 Helpful

Go to solution
tresdodi
Level 1
Level 1
In response to Georg Pauwen

‎12-24-2021 09:28 AM

Here's the router config:

 

Router1941#sh run
Building configuration...


Current configuration : 11593 bytes
!
! Last configuration change at 01:38:32 EST Fri Dec 24 2021 by <elided>
! NVRAM config last updated at 15:09:00 EST Thu Dec 23 2021 by <elided>
!
version 15.8
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Router1941
!
boot-start-marker
boot-end-marker
!
!
enable secret 5 <elided>
!
no aaa new-model
clock timezone EST -5 0
clock summer-time DST recurring
!
!
!
!
!
!
no ip source-route
ip options drop
!
!
!
ip dhcp bootp ignore
!
!
!
no ip bootp server
no ip domain lookup
ip domain name <elided>
ip name-server 192.168.1.14
ip name-server 9.9.9.9
ip name-server 149.112.112.112
ip name-server 1.1.1.1
ip cef
login block-for 120 attempts 3 within 60
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
license udi pid CISCO1941/K9 sn <elided>
license boot module c1900 technology-package securityk9
!
!
memory reserve critical 5
memory reserve console 4096
memory free low-watermark processor 10
memory free low-watermark IO 10
username <elided> secret 9 <elided>
!
redundancy
!
!
!
!
!
!
class-map type inspect match-any ALL_TRAFFIC_CMAP
 match access-group name PERMIT_ANY
class-map type inspect match-any ALLOWED_DNS_CMAP
 match access-group name WWW_OPENDNS
class-map type inspect match-any HOME-IOT_CMAP
 match access-group name HOME-IOT
class-map type inspect match-any WAN-HOME_CMAP
 match access-group name WAN-HOME
class-map type inspect match-any DHCP_REQUEST_CMAP
 match access-group name DHCP_REQUEST
class-map type inspect match-any DCHP_REPLY_CMAP
 match access-group name DHCP_REPLY
class-map type inspect match-any WAN-IOT_CMAP
 match access-group name WAN-IOT
class-map type inspect match-any UNTRUSTED_VLAN-SELF_CMAP
 match access-group name PERMIT_PING_GATEWAY
class-map type inspect match-any GUEST_WIFI-HOME_CMAP
 match access-group name GUEST_WIFI-HOME
!
policy-map type inspect UNTRUSTED_VLAN-SELF_PMAP
 description Passes DHCP requests, inspects ICMP and drops everything else.
 class type inspect DHCP_REQUEST_CMAP
  pass log
 class type inspect UNTRUSTED_VLAN-SELF_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect WAN-IOT_PMAP
 class type inspect WAN-IOT_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect SELF-WAN_PMAP
 description Passes DHCP requests and inspects everything else.
 class type inspect DHCP_REQUEST_CMAP
  pass
 class type inspect ALL_TRAFFIC_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect WAN-HOME_PMAP
 class type inspect WAN-HOME_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect DHCP_REPLY_PMAP
 description Passes DHCP replies.
 class type inspect DCHP_REPLY_CMAP
  pass log
 class class-default
  drop log
policy-map type inspect GUEST_WIFI-HOME_PMAP
 class type inspect GUEST_WIFI-HOME_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect INSPECT_ALL_PMAP
 class type inspect ALL_TRAFFIC_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect HOME-IOT_PMAP
 class type inspect HOME-IOT_CMAP
  inspect
 class class-default
  drop log
policy-map type inspect GUEST_WIFI-WAN_PMAP
 description Permits all Internet except DNS Over TLS (DOT) and non-OpenDNS.
 class type inspect ALLOWED_DNS_CMAP
  inspect
 class class-default
  drop log
!
zone security WAN
zone security HOME
zone security GUEST_WIFI
zone security CAMERAS
zone security IOT
zone-pair security SELF-WAN_ZP source self destination WAN
 service-policy type inspect SELF-WAN_PMAP
zone-pair security WAN-SELF_ZP source WAN destination self
 service-policy type inspect DHCP_REPLY_PMAP
zone-pair security HOME-WAN_ZP source HOME destination WAN
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security WAN-HOME_ZP source WAN destination HOME
 service-policy type inspect WAN-HOME_PMAP
zone-pair security HOME-SELF_ZP source HOME destination self
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security SELF-HOME_ZP source self destination HOME
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security GUEST_WIFI-SELF_ZP source GUEST_WIFI destination self
 service-policy type inspect UNTRUSTED_VLAN-SELF_PMAP
zone-pair security SELF-GUEST_WIFI_ZP source self destination GUEST_WIFI
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security GUEST_WIFI-WAN_ZP source GUEST_WIFI destination WAN
 service-policy type inspect GUEST_WIFI-WAN_PMAP
zone-pair security SELF-CAMERAS_ZP source self destination CAMERAS
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security CAMERAS-SELF_ZP source CAMERAS destination self
 service-policy type inspect UNTRUSTED_VLAN-SELF_PMAP
zone-pair security HOME-CAMERAS_ZP source HOME destination CAMERAS
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security GUEST_WIFI-HOME_ZP source GUEST_WIFI destination HOME
 service-policy type inspect GUEST_WIFI-HOME_PMAP
zone-pair security HOME-GUEST_WIFI_ZP source HOME destination GUEST_WIFI
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security IOT-SELF_ZP source IOT destination self
 service-policy type inspect UNTRUSTED_VLAN-SELF_PMAP
zone-pair security SELF-IOT_ZP source self destination IOT
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security IOT-WAN_ZP source IOT destination WAN
 service-policy type inspect INSPECT_ALL_PMAP
zone-pair security HOME-IOT_ZP source HOME destination IOT
 service-policy type inspect HOME-IOT_PMAP
zone-pair security WAN-IOT_ZP source WAN destination IOT
 service-policy type inspect WAN-IOT_PMAP
!
!
!
!
!
!
!
!
!
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 description WAN
 ip address dhcp client-id GigabitEthernet0/0
 no ip redirects
 ip nat outside
 ip virtual-reassembly in
 zone-member security WAN
 duplex auto
 speed auto
 no cdp enable
 no mop enabled
!
interface GigabitEthernet0/1
 no ip address
 ip virtual-reassembly in
 shutdown
 duplex auto
 speed auto
 no mop enabled
!
interface GigabitEthernet0/0/0
 description Home
 switchport mode access
 no ip address
 zone-member security HOME
!
interface GigabitEthernet0/0/1
 description Cameras
 switchport access vlan 70
 switchport mode access
 no ip address
 zone-member security CAMERAS
!
interface GigabitEthernet0/0/2
 description Guest WiFi
 switchport access vlan 250
 switchport mode access
 no ip address
 zone-member security GUEST_WIFI
!
interface GigabitEthernet0/0/3
 description Iot
 switchport access vlan 200
 switchport mode access
 no ip address
 zone-member security IOT
!
interface Vlan1
 description Home
 ip address 192.168.1.1 255.255.255.0
 ip helper-address 192.168.1.14
 ip flow ingress
 ip flow egress
 ip nat inside
 ip virtual-reassembly in
 zone-member security HOME
!
interface Vlan70
 description Cameras
 ip address 192.168.70.1 255.255.255.0
 ip helper-address 192.168.1.14
 ip flow ingress
 ip flow egress
 ip nat inside
 ip virtual-reassembly in
 zone-member security CAMERAS
!
interface Vlan200
 description Iot
 ip address 192.168.200.1 255.255.255.0
 ip helper-address 192.168.1.14
 ip flow ingress
 ip flow egress
 ip nat inside
 ip virtual-reassembly in
 zone-member security IOT
!
interface Vlan250
 description Guest WiFi
 ip address 192.168.250.1 255.255.255.0
 ip helper-address 192.168.1.14
 ip flow ingress
 ip flow egress
 ip nat inside
 ip virtual-reassembly in
 zone-member security GUEST_WIFI
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip flow-export version 9
ip flow-export destination 192.168.1.116 11839
!
ip nat inside source list NAT interface GigabitEthernet0/0 overload
ip nat inside source static tcp 192.168.1.99 <elided> interface GigabitEthernet0/0 <elided>
ip nat inside source static udp 192.168.1.24 <elided> interface GigabitEthernet0/0 <elided>
ip nat inside source static udp 192.168.1.25 <elided> interface GigabitEthernet0/0 <elided>
ip nat inside source static tcp 192.168.1.112 <elided> interface GigabitEthernet0/0 <elided>
ip nat inside source static udp 192.168.1.118 <elided> interface GigabitEthernet0/0 <elided>
ip nat inside source static tcp 192.168.200.10 <elided> interface GigabitEthernet0/0 <elided>
ip ssh authentication-retries 5
ip ssh version 2
!
ip access-list standard NAT
 remark
 remark Permit Home VLAN
 permit 192.168.1.0 0.0.0.255
 remark Permit Guest WiFi VLAN
 permit 192.168.250.0 0.0.0.255
 remark Permit Iot VLAN
 permit 192.168.200.0 0.0.0.255
ip access-list standard PERMIT_ANY
 permit any
!
ip access-list extended DHCP_REPLY
 permit udp any any eq bootpc
ip access-list extended DHCP_REQUEST
 permit udp any any eq bootps
ip access-list extended GUEST_WIFI-HOME
 permit tcp 192.168.250.0 0.0.0.255 host 192.168.1.99 eq <elided>
 permit tcp 192.168.250.0 0.0.0.255 host 192.168.1.112 eq <elided>
ip access-list extended HOME-IOT
 permit tcp 192.168.1.0 0.0.0.255 host 192.168.200.10 eq <elided>
 permit tcp 192.168.1.0 0.0.0.255 host 192.168.200.10 eq <elided>
 permit tcp 192.168.1.0 0.0.0.255 host 192.168.200.10 eq <elided>
 permit tcp 192.168.1.0 0.0.0.255 host 192.168.200.10 eq <elided>
ip access-list extended PERMIT_PING_GATEWAY
 remark Allow ping gateway from Guest Wifi VLAN
 permit icmp 192.168.250.0 0.0.0.255 host 192.168.250.1
 remark Allow ping gateway from Cameras VLAN
 permit icmp 192.168.70.0 0.0.0.255 host 192.168.70.1
 remark Allow ping gateway from Iot VLAN
 permit icmp 192.168.200.0 0.0.0.255 host 192.168.200.1
ip access-list extended WAN-HOME
 permit tcp any host 192.168.1.99 eq <elided>
 permit udp any host 192.168.1.118 eq <elided>
 permit udp any host 192.168.1.24 eq <elided>
 permit udp any host 192.168.1.25 eq <elided>
 permit tcp any host 192.168.1.112 eq <elided>
ip access-list extended WAN-IOT
 permit tcp any host 192.168.200.10 eq <elided>
ip access-list extended WWW_OPENDNS
 remark Allow Internet only with OpenDNS
 permit udp any host 208.67.222.222 eq domain
 permit tcp any host 208.67.222.222 eq domain
 permit udp any host 208.67.220.220 eq domain
 permit tcp any host 208.67.220.220 eq domain
 permit udp any host 208.67.222.220 eq domain
 permit tcp any host 208.67.222.220 eq domain
 permit udp any host 208.67.220.222 eq domain
 permit tcp any host 208.67.220.222 eq domain
 remark Permit work laptop to use any DNS.
 permit udp host 192.168.250.54 any eq domain
 permit tcp host 192.168.250.54 any eq domain
 remark Block DNS Over TLS (DOT). (DOH can't be blocked because uses 443)
 deny   udp any any eq domain 853
 deny   tcp any any eq domain 853
 permit ip any any
!
logging host 192.168.1.22
!
!
access-list 10 permit 192.168.1.14
control-plane host
 management-interface Vlan1 allow ftp https ssh tftp snmp
!
!
control-plane
!
banner motd ^CUnauthorized Access is Prohibited!^C
!
line con 0
 exec-timeout 0 0
 password 7 <elided>
 logging synchronous
 login
line aux 0
 exec-timeout 0 1
 no exec
 transport output none
line 2
 no activation-character
 no exec
 transport preferred none
 transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
 stopbits 1
line vty 0 4
 exec-timeout 60 0
 login local
 transport input ssh
line vty 5 15
 login local
 transport input none
!
exception crashinfo maximum files 5
scheduler allocate 20000 1000
ntp server 129.6.15.26
!
end
0 Helpful

Go to solution
Georg Pauwen
VIP
VIP
In response to tresdodi

‎12-24-2021 10:17 AM - last edited on ‎01-18-2022 01:41 AM by Community Manager

Hello,

 

I think that, since the router is not the DHCP server, you need to have DHCP traffic pass between the IOT and the HOME zones. It would look something like this:

 

access-list extended 101
10 permit udp any any eq 67
!
access-list extended 102
10 permit udp any any eq 68

class-map type inspect match-any HOME-TO-IOT-CM
match access-group 101
class-map type inspect match-any IOT-TO-HOME-CM
match access-group 102
!
policy-map type inspect IOT-TO-HOME-PM
class type inspect IOT-TO-HOME-CM
pass
class class-default
drop
policy-map type inspect HOME-TO-IOT-PM
class type inspect HOME-TO-IOT-CM
pass
class class-default
drop
!
zone-pair security IOT-HOME_ZP source IOT destination HOME
service-policy type inspect IOT-TO-HOME-PM
zone-pair security HOME-TO-IOT_ZP source HOME destination IOT
service-policy type inspect HOME-TO-IOT-PM
0 Helpful

Go to solution
tresdodi
Level 1
Level 1
In response to Georg Pauwen

‎12-24-2021 12:12 PM - last edited on ‎01-18-2022 01:42 AM by Community Manager

If I do this DCHP doesn't pass through the firewall because the DHCP packets are directed to the router (self zone). That's why time ago I set the firewall to pass DHCP discover from IOT to self (255.255.255.255), inspect all from self to Home and IOT, and inspect all from Home to self.

 - IOT to self DHCP Discover: 0.0.0.0 ->pass-> 255.255.255.255

 - self to Home relayed DHCP Discover: 192.168.200.1 ->inspect-> 192.168.1.14

 - Home to self DHCP Offer: 192.168.1.14 -> 192.168.200.1

 - self to IOT relayed DHCP Offer: 192.168.200.1 ->inspect-> 0.0.0.0


The strange thing is that this has been working for all clients in all vlans, except for this one client. By the way, this device is a smart light bulb. I'd blame it if the WLC showed the DCHP Offer for it, but it doesn't; as if the DHCP offer is not making it to that network. For comparison, this is the WLC debug for the complete DHCP negotiation for a cell phone on the same vlan (200):

*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP received op BOOTREQUEST (1) (len 306,vlan 1, port 1, encap 0xec03)
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP   xid: 0x79b87722 (2042132258), secs: 0, flags: 0
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP   chaddr: 98:09:cf:90:ac:40
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:14:01.769: 98:09:cf:90:ac:40 DHCP successfully bridged packet to DS
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP received op BOOTREPLY (2) (len 308,vlan 200, port 1, encap 0xec00)
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP processing DHCP OFFER (2)
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP   xid: 0x79b87722 (2042132258), secs: 0, flags: 0
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP   chaddr: 98:09:cf:90:ac:40
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP   ciaddr: 0.0.0.0,  yiaddr: 192.168.200.104
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP   siaddr: 192.168.1.14,  giaddr: 192.168.200.1
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP   server id: 192.168.1.14  rcvd server id: 192.168.1.14
*DHCP Socket Task: Dec 24 10:14:01.775: 98:09:cf:90:ac:40 DHCP successfully bridged packet to STA
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP received op BOOTREQUEST (1) (len 318,vlan 1, port 1, encap 0xec03)
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP processing DHCP REQUEST (3)
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP   xid: 0x79b87722 (2042132258), secs: 0, flags: 0
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP   chaddr: 98:09:cf:90:ac:40
*DHCP Socket Task: Dec 24 10:14:01.831: 98:09:cf:90:ac:40 DHCP   ciaddr: 0.0.0.0,  yiaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:14:01.832: 98:09:cf:90:ac:40 DHCP   siaddr: 0.0.0.0,  giaddr: 0.0.0.0
*DHCP Socket Task: Dec 24 10:14:01.832: 98:09:cf:90:ac:40 DHCP   requested ip: 192.168.200.104
*DHCP Socket Task: Dec 24 10:14:01.832: 98:09:cf:90:ac:40 DHCP   server id: 192.168.1.14  rcvd server id: 192.168.1.14
*DHCP Socket Task: Dec 24 10:14:01.832: 98:09:cf:90:ac:40 DHCP successfully bridged packet to DS
*DHCP Socket Task: Dec 24 10:14:01.836: 98:09:cf:90:ac:40 DHCP received op BOOTREPLY (2) (len 308,vlan 200, port 1, encap 0xec00)
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP processing DHCP ACK (5)
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP   xid: 0x79b87722 (2042132258), secs: 0, flags: 0
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP   chaddr: 98:09:cf:90:ac:40
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP   ciaddr: 0.0.0.0,  yiaddr: 192.168.200.104
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP   siaddr: 0.0.0.0,  giaddr: 192.168.200.1
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 DHCP   server id: 192.168.1.14  rcvd server id: 192.168.1.14
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 Static IP client associated to interface iot which can support client subnet.
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 apfMsRunStateInc
*DHCP Socket Task: Dec 24 10:14:01.837: 98:09:cf:90:ac:40 192.168.200.104 DHCP_REQD (7) Change state to RUN (20) last state DHCP_REQD (7)

 

0 Helpful

Go to solution
Georg Pauwen
VIP
VIP
In response to tresdodi

‎12-24-2021 12:37 PM

Hello,

 

--> this device is a smart light bulb

 

What brand/type/model is the smart light bulb ? And what brand/type/model is the WLC ?

0 Helpful

Go to solution
tresdodi
Level 1
Level 1
In response to Georg Pauwen

‎01-17-2022 09:53 AM

Sorry for the late reply and thank you for your help on this. During the end of the year I got distracted from this. Late Happy New Year!

The bulb is a Lifx Original model BUL-11-A21E26-G. The WLC is an AIR-CT2504-5-K9 V03.

I'll monitor the switch to verify if the DHCP Offer is making from the router to the WLC.

0 Helpful

Go to solution
Georg Pauwen
VIP
VIP
In response to tresdodi

‎01-17-2022 01:43 PM

Hello,

 

I guess if you can get a Wireshark capture, that would be helpful.

 

Since I don't know much about the LifeX bulbs, I have googled around; did you try a hardware reset ?

 

https://support.lifx.com/hardware-resetting-your-lifx-ryXKbdiLO

 

Also, it might be worth while checking the wifi connectivity checklist:

 

https://support.lifx.com/wi-fi-connectivity-checklist-rJebzOi8O

0 Helpful

Go to solution
tresdodi
Level 1
Level 1
In response to Georg Pauwen

‎01-17-2022 02:01 PM

Georg, please check my other update below for important details I found.

0 Helpful

Go to solution
tresdodi
Level 1
Level 1
In response to Georg Pauwen

‎12-24-2021 10:01 AM

Yes, the client with the problem in on VLAN 200.

0 Helpful

Go to solution
tresdodi
Level 1
Level 1

‎01-17-2022 01:08 PM

Update:

On the subnet where the lightbulb is clients that send the DHCP Discover with the bootp flags set to Unicast get DHCP fine. However, the lightbulb sets the flags to Broadcast. This seems the be the crucial factor.

The lightbulb gets DHCP fine if I connect it to the network where the DHCP server is. It means that the problem occurs due to the bootp flag being set to Broadcast and DHCP going through a relay.

I see the DHCP server sending the DHCP Offer and the relay says that it broadcasts it, but a packet capture on that VLAN (200) does not show the Offer, only the constant client Discovers:

an 17 20:31:31.373: DHCPD: client's VPN is .
Jan 17 20:31:31.373: DHCPD: No option 125
Jan 17 20:31:31.373: DHCPD: Option 125 not present in the msg.
Jan 17 20:31:31.373: DHCPD: Option 125 not present in the msg.
Jan 17 20:31:31.373: DHCPD: setting giaddr to 192.168.200.1.
Jan 17 20:31:31.373: DHCPD: BOOTREQUEST from d073.d502.63b9 forwarded to 192.168.1.14.
Jan 17 20:31:31.373: DHCPD: client's VPN is .
Jan 17 20:31:31.373: DHCPD: No option 125
Jan 17 20:31:31.373: DHCPD: forwarding BOOTREPLY to client d073.d502.63b9.
Jan 17 20:31:31.373: DHCPD: Option 125 not present in the msg.
Jan 17 20:31:31.373: DHCPD: no option 125
Jan 17 20:31:31.373: DHCPD: broadcasting BOOTREPLY to client d073.d502.63b9.

Capture.JPG

0 Helpful

Go to solution
tresdodi
Level 1
Level 1

‎01-17-2022 07:40 PM

Solved!

After the above, I had a hunch that this was some kind of interoperational bug between ZBFW and DHCP relay. Then I found DHCP Client or Server with ZBF Router Configuration, which prompts to pass DHCP requests and replies from and to the router when working with the built-in DHCP server or when the router is a DHCP client. It also refers to bug  CSCso53376 - ZBF inspect doesn't work for broadcast traffic which succinctly states that "ZBF with DHCP currently does not work" and the solution is to "manually allow DHCP [...] from and to the router."

So, I modified the policy between the self and the Iot zone (where the lightbulb is) to pass DHCP reply and the problem was resolved instantly, meaning that the bulb successfully got an IP after the DHCP offer broadcasted by the relay made it to it through the ZBFW. The previous policy only inspected everything and curiously, clients that set the bootp flags on the DHCP Discovery to Unicast always worked fine, which happened to be all the devices I had had. As soon as I brought the Lifx bulb, which sets the flags to Broadcast, I hit the bug.

This is the working config now:

ip access-list standard PERMIT_ANY
permit any
ip access-list extended DHCP_REPLY
 permit udp any any eq bootpc

policy exists on zp SELF-IOT_ZP
  Zone-pair: SELF-IOT_ZP

  Service-policy inspect : PASS_DHCP_REPLY_AND_INSPECT

    Class-map: DCHP_REPLY_CMAP (match-any)
      Match: access-group name DHCP_REPLY
        4 packets, 1232 bytes
        30 second rate 0 bps
      Pass
        4 packets, 1232 bytes

    Class-map: ALL_TRAFFIC_CMAP (match-any)
      Match: access-group name PERMIT_ANY
        0 packets, 0 bytes
        30 second rate 0 bps

   Inspect

    Class-map: class-default (match-any)
      Match: any
      Drop
        0 packets, 0 bytes
Customers Also Viewed These Support Documents