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

    DHCP offers from pfsense seems to be unicasted instead of broadcasted problem.

    Scheduled Pinned Locked Moved
    DHCP and DNS
    2
    5
    3.3k
    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.
    • P
      pfsenseboonie
      last edited by

      Hi all,

      I have such a network

      1/
      VLAN A -> 192.168.1.0/24)
      VLAN B -> 192.168.2.0/24)

      2/
      PFSENSE in Router on Stick mode. (192.168.1.1, 192.168.2.1)

      OpenVPN -> 192.168.1.50
      Client_A1 -> 192.168.1.55
      Client_A2 -> 192.168.2.112

      I am trying to let Client_A2 be part of the VLAN A via Openvpn in bridge mode.

      Client_A2 creates it's tap0 interface and sends a DHCPDISCOVER

      
12:16:58.021647 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 11:22:33:44:55:66, length 300

      Monitoring the interfaces on the openvpn server I can also see the DHCPDISCOVER

      
12:17:23.469527 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 11:22:33:44:55:66, length 300

      Monitoring the interfaces on the pfsense router I can see the DHCPDISCOVER and the DHCPOFFER

      
12:21:33.923175 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 11:22:33:44:55:66, length 300
12:21:33.923562 IP 192.168.1.1.67 > 192.168.1.105.68: BOOTP/DHCP, Reply, length 300

      And that is as far as it gets.  From there the openvpn server does not record the passage of the offer and the ofer does not arrive at the requesting client.

      I read the DHCPOFFER portion of how dhcp is suppose to work and see this…

      
Once the DHCP server receives the DHCPDISCOVER message, it replies with a DHCPOFFER message. The DHCPOFFER message contains the IP configuration information for the client. THE DHCPOFFER message is sent as a broadcast on UDP port 68\. The client will know that the DHCPOFFER message is intended for it because the client's MAC address is included in the message.

      Looking back at the traffic log for pfsense I see this…

      
  12:21:33.923562 IP 192.168.1.1.67 > 192.168.1.105.68: BOOTP/DHCP, Reply, length 300

      instead of what the docs say it should be which may imply that pfsense is try to send to a nonexistance IP instead of brocasting the DHCPOFFER?

      
  12:21:33.923562 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

      What can I do to insure the requesting openvpn client receives the offer.

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        I think there are a few pieces of information missing from your problem report:

        @pfsenseboonie:

        Monitoring the interfaces on the pfsense router I can see the DHCPDISCOVER and the DHCPOFFER

        
12:21:33.923175 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 11:22:33:44:55:66, length 300
12:21:33.923562 IP 10.0.0.1.67 > 10.0.0.105.68: BOOTP/DHCP, Reply, length 300

        And that is as far as it gets.  From there the openvpn server does not record the passage of the offer and the ofer does not arrive at the requesting client.

        What interfaces have IP addresses 10.0.0.1 and 10.0.0.105?

        @pfsenseboonie:

        I read the DHCPOFFER portion of how dhcp is suppose to work and see this…

        
Once the DHCP server receives the DHCPDISCOVER message, it replies with a DHCPOFFER message. The DHCPOFFER message contains the IP configuration information for the client. THE DHCPOFFER message is sent as a broadcast on UDP port 68\. The client will know that the DHCPOFFER message is intended for it because the client's MAC address is included in the message.

        Read where? In a "normal" LAN the DHCP server will know the MAC address of the client that issued the DHCPDISCOVER so the server can send the DHCP offer to the client's MAC address, no need to use the broadcast MAC address nor a broadcast IP address. The CLIENT always needs to send the DHCPDISCOVER to the broadcast MAC address since the client doesn't know the MAC address of the server until the client gets a response from a server.

        Perhaps it would help if you provided a diagram of the network including IP addresses and subnet masks of all the interfaces.

        1 Reply Last reply Reply Quote 0
        • P
          pfsenseboonie
          last edited by

          @wallabybob:

          What interfaces have IP addresses 10.0.0.1 and 10.0.0.105?

          That was a typo I have corrected it in the original post.

          @wallabybob:

          Read where? In a "normal" LAN the DHCP server will know the MAC address of the client that issued the DHCPDISCOVER so the server can send the DHCP offer to the client's MAC address, no need to use the broadcast MAC address nor a broadcast IP address. The CLIENT always needs to send the DHCPDISCOVER to the broadcast MAC address since the client doesn't know the MAC address of the server until the client gets a response from a server.

          I stand corrected
          I read it on the internet here so I thought it was true. :)
          http://knowurtech.netfirms.com/networking/how_dhcp_works.html

          @wallabybob:

          Perhaps it would help if you provided a diagram of the network including IP addresses and subnet masks of all the interfaces.

          See attached png.

          network.png
          network.png_thumb

          1 Reply Last reply Reply Quote 0
          • P
            pfsenseboonie
            last edited by

            … some more information....
            I don't know how to explain it so I am just going to say what I see.

            I tried testing with an opvn config where the ovpn server itself hands out leases.
            When a clientB on VLAN B connects and gets an ip on say 192.168.1.105, and trys to ping 192.168.1.55 it gets host unreachable meaning the arp handshake did not complete.

            1/
            I can see the arp-request for .55 being requested by .105

            2/
            I can see on the ovpn server on both the tap0 and br0 interface that the arp-request from .105 for .55 is seen there.

            3/
            I can see on the pfsense server on the vlanA  interface that the arp-request from .105 for .55 is seen there.

            4/
            I can see on the .55 ClientA on eth0 interface that the arp-request from .105 for .55 is seen there, and can also see that .55 replies with it's mac address

            5/
            back to ovpn server I cannot see the reply that .55 sent out

            6/
            back to clientB on VLAN B who is connected to VLAN A via ovpn server, I cannot see the arp-reply from .55

            So since the arp is not completing I don't thing any type of communication is possible?

            1 Reply Last reply Reply Quote 0
            • P
              pfsenseboonie
              last edited by

              Hi again,

              I think I have tracked down my misconfiguration.

              When I converted this network to VLANS the vSwitch in vmware lost it's "accept promiscuous packets" setting.  After going in and setting VLAN A interface (this is the one openvpn is assigned to) to accept promiscuous packets then the packets began to flow as I remembered before switching to this VLAN configuration.

              Apologies for the false alarm.

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