Firewall Rules for Blue <> Green

Hey there,

I’ve been losing my mind to connect my Hue smart lights and Sonos to my network:
The Hue Bridge is connected via GREEN while my phone that is running the Hue app is in BLUE.
In order to set up my Sonos I have to first connect it to GREEN, configure it with my phone being in BLUE and then unplug the Sonos so it can connect to BLUE.

None of that works. I’ve tried to add all kinds of firewall rules - specific and less specific and my phone never finds any of those devices, making it impossible for me to set them up.

The las rules I tried were the most general I could think of:

(I know this is incredibly unsafe. I was just testing to see if anything works at all - it doesn’t.)

Any advice on how to achieve this?

Thanks!

Maybe this helps

and this
https://wiki.ipfire.org/configuration/firewall/accesstoblue

1 Like

Hi,
I’ve been totally crazy for weeks with this topic.

On my side it was impossible to access Green network from any Blue devices even by configuring the DMZ pinhole as documentation advices.

After having read this post, I tried again to configure the Blue to Green rule by playing with NAT options.

I find one that solves my trouble :grin:

Into NAT section:

  • activate => Use Network Address Translation (NAT)
  • Select Source NAT radio button
  • Choose Green interface into ‘New source IP address’ combo box

If somebody can validate this fact, maybe it will be useful to update this page : wiki.ipfire.org - Creating a DMZ Pinhole or this one wiki.ipfire.org - Firewall Default Policy into the line related to blue to green default policy.

To sum up here you are the full rule to allow Blue devices accessing Green network

Hi Patrick,
Welcome to the IPFire community!

I don’t have a Sonos so I am not sure how that might need to be configured. Does the first firewall rule not get things working?


Hi Sébastien,

Welcome to the IPFire community!
I tried the Creating a DMZ Pinhole and it works fine for me.

I also tried the your rule above and it works fine without the Source NAT. So I was not sure why it was added or needed.

Just out of curiosity…

Why have you put the smarthome devices or bridges in the GREEN segment? Isn’t it supposed to be the most secure segment in your network topology? Are you sure that these smarthome devices do not perform unnoticed and unwanted requests (“auto updates”) to the outside world (aka RED) and maybe introduce trojans etc. into the GREEN segment? I’m inviting you to considering putting these devices directly in the BLUE segment, or even better, in the ORANGE segment (DMZ).

In my case I have put smarthome devices in ORANGE and monitor its DNS and https requests with both the IPS of IPfire and also a PiHole in ORANGE that acts as DHCP server plus DNS resolver for any device in ORANGE. This way I can and minimize its DNS requests and connections to whatever manufacturer servers it contacts in RED.

Hi Jon,

Are you using also orange network and last ipfire version because without NAT activated it doesn’t work for me?
It was the addition that solves my connection problem from wifi network (blue) to my private Samba server (Green).


Hi Data Morgana,

I have updated the rule to allow access only to some services

On my side I have activated IPS on all networks and the only alert I have seen are related to some hacking attempts on Orange network.

Yes, I am using an Orange network. Only two items currently on Orange.

This is the version of IPFire I am using:
IPFire 2.25 (x86_64) - Core Update 154

I do not use a Samba server on my IPFire box.

Jon,
I have the same setup, maybe the only difference we have is the wifi access point.
On my side I’m using another router without WAN port plugged and with all possible services disabled (dhcp, dns etc…)

Hi there,
after getting a wifi module that’s working with hostapd I removed my external wlan-router (attached to green) and enabled the hotspot on blue.

Finally I ran into the similiar problems like the OP and Sébastien.
The solution by Sébastian made it!

I think the different experiences of Jon and others maybe due to their proxy settings?!
After enabling the internal proxy access
BLUE to GREEN and Proxy I could access the webserver of a device - BUT I still wasn’t able to access other services like ssh on the device.
Enabling the source nat finally did it!

Cheers,
Stephan

You should not need to set Source NAT at all.

Effectively that is saying that you have a machine on the blue network (192.168.2.0/24 in the case of @s8bordes ) but you are going to pretend that the machine actually has an IP of 192.168.0.254 on the green network.

I just set up a blue to green pinhole rule on my testbed vm system and it worked fine with no problems, both with the proxy enabled or disabled.

The rule is specific to only allow the machine blue1 on the blue network to access green1 on the green network.
NAT was not selected at all.
With this rule enabled I can access green1 from blue1 with no problems. With the rule disabled then there is no connection from blue 1 to green1.

Often when people have a problem having machines on the blue network recognised it has turned out that they have not defined the mac addresses for the blue machines in the mac filter section of the wui menu Firewall - Blue Access.

In the Blue Access section you need to either specify the mac addresses that are allowed or you need to put an entry that says that all mac addresses on blue are allowed.
This is what I have on my IPFire Blue Access page


I have entered the whole blue subnet (192.168.220.0/24) into the source IP box and left the Source MAC Address box empty as per the wiki page on Blue Access
https://wiki.ipfire.org/configuration/firewall/accesstoblue#Disable MAC Address filtering

Can you confirm if you have filled out the Blue Access page with the mac addresses or disabled the mac filtering

4 Likes

there is an argument to be made that maybe the default should be changed NOT to have the blue access filter ON. The first argument could be this user interface attrition, but more importantly the default setting of new android phones (ios as well?) of randomizing the mac address. Finally, the security advantage of a mac address filter ON by default can be argued is minimal, at least against a mildly determined attacker.

I am just putting out there the argument, not necessarily advocating for such a change. In my personal situation, the present setting is not a problem whatsoever.

2 Likes