pfSense doubling DHCP Request even Though DHCP-Relay Disabled on Interface



  • Hi,

    I have a strange issue here.
    A client PC (Win10) is requesting frequently a new IP address. I did some troubleshooting and noticed my pfSense is relaying the request to the DHCP server even though it should not!

    Setup:
    pfSense with some more interfaces, on some interfaces DHCP relay is activated to relay DHCP requests to the server 192.168.9.10. This is working really fine.

    I recently noticed (not aware of any changes) a Win10 client request frequently a confirmation for his address and in addition, the pfSense does so. See below dhcpdump output:

    root@ucs:/var/log# dhcpdump -i ens192
      TIME: 2019-11-28 13:40:56.233
        IP: 0.0.0.0 (a4:4c:c8:a4:91:60) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
        OP: 1 (BOOTPREQUEST)
     HTYPE: 1 (Ethernet)
      HLEN: 6
      HOPS: 0
       XID: e8c144e9
      SECS: 0
     FLAGS: 0
    CIADDR: 0.0.0.0
    YIADDR: 0.0.0.0
    SIADDR: 0.0.0.0
    GIADDR: 0.0.0.0
    CHADDR: a4:4c:c8:a4:91:60:00:00:00:00:00:00:00:00:00:00
     SNAME: .
     FNAME: .
    OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
    OPTION:  61 (  7) Client-identifier         01:a4:4c:c8:a4:91:60
    OPTION:  50 (  4) Request IP address        192.168.9.140
    OPTION:  12 (  8) Host name                 knebb
    OPTION:  81 ( 20) Client FQDN               0-0-0 knebb.domain.com
    OPTION:  60 (  8) Vendor class identifier   MSFT 5.0
    OPTION:  55 ( 14) Parameter Request List      1 (Subnet mask)
    					      3 (Routers)
    					      6 (DNS server)
    					     15 (Domainname)
    					     31 (Perform router discovery)
    					     33 (Static route)
    					     43 (Vendor specific info)
    					     44 (NetBIOS name server)
    					     46 (NetBIOS node type)
    					     47 (NetBIOS scope)
    					    119 (Domain Search)
    					    121 (Classless Static Route)
    					    249 (MSFT - Classless route)
    					    252 (MSFT - WinSock Proxy Auto Detect)
    					    
    ---------------------------------------------------------------------------
    
      TIME: 2019-11-28 13:40:56.234
        IP: 192.168.9.254 (90:1b:e:bf:78:6a) > 192.168.9.10 (0:50:56:bf:53:5f)
        OP: 1 (BOOTPREQUEST)
     HTYPE: 1 (Ethernet)
      HLEN: 6
      HOPS: 1
       XID: e8c144e9
      SECS: 0
     FLAGS: 0
    CIADDR: 0.0.0.0
    YIADDR: 0.0.0.0
    SIADDR: 0.0.0.0
    GIADDR: 192.168.9.254
    CHADDR: a4:4c:c8:a4:91:60:00:00:00:00:00:00:00:00:00:00
     SNAME: .
     FNAME: .
    OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
    OPTION:  61 (  7) Client-identifier         01:a4:4c:c8:a4:91:60
    OPTION:  50 (  4) Request IP address        192.168.9.140
    OPTION:  12 (  8) Host name                 knebb
    OPTION:  81 ( 20) Client FQDN               0-0-0 knebb.domain.com
    OPTION:  60 (  8) Vendor class identifier   MSFT 5.0
    OPTION:  55 ( 14) Parameter Request List      1 (Subnet mask)
    					      3 (Routers)
    					      6 (DNS server)
    					     15 (Domainname)
    					     31 (Perform router discovery)
    					     33 (Static route)
    					     43 (Vendor specific info)
    					     44 (NetBIOS name server)
    					     46 (NetBIOS node type)
    					     47 (NetBIOS scope)
    					    119 (Domain Search)
    					    121 (Classless Static Route)
    					    249 (MSFT - Classless route)
    					    252 (MSFT - WinSock Proxy Auto Detect)
    					    
    ---------------------------------------------------------------------------
    
      TIME: 2019-11-28 13:40:56.234
        IP: 192.168.9.10 (0:50:56:bf:53:5f) > 192.168.9.140 (a4:4c:c8:a4:91:60)
        OP: 2 (BOOTPREPLY)
     HTYPE: 1 (Ethernet)
      HLEN: 6
      HOPS: 0
       XID: e8c144e9
      SECS: 0
     FLAGS: 0
    CIADDR: 0.0.0.0
    YIADDR: 192.168.9.140
    SIADDR: 192.168.9.10
    GIADDR: 0.0.0.0
    CHADDR: a4:4c:c8:a4:91:60:00:00:00:00:00:00:00:00:00:00
     SNAME: .
     FNAME: .
    OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
    OPTION:  54 (  4) Server identifier         192.168.9.10
    OPTION:  51 (  4) IP address leasetime      86400 (24h)
    OPTION:   1 (  4) Subnet mask               255.255.255.0
    OPTION:   3 (  4) Routers                   192.168.9.254
    OPTION:   6 ( 12) DNS server                192.168.9.10,192.168.9.254,192.168.9.100
    OPTION:  15 (  8) Domainname                domain.com
    ---------------------------------------------------------------------------
    
      TIME: 2019-11-28 13:40:56.235
        IP: 192.168.9.10 (0:50:56:bf:53:5f) > 192.168.9.254 (90:1b:e:bf:78:6a)
        OP: 2 (BOOTPREPLY)
     HTYPE: 1 (Ethernet)
      HLEN: 6
      HOPS: 1
       XID: e8c144e9
      SECS: 0
     FLAGS: 0
    CIADDR: 0.0.0.0
    YIADDR: 192.168.9.140
    SIADDR: 192.168.9.10
    GIADDR: 192.168.9.254
    CHADDR: a4:4c:c8:a4:91:60:00:00:00:00:00:00:00:00:00:00
     SNAME: .
     FNAME: .
    OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
    OPTION:  54 (  4) Server identifier         192.168.9.10
    OPTION:  51 (  4) IP address leasetime      86400 (24h)
    OPTION:   1 (  4) Subnet mask               255.255.255.0
    OPTION:   3 (  4) Routers                   192.168.9.254
    OPTION:   6 ( 12) DNS server                192.168.9.10,192.168.9.254,192.168.9.100
    OPTION:  15 (  8) Domainname                domain.com
    ---------------------------------------------------------------------------
    

    Any ideas what is going on?

    /KNEBB



  • As an addition:
    Seems the dhcprelay listens on all interfaces. I assume this is usual behaviour and the interfaces to deal with are in the configuration?

    [2.4.4-RELEASE][root@pfsense.domain.com]/root: sockstat -4 -l | grep 67
    root     dhcrelay   10067 8  udp4   *:67                  *:*
    


  • @knebb said in pfSense doubling DHCP Request even Though DHCP-Relay Disabled on Interface:

    sockstat -4 -l | grep 67

    Is the client PC and DHCP server on the same subnet ?

    Tried a packet capture on pfSense to see whats happening ?



  • This post is deleted!


  • This post is deleted!


  • Me again.

    Very strage- the pfSense packet capture did not capture anything!
    But dhcpdump did capture it again.

    This time I added the "Append circuit ID and agent ID to requests" to dhcp-relay and in dhcpdump on the DHCP server I got the following:

    OPTION:  82 (  5) Relay Agent Information   
                      Circuit-ID    72:65:30
    

    Now I need to find out which interface the "72:65:30" is. Any idea how to figure out?

    /KNEBB



  • Ok, got the pfSense packet capture now working (had it by default limited to 100 packes and did not caputer the later dhcp packets).

    Now it matches what dhcpdump captures:

    • First, I see a dhcprequest broadcast from my client (0.0.0.0 -> 255.255.255.255)
    • Then I see another DHCPREQUEST from my pfSense to my DHCP server
    • Third then is he DHCP server replying to my pfSense with DHCPACK
    • And fourth is the DHCP server replying to my client with DHCPACK.

    Still the question: Why does my pfSense dhcp relay forward these requests?

    /KNEBB


Log in to reply