DHCP broadcasting over subnets
-
Hello,
I have two pfsense routers one on the 192.168.20.0/24 subnet and one on 192.168.25.0/24. I have a Windows 2012 DHCP server on the 20 network. I have tried setting up a DHCP relay on the 192.168.25.1 pfsense machine but I always get an address on the 192.168.20.0/24 network. I have tried turning off the DHCP relay and get the exact same result (an address on the 192.168.20.0 subnet). The machine works perfectly if I manually set it to the 25 subnet.
I have seen lots of people having the same issue if the scopes are set as superscopes but that is not the case for me.Does anybody have any ideas how I can fix this?
-
So why are you running 2 address schemes over the same wire.. Normally it is impossible to broadcast to a different network segment, which would be why you need to run a relay so that you can have a dhcp server serve IPs to multiple segments.
If your getting an IP from your .20 server while your on .25 - then you have an issue with your network segments not being isolated like they should. Fix that and your issue goes away.
-
Thanks for the response.
Basically what I am trying to achieve is to have the WAN connected to one pfsense box and all of the production machines connected to that router on 192.168.20.0/24. A second pfsense box with multiple subnets (I'm just trying 192.168.25.0/24 for now) with a few testing machines connected to it. I want to keep the two routers separate as I will use the 25 network for testing and can't afford to have downtime on the 20 subnet.Have you got any ideas why the segments wouldn't be isolated? I can't seem to find any reason although I know there must be something.
-
Because you have them connected with a wire ;)
draw up your network please - You say multiple subnets, so this second pfsense should have a 20.0/24 interface that connects it to that network.. And then more interfaces for your other segments. You need switches that support vlans and you could go that route.
But if you have something like say this your going to have problems.
See pic 2 for how you would isolate your segments
-
Thanks for all the help!
This is how it is currently set up.
Can you see any problems with this?
 -
Those vswitches are in esxi or something?
I would assume that your lan of your pfsense 20.1 is connected to same vswitch that your pfsense 25.1 lan is connected too.
From that drawing the onlyway I could see you getting cross talk across your segments is you have shared vswitch for both your 20 and 25 segments.
Those physical switches are different switches right? And there are no loops, ie you don't have any wires running between the 2 physical switches?
What ties those vswitches to the physical world - what nics in what is hosting the vswitches?
-
Yes they are in esxi.
No the 20.1 LAN is connected to the same vswitch as the 25.1 WAN.
Yes they are completely separate switches and the second one only has the LAN from the second pfsense and one computers connection in it currently.
Both pfsense VMs and the DHCP server are all in the same ESXi box. Both of the vswitches are connected to separate NICs. There is also a separate NIC connected to the 1st pfSense WAN and more connected to the second pfsense for the extra subnets but these are not yet in use. -
Dude here is the thing - broadcasts do not pass segment boundaries.
So either you got something setup as a bridge passing traffic, a dhcp relay example. Or you have some cross over in your physical/virtual network that connects your networks to the same wire.
It should be impossible for your 20.1 dhcp server to see broadcast packets from your 25.1 segment - so if 20.1 is seeing dhcp discover and sending offers then you got a issue with your physical network being connected.
can you post up your esxi network setup? Impossible to point out where your issue is without understanding your network - do you have vlans setup on your vswitches?
In a normal setup it would be impossible for 20.1 to see broadcasts or dhcp discover from devices connected to your 25.1 segment - so you have something connected together that shouldn't be.
