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

    DHCP relay over IPSEC VPN?

    DHCP and DNS
    10
    27
    8.4k
    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.
    • jimpJ
      jimp Rebel Alliance Developer Netgate
      last edited by

      The limitation before was mostly due to IPsec in tunnel mode. In theory, VTI mode should handle it better, since you'd have proper OS routes to the destination. I haven't tried it, though. It might work, it might not, but if it doesn't work then it may be an issue in the DHCP relay daemon not wanting to latch onto the VTI interface itself. It's also possible that it's hitting an issue like https://redmine.pfsense.org/issues/9466 which may be solved on 2.4.5 which will be out soon.

      Beyond that, it isn't necessarily about the type of packet but how it gets treated. Coming from the operating system on the firewall, it has different rules to follow vs a packet coming from the LAN. The OS has to follow its routing table when choosing not only where to deliver the packet but which source address to use. Because of that, the packets generated by the relay daemon may not match tunnel policies (in tunnel mode) thus would never be delivered to the far side.

      Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      J ? 2 Replies Last reply Reply Quote 0
      • J
        jlw52761 @jimp
        last edited by

        @jimp That makes much more sense, thank you for the expanded answer. I'm going to keep my eyes open for 2.4.5 and try the setup again, maybe they have it licked.

        1 Reply Last reply Reply Quote 0
        • ?
          A Former User @jimp
          last edited by A Former User

          @jimp : DHCP Relay doesn't like VTIs as Upstream Interfaces:

          Unsupported device type 131 for "ipsec1000"
          

          Edit: Tested on 2.4.4-RELEASE-p3

          1 Reply Last reply Reply Quote 0
          • R
            rvoosterhout
            last edited by

            We are 2 years further, is there any progress on relaying dhcp requests through an ipsec vpn tunnel?

            1 Reply Last reply Reply Quote 1
            • M
              maestrx
              last edited by

              One year later and still hitting the same wall... any ideas with the 2.6.0 release ?

              J 1 Reply Last reply Reply Quote 0
              • M maestrx referenced this topic on
              • J
                jlw52761 @maestrx
                last edited by

                @maestrx I get the feeling you will need to use your switch to do the DHCP relay functionality. I haven't done this on the pfSense platform, but I do this on my work's Palo Alto platform that uses IPSeC tunnels from remote sites to the main datacenter and DHCP is located centrally for the smaller sites. This is done using the Cisco ip-helper configuration of the SVI, but I bet other switches have this as well.

                M 1 Reply Last reply Reply Quote 1
                • M
                  maestrx @jlw52761
                  last edited by

                  @jlw52761 Thanks for your note. Our switches have L2 license only and the ones with L3 does not work with our usecase (PXE install) anyway. So we need to have it done on the FW level.

                  J 1 Reply Last reply Reply Quote 0
                  • J
                    jlw52761 @maestrx
                    last edited by

                    @maestrx I don't understand your comment about L3 and PXEINSTALL. the ip-helper/DHCP Relay is all the switch has to do, which is essentially reflect the packets. The PXE is still handled by your DHCP server and the TFTP server.

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      maestrx @jlw52761
                      last edited by

                      @jlw52761 Well, reality is showing that the ip-helper implementation in the switches is not perfect and the PXE boot usecase is not working for us. L2 switch means that the switch sees only up to the MAC address and does not see the content of the packets ( not able to distinguish if the packet is DHCP or any other type of traffic)

                      J 1 Reply Last reply Reply Quote 1
                      • J
                        jlw52761 @maestrx
                        last edited by

                        @maestrx I do know what the difference between an L2 and L3 switch are. The L3 switch would perform the relay function, which depending on the manufacturer may or may not work well. I know on the Cisco Catalyst switches, it worked without any issues.

                        E 1 Reply Last reply Reply Quote 0
                        • E
                          Ethereal @jlw52761
                          last edited by

                          @jlw52761 IP helper would work only on the SVI / Layer 3 Interface for the network.
                          DHCP is L2. The IP helper must be configured on the Layer 3 interface/SVI which would also be the gateway/router for that network. That SVI must be able to "talk" / reach the DHCP server.

                          J 1 Reply Last reply Reply Quote 0
                          • J
                            jlw52761 @Ethereal
                            last edited by

                            @Ethereal Yes, absolutely correct. Are you magically wanting pfSense to do this without any L2 connectivity?

                            E 1 Reply Last reply Reply Quote 0
                            • E
                              Ethereal @jlw52761
                              last edited by

                              @jlw52761 i clicked on the wrong user. I was replying to one reply above.

                              J 1 Reply Last reply Reply Quote 0
                              • J
                                jlw52761 @Ethereal
                                last edited by

                                @Ethereal understandable, sorry for the snarky response.

                                O 1 Reply Last reply Reply Quote 0
                                • O
                                  othomas @jlw52761
                                  last edited by

                                  Just another hand up here for this to be a feature in pfSense - our usecase is also iPXE bootstaping. I was assuming in my original planning that this was work, and now I find it doesn't. Having to rethink ๐Ÿ˜ 

                                  1 Reply Last reply Reply Quote 0
                                  • I
                                    itBJA
                                    last edited by

                                    Hello together.
                                    Seems almost 2 years later still an issue.
                                    I tried out the fix with the route, only change is, that I can now ping the remote-side from the diagnostic menu.
                                    DHCP Relay still not working.
                                    On the remote side the is no switch, it a virtualized network without any further setting possible.
                                    The issue might also be:
                                    You can have only one setting for DHCP-Relay.
                                    So if you have VLANs on the remote-side that need to communicate with the same DHCP-Server on the central side, the packets won't come from the respective VLAN-interface, and will be routed into the wrong scope of the DHCP.
                                    What also is weird, the local DHCP in the PFSense also isn't working, or so to speak only serving the LAN-Interface, not the VLAN-interfaces althoug activated on every interface.

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.