having been a pfsense user for the past 1000 years or so, I find some things confusing. I’ve re set up IPFire with red-green-blue instead of red-green-orange, as I found out that there isn’t a DHCP server available on the orange network. I have a smartmeter connected to blue (or will, when everything is working), so I needed a spearate network with DHCP.
Anyway, I have DHCP turned on both on green and blue. Nothing is plugged into the blue interface (yet). Still, all DHCP clients on green are in the IP range set up for blue… how can this be?
The device is a PC Engines APU2 with three ethernet ports.
One is assigned green (10.20.30.x), one red (goes to the cable modem, DHCP) and one blue (10.20.33.x). Netmask is 255.255.0.0.
Green is my general LAN which has everything on it behind the firewall. Blue I will use for a smartmeter to separate it from the rest - as soon as I get this sorted out. There isn’t even anything plugged into the blue ethernet port right now.
I’m not sure how to include screenshots here, but both DHCP servers on green and blue are turned on, green serves up 10.20.31.150 - 199 and blue serves up 10.20.33.15-199 – but all DHCP clients on green (physically connected) have blue DHCP addresses…
After looking through some options, I’m thinking the easiest solution might be to use a subnet for blue that is outside of 10.20.x.x - what do you think? Something like 192.168.1.x/24?
I suspect that when your green clients connected to IPFire maybe the dynamic rabge was defined in Blue but not yet in Green.
Either way your clients got a Blue ip and a lease. Basically those clients will now stay with that lease and when the lease time has gone down to 50% they will request a renewal of that lease and as long as it is still a valid ip address it will be granted.
I think your best approach is to disable the blue dhcp section by un-checking the enable box and pressing save and then force the clients to reconnect by either restarting their network daemons or rebooting them.
You are not currently using blue so it won’t create a problem and you can always re-enable blue when you need it in the future.
In that mode they will only be able to get green ip’s and their old blue ip leases will no longer be valid so they can only get the green leases. Once they have those leases then they will stay on the green subnet even if the blue is re-enabled.
I will give that a go, thanks.
Changing the blue IP completely will require me to bring the device upstairs and reconfigure via terminal, as it only has a serial port. I don’t see any way to change the blue IP from the GUI. That is something for Sunday, I think…
Agreed, but I have two more subnets in 10.20 - one is my wife’s office and one is for other stuff.
So I will have to switch blue to 192.168.0.x / 24
Will do that Sunday and report.
network definition in setup for green and blue ( networkaddress, mask )
association of NICs and networks in setup
definitions of DHCP ranges ( for dynamic leases ) and fixed leases
BTW: did you get errormessages abour overlaping networks?
How do you realize your 'sub’networks? IPFire usually uses distinct networks ( defined with CIDR notation ) for the network zones green, blue, red, orange.
The same thing happens to me in a Client. I thought I had a mess of cables and that’s why I was having problems, but looking at this, I see that I’m not the only one.
the DHCPDISCOVER packet must be received on the NIC assigned to the zone. Broadcast packets are not routed.
If the server hands out a ‘blue’ IP for a ‘green’ client, this client must be connected in some way to the blue NIC.
My opinion. Fixed/static IPs do not remove this false connection.
Okay, since I found out that you don‘t have to re-attach a serial connection in order to change the Blue IP, but can rather just SSH into the device and do that via setup, I‘ve now changed Blue‘s IP to 192.168.10.1/24. The Blue DHCP server is turned on and serving up an address to the attached smartmeter.
Also, the DHCP server on Green (10.20.30.1/16) isn‘t phased by this. So far so good.
Unfortunately, the Smartmeter apparently isn‘t getting a connection to the internet.
I don‘t know what is wrong here, there are no firewall rules set up (which I find strange as well - I would have thought that there would be at least some standard rules like anti-lockout, etc.).
At least the devices on Green are getting Green DHCP addresses and not Blue addresses…
I know that it is not an a, b or c class address, but it is what it is and this (I have found it in several clients) is inherited from before that classification and now, let’s see who is the nice guy who changes it …
I am not the IT person, I am the provider of a perimeter solution that I have to adapt to what is there.
Ideally, they would put a correct range, but I am not the one to decide.
