How to DHCP relay with DHCP server on WAN side?



  • Hi,
    our environment is a network which consists of external, non-private subnets with our main DHCP server. I want to use a pfSense (2.2.6) for pure NATing between the main network and private networks. But I want to use the main DHCP Servers for the NATed-clients too.

    The pfsense-WAN interface is connected to the main network where the main DHCP Servers are. The LAN interface is connected to a VLAN with private addresses where the NATed clients will be.

    WAN-Interface:
    x.y.z.33 mask 255.255.255.0 with gateway x.y.z.1

    LAN Interface:
    10.45.192.1 mask 255.255.255.0
    no gateway

    DHCP-relay enabled on interface: LAN, destination server: [IP-Adress of MAIN DHCP-server]

    On the DHCP server I prepared an adress range 10.45.192.32-254. I activated "DHCP relay" on the pfSense LAN interface. DHCP DISCOVERS of NATed clients are received by our main DHCP-Server, since I see the following in its log:
    "DHCPDISCOVER from 50:1a:c5:f5:cc:a3 (hostname) via 10.45.192.1 uid 01:50:1a:c5:f5:cc:a3"
    "DHCPOFFER on 10.45.192.196 to 50:1a:c5:f5:cc:a3 (hostname) via bond0 relay 10.45.192.1 lease-duration 120 offered-duration 3600 uid 01:50:1a:c5:f5:cc:a3"

    I assume the OFFER-Packet does not reach the client since its destination is 10.45.192.1 which is on the inside of the pfSense. But shouldn't the packets go to the x.y.z.33 pfsense-WAN-interface to be able to reach 10.45.192.1? Shouldnt the discovers get relayed from 10.45.192.broadcast to x.y.z.33?

    What am i missing here? NATting itself works when I use IP-Adresses from pfSenses internal DHCP-server. I even added "PASS IPv4 from any to any"-Rules in LAN and WAN-firewall to make sure nothing is dropped.

    Best regards,
    Atkatla



  • Hello.
    In general, a complex situation you have in your hands.
    What happens is that your external main DHCP server doesn't know how to reach back your DHCP relay server with the DHCPOFFER. Because when the main one replies to the relay server it uses its private address as destination (a DHCP server replies to a relay server using what is in the GIADDR field in the DHCPDISCOVER - as shown in your logs also). You need to expose the relay server's private address to the main one. Some ways to do it are routing, port forwarding or vpn (not sure if port forwarding would work). I'd go with vpn if routing is not available.
    Either way, be advised that many would agree that it's a design to avoid. But sometimes I know it's inevitable. BTW, I would keep an eye on things like unicast flood.
    Hope it helps. :)
    See you.


  • Rebel Alliance Global Moderator

    So your dhcp server is sitting on a public IP??  Why are you masking your wan IP unless its public?  If pfsense is not your edge why are you natting inside your own network?



  • @john:
    I want to test NAT inside our network because we don't have unlimited non-private IP-Adresses. The use of public IP-Addresses inside the main network has historical roots (our organization has a class B-Subnet). Of course, security-sensitive systems are not reachable from the Internet, even if they use non-private IP-Adresses. But since I can't use the border firewall systems for this cause I want to use a dedicated pfsense-Router.

    @gabe:
    The NATed VLANs are in a separate virtual routing domain via VRF. Global-routing domain and NAT-routing domain are only connected via the pfSense-Router. So I suppose there must be a route in global routing domain like: if you want to send a packet to 10.45.192.1 send it via x.y.z.3 [pfSense-WAN-interface]? I'll talk about our routing admin about that.


  • Rebel Alliance Global Moderator

    So your using public inside your network that is fine.. But you don't have to nat your rfc1918 space in this case to talk to those public address, because your routing both public and rfc1918 in "your" network.

    If your going to nat devices behind pfsense would would you want to run a dhcp server outside pfsense??  That makes NO sense - because with the nat, the rest of your network would only ever be able to send stuff to pfsense wan IP.

    If you want to use pfsense inside your network and use a different dchp server, then you shouldn't be natting.  Or your dhcp server should be inside pfsense where there is no nat.



  • @johnpoz: Then what would you do?

    The requirements are:

    • you have subnets with public IPs (This is no corporate network where you can hide anything behind border firewalls. Only sensitive and critical systems are protected here, the rest of the clients want to use the internet freely.)
    • number of devices in public-main-networks are rising so the adress space in public networks are not enough anymore
    • so you have to move some of the devices to private-networks
    • but the devices still have to be able to communicate with main network AND internet, so you have to NAT
    • it is acceptable that devices in internet or public-network can't address devices behind pfSense directly because mainly clients are moved behind the NATing (think of smartphones and wifi-clients)
    • for technical and organisational reasons you can't use border or global-network routers for NATing for the next few years until real budget for new border and/or NAT-Hardware rains in
    • all DHCP-Addressing has to be done by a central DHCP-Cluster which is located in the public-main-network so helpdesk hasn't to look over several DHCP-servers.

    Imagine the situation as if an ISP would also have to manage and configure his customers private IP-Addresses behind their home NAT routers and does not want to use additional DHCP-Servers behind any NAT-router of his customers. I know it is an unusual situation.

    @gabe: We added a static route via the pfSense-WAN-IP in main network. Now the central DHCP-cluster can manage the IP-Adresses in the NAT-virtual routing domains behind the pfSense(s). :-)


  • Rebel Alliance Global Moderator

    " but the devices still have to be able to communicate with main network AND internet, so you have to NAT"

    Nonsense - Again you do not have to NAT just because you use public ip space inside your network.  You only have to nat when you want to those rfc1918 address to talk to the actual public internet.

    Why does your private IP space behind pfsense have to be managed by some central dhcp server?  If you going to nat those to the public IP space your connecting too then it will always look like that IP so that dhcp server is completely pointless, and just might as well use dhcp on pfsense to give devices behind pfsense IPs

    Your setup sounds completely fubar – If was mean the #1 project would be to get off public IP space internally..



  • @johnpoz:

    " but the devices still have to be able to communicate with main network AND internet, so you have to NAT"

    Nonsense - Again you do not have to NAT just because you use public ip space inside your network.  You only have to nat when you want to those rfc1918 address to talk to the actual public internet.

    Exactly. Thats what I meant when I wrote that they have to be able to communicate with network AND internet. Yes, the phrasing in my first post didnt imply that.

    Why does your private IP space behind pfsense have to be managed by some central dhcp server?  If you going to nat those to the public IP space your connecting too then it will always look like that IP so that dhcp server is completely pointless, and just might as well use dhcp on pfsense to give devices behind pfsense IPs

    It is not about which address is seen from the WAN side. Its about organization and configuration in the networks which is here more than simply giving addresses.

    Using DHCP-Server of the pfsense firewalls has several disadvantages in our case: Support and the admins of the respective organizational units must be able to set DHCP options for their selected devices or static DHCP adresses inside the NATed and non-NATed networks. If a lab admin wants to configure a static DHCP address for display-less lab devices or he has to give specific DHCP options to that device then I cant say to the admin that he has first to determine which pfsense is responsible for his private subnets and introduce him (or her) to pfsense. And I would have to give them access to pfsense so he can do his DHCP stuff there. Additionally pfsense DHCP misses funtions (more on this later) From the support side: wheter its a lab device or a plain wifi device, the user will always come with current or wanted internal IP address to the support staffs and not the external NAT-WAN-IP-Pool-Address. So it must be located fast and simple with a single click and not first looking which pfsense is responsible for the respective Subnet.

    So all in all the advantages of the central DHCP plattform are:

    • No need to give the subunits admins access to the pfsenses and teach them how to configure DHCP there
    • Even first level support units can find every device at once whether its in the public, private or private-NAT space.
    • Inheriting functions, templates and filters to determine different option sets and different lease times when a device hits certain rules make DHCP option administration of devices faster and easier. We have a lot of devices which need more than a simple IP-Address. I need to configure filters and rules only once. How would you configure multiple pfsense Firewalls to give a special set of DHCP options to every device which hits a filter rule set depending on content of RADIUS answers, DHCP fingerprints for vendor and/or operating system, the agent and curcuit IDs (which I can activate in pfSense DHCP relay) and so on?
    • It is already there and paid and support staffs are trained for it.

    The only disadvantage of using the central plattform is that I have to add a static route in the routers so the DHCPOFFER reaches the client. I can live with that.

    Your setup sounds completely fubar – If was mean the #1 project would be to get off public IP space internally..

    The majority of addresses has to stay in public address space. (the ISP-like part)
    Private-network clients which needs no internet are already in main-network-VLANs with private addresses.
    Now network devices which needs internet and are able to work behind NAT shall now move behind NAT to free more public addresses. Thats the basic strategy. Using the central DHCP server cluster keeps support and configuration tasks easy in this environment where support staffs of multiple organizational units have to do their DHCP stuff.

    Do you have a better suggestion to organize that?


  • Rebel Alliance Global Moderator

    But you do not have to nat it at pfsense..  You can nat your rfc1918 space at your edge when it actually needs to be natted.

    Here is your problem your trying to send a dhcp relay through a nat.. How does your dhcp server send back to the IP address given by the relay which is your private IP behind pfsense.. How is it suppose to know to send it to pfsense WAN public IP??

    If you want to use central dns, then don't nat your internal networks.  Or you going to have to create routes on your dhcp server that tells it how to get to that private network which is pfsense wan IP.  And then allow that traffic pfsense firewall to get back to your clients.  Not very common setup, and to honest the way around it would better design where you do not nat your internal networks.  And only nat them at the edge.

    Again lets be clear, using private and public address space in your network does not require nat internally.  The only place where you have to nat your private IP is when they actually go to the internet..



  • Hi john,
    sorry, I have overseen your answer.
    @johnpoz:

    But you do not have to nat it at pfsense..  You can nat your rfc1918 space at your edge when it actually needs to be natted. … Again lets be clear, using private and public address space in your network does not require nat internally.  The only place where you have to nat your private IP is when they actually go to the internet.

    I know, but I wrote in requirements:
    "- for technical and organisational reasons {we} can't use border or global-network routers for NATing for the next few years until real budget for new border and/or NAT-Hardware rains in"
    Thats what made this case unnecessarily difficult. But I cant change that for the next two years.

    Here is your problem your trying to send a dhcp relay through a nat.. How does your dhcp server send back to the IP address given by the relay which is your private IP behind pfsense.. How is it suppose to know to send it to pfsense WAN public IP??

    We added a static route towards internal relay-IP via the pfSense-WAN-IP in main network. Now the central DHCP-cluster can manage the IP-Adresses in the NAT-virtual routing domains behind the pfSense(s). Works very good.