I’m testlabing ready for the change although I have hit a bit of a wall.
I am looking to use pfsense as an internal routing device. All routing works fine and any static IP used is also fine.
our main network is 10.0.X.X (WAN Interface)
and this testlab is 172.16.X.X (LAN Interface)
I have a number of vLANs setup on the LAN and passed these to untagged ports for testing.
Again, static assignment, all is good.
I have disabled the firewall for testing and still nothing. I’ve enabled DHCP relay and set our dhcp server (10.0.98.101) as the destination server.
My thinking is that the DHCP server is on the WAN interface, trying to provide to the LAN interface is the issue for some reason.
A DHCP client always uses the local broadcast address to send a DHCP request. When pfsense is connected to that local subnet that receives a DHCP broadcast message and if the DHCP server is active on pfsense it will respond and provide an address. If DHCP server is off but relaying is configured then it will relay those requests to a defined server on another segment of the network. But I have no idea if that other segment can be WAN or upstream of WAN.
This is a very normal way to use a DHCP relay. Normally I relay from one LAN subnet to another LAN subnet, but without a firewall there shouldn’t be any functional difference between WAN and LAN. Is it possible to post a screen cap of your config? I’m trying to turn on the DHCP relay so I can view the settings, but my pfsense is having a fit saying I can’t have a relay if there’s a DHCP Server running at all. That’s a very bizarre limitation, but that’s a ticket for the pfsense developers.
Definitely nothing wacky, this shouldn’t be too hard. I’ve only ever done DHCP relaying on a Palo Alto though, so I’m not sure of the switches to flip on pfsense. Have you tried enabling the Append checkbox?
Yeh, just to make sure and still no relay.
i did think to build a DHCP server on a LAN subnet to test but i’m super sure that would work and not get me any closer to the goal.
So this is a definitely a “shouldn’t be the issue” suggestion, but maybe re-assigning your interfaces. Remove your interface from WAN and re-assign it to OPT1.
Like that shouldn’t matter, but I’ve seen stranger shit in my day job.
Well i got support and long story short, it just worked.
not sure if the service just needed a reboot then i did it last, i’m sure i rebooted a few times etc but when i lead the way during the support call, it just worked. GRRR!
does mean that it is possible and i asked if there was anything special about the WAN vs a LAN, he said no, it’s just another interface. No actions locked to WAN vs LAN.
from memory we found the issue was when we turned off packet filtering (this also turns off NAT as it says)
Anyway i don’t think we had a correct route back for this vlan. When support came on, i put it all back to normal and it just worked, because NAT completed the task.
not 100% of the fix in the end but it was clear once we understood the effect of disabling NAT/Static Routes.
