DHCP on blue used from green!

Hi folks,

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?

Thank you!

Welcome to IPFire. @lordnemesis !

How did you realise your networks? Both by Ethernet?
Have you assigned the logical networks ( green0, blue0 ) to the right NIC?

1 Like

Hi Bernhard, thank you for getting back to me.

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

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 - 199 and blue serves up – 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?

1 Like

Yes and your net mask should be


I am not sure that will necessarily help.

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.

1 Like

Hi @decibel

I missed that. Very good observation. That means that the green and blue ranges are both considered to be part of the same subnet I think.

1 Like

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…

Thanks everyone for your feedback! I’ll post here once I get blue reconfigured.

The disabling of the blue dhcp and correcting the netmask on both blue and green can both be done from the wui page.

1 Like

Both networks green0 and blue0 belong to!
So a netmask of will seperate them to

blue0 :
1 Like

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.

Missing informations about your actual config are

  • 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.

See also

1 Like

Hi friends.

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 assignment of the interfaces:

         │ GREEN : "pci: Intel Corporation I210 Gigabit Network    ▒ │
         │ Connection (rev 03)"                                    ▒ │
         │ GREEN : (00:xx:xx:xx:xx:21)                             ▒ │
         │ RED   : "pci: Intel Corporation I210 Gigabit Network    ▒ │
         │ Connection (rev 03)"                                    ▒ │
         │ RED   : (00:xx:xx:xx:xx:20)                             ▒ │
         │ BLUE  : "pci: Intel Corporation I210 Gigabit Network    ▒ │
         │ Connection (rev 03)"                                    ▒ │
         │ BLUE  : (00:xx:xx:xx:xx:22)                             ▒ │

DHCP configuration:

Not knowing if it was the Client’s problem, I opted to put fixed IPs on those Green teams that took Blue IPs.


According to the DHCP protocol

DHCPOFFER \<IPs\> \<IP DHCP server:67\> -->\<offered IP\>:68

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 The Blue DHCP server is turned on and serving up an address to the attached smartmeter.
Also, the DHCP server on Green ( 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… :slight_smile:

Did you set up your blue access


Wui menu Firewall/Blue access

1 Like

I assume you know that is not a private address,
only the 192.168.*.* is a 16-bit block private space.

If you need to use /16 blocks, green can be 10.20.*.* (65535 hosts) and
blue can be 10.60.*.* (65535 hosts)

1 Like

Goodnight @pavlos

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.

Greetings from Spain :smiley:

Hi Paul, I only need /16 on Green, not on Blue.