Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Windows 2019 DHCP stops serving IPs to LAN clients when OpenVPN site-to-site is on. [solved]

    Scheduled Pinned Locked Moved
    DHCP and DNS
    solved
    2
    3
    5.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      SuperVertrix
      last edited by johnpoz

      Hello Community,

      I do have a very weird problem that I can't seem to figure out.

      I have two sites connected via OpenVPN shared-key.

      The configuration:
      pfSense ver. on both ends: 2.4.5-RELEASE-p1

      Server/Site: A
      WAN: internet_ip_#
      LAN: 10.10.51.0/24
      OpenVPN Tunnel Network: 10.8.0.0/24
      Windows 2019 DHCP server, subnet range 10.10.51.30 to 10.10.51.240

      Client/Site: B
      WAN: internet_ip_#
      LAN: 10.10.40.0/24
      OpenVPN Tunnel Network: 10.8.0.0/24
      Windows 2019 DHCP server, subnet range 10.10.40.30 to 10.10.40.240

      The problem:
      Whenever I establish the OpenVPN tunnel, all the DHCP computer clients on the LAN side of Site A stops getting IPs from the Windows DHCP server on the same subnet, they try and fail.

      Site B computer clients on the LAN aside are able to obtain their IP's via their Windows DHCP server without a problem.

      I did a packet capture from Site A, LAN side, with tunnel turn on and off:

      Tunnel on: DHCP request is broadcasted, but Windows server just ignores it:

      22:39:35.027192 IP (tos 0x0, ttl 128, id 60430, offset 0, flags [none], proto UDP (17), length 328)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:67:bb:61, length 300, xid 0x2d5d54a4, Flags [none]
      Client-Ethernet-Address 00:0c:29:67:bb:61
      Vendor-rfc1048 Extensions
      Magic Cookie 0x63825363
      DHCP-Message Option 53, length 1: Discover
      Client-ID Option 61, length 7: ether 00:0c:29:67:bb:61
      Hostname Option 12, length 12: "WINDOWS10_VM"
      Vendor-Class Option 60, length 8: "MSFT 5.0"
      Parameter-Request Option 55, length 14:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
      Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
      Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
      Classless-Static-Route-Microsoft, Option 252
      22:39:35.115947 IP (tos 0x0, ttl 128, id 60431, offset 0, flags [none], proto UDP (17), length 328)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:67:bb:61, length 300, xid 0xe17275e0, Flags [none]
      Client-Ethernet-Address 00:0c:29:67:bb:61
      Vendor-rfc1048 Extensions
      Magic Cookie 0x63825363
      DHCP-Message Option 53, length 1: Discover
      Client-ID Option 61, length 7: ether 00:0c:29:67:bb:61
      Hostname Option 12, length 12: "WINDOWS10_VM"
      Vendor-Class Option 60, length 8: "MSFT 5.0"
      Parameter-Request Option 55, length 14:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
      Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
      Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
      Classless-Static-Route-Microsoft, Option 252
      22:39:39.978436 IP (tos 0x0, ttl 128, id 60432, offset 0, flags [none], proto UDP (17), length 328)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:67:bb:61, length 300, xid 0xe17275e0, Flags [none]
      Client-Ethernet-Address 00:0c:29:67:bb:61
      Vendor-rfc1048 Extensions
      Magic Cookie 0x63825363
      DHCP-Message Option 53, length 1: Discover
      Client-ID Option 61, length 7: ether 00:0c:29:67:bb:61
      Hostname Option 12, length 12: "WINDOWS10_VM"
      Vendor-Class Option 60, length 8: "MSFT 5.0"
      Parameter-Request Option 55, length 14:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
      Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
      Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
      Classless-Static-Route-Microsoft, Option 252
      22:39:41.899921 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 169.254.85.78 tell 0.0.0.0, length 46
      22:39:42.899934 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 169.254.85.78 tell 0.0.0.0, length 46
      22:39:43.899924 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 169.254.85.78 tell 0.0.0.0, length 46
      22:39:44.947106 IP (tos 0x0, ttl 128, id 60433, offset 0, flags [none], proto UDP (17), length 328)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:67:bb:61, length 300, xid 0xe17275e0, secs 1024, Flags [none]
      Client-Ethernet-Address 00:0c:29:67:bb:61
      Vendor-rfc1048 Extensions
      Magic Cookie 0x63825363
      DHCP-Message Option 53, length 1: Discover
      Client-ID Option 61, length 7: ether 00:0c:29:67:bb:61
      Hostname Option 12, length 12: "WINDOWS10_VM"
      Vendor-Class Option 60, length 8: "MSFT 5.0"
      Parameter-Request Option 55, length 14:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
      Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
      Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
      Classless-Static-Route-Microsoft, Option 252

      Tunnel off: DHCP request is broadcasted, but Windows server replies to request with IP #:

      23:01:13.697351 IP (tos 0x0, ttl 128, id 3812, offset 0, flags [none], proto UDP (17), length 344)
      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:67:bb:61, length 316, xid 0xa0f0de30, Flags [none]
      Client-Ethernet-Address 00:0c:29:67:bb:61
      Vendor-rfc1048 Extensions
      Magic Cookie 0x63825363
      DHCP-Message Option 53, length 1: Request
      Client-ID Option 61, length 7: ether 00:0c:29:67:bb:61
      Requested-IP Option 50, length 4: 10.10.51.128
      Hostname Option 12, length 12: "WINDOWS10_VM"
      FQDN Option 81, length 15: "WINDOWS10_VM"
      Vendor-Class Option 60, length 8: "MSFT 5.0"
      Parameter-Request Option 55, length 14:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
      Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
      Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
      Classless-Static-Route-Microsoft, Option 252
      23:01:13.698136 IP (tos 0x0, ttl 128, id 8959, offset 0, flags [none], proto UDP (17), length 328)
      10.10.51.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0xa0f0de30, Flags [none]
      Your-IP 10.10.51.128
      Client-Ethernet-Address 00:0c:29:67:bb:61
      Vendor-rfc1048 Extensions
      Magic Cookie 0x63825363
      DHCP-Message Option 53, length 1: ACK
      RN Option 58, length 4: 345600
      RB Option 59, length 4: 604800
      Lease-Time Option 51, length 4: 691200
      Server-ID Option 54, length 4: 10.10.51.5
      Subnet-Mask Option 1, length 4: 255.255.255.0
      Default-Gateway Option 3, length 4: 10.10.51.1
      Domain-Name-Server Option 6, length 4: 10.10.51.5
      Domain-Name Option 15, length 7: "my_domain_name.ad^@"

      Any idea why psfense OpenVPN running on a site-to-site configuration would be causing this?

      I'be been searching throught and I can't seem to find anybody else having this problem.

      Please help!

      Sincerely,
      SuperVertrix.

      S 1 Reply Last reply Reply Quote 0
      • S
        SteveITS Rebel Alliance @SuperVertrix
        last edited by

        Just a guess, is the Windows server logging that it sees another DHCP server on the network and will stop processing DHCP requests? (it's an event, don't recall the event ID or exact wording)

        Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
        Upvote 👍 helpful posts!

        S 1 Reply Last reply Reply Quote 1
        • S
          SuperVertrix @SteveITS
          last edited by

          @teamits

          Thank you, Steve, you somewhat pointed me in the right direction.
          The location of the events are located here:
          Applications and Services Logs > Microsoft > Windows > DHCP-Server

          I checked and I couldn't find the culprit, but there's a DHCP server log file here:
          %windir%\System32\Dhcp

          The log file revealed the following error while a client was asking for an IP and the OpenVPN tunnel was on:
          "Packet dropped because of Client ID hash has mismatch or standby server"

          Upon further search, it turns out that the Active Directory DHCP server on Site A was trying to contact an AD DHCP server on Site B that once was part of the AD Domain of Site A, but since was removed from, but some more cleanup was necessary on AD Site A to make it stop trying to contact that orphaned AD Domain Controller. The issue has been resolved, all clients are able to obtain IP #'s from Site A.

          Thanks so much for the hint.

          Stay safe my friends.

          SuperVertrix.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post