How to DHCP relay with DHCP server on WAN side?
-
@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. -
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). :-)
-
" 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..
-
" 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?
-
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.
-
Hi
I'm actually trying to do the exact same thing.
I know this is an old thread but can you explain more the last post - setting a static route to allow a DHCP server on the "WAN" side to be able to maanage address through the NAT?
I've been trying to play with this configuration to make it for for an hour now but can't manage to work out what Static Route configuration you mean.
Thanks!
Paul -
That user has not been on since 2017... So highly doubt your going to get any sort of response from them.
He scenario was clearly ODD.. And his work around was just that a work around for a borked setup.. I would suggest you rethink why you would want to run a dhcp server on a wan for network behind a nat firewall in the first place.
-
@johnpoz Cheers for the reply. You are correct about the approach toward DHCP. It was more of a thought experiment to try and align some new architect with services we already present corporately. It seems now the sensible thing to do is to change the deployment of those services rather than fit an architecture around a legacy pattern. P
