AFAIK you can’t have the same subnet (or part of existing subnet) into different interfaces of any router.
So:
Green: 192.168.0.1/16
Red: 192.168.1.1/16 Does not work
Green: 192.168.0.1/16
Red: 192.168.1.1/24 Does not work
Green: 192.168.12.1/24
Red: 192.168.1.1/24 Works
The first issue is routing, the mechanism should not have doubt on which adapter should talk when reaching a IP address.
Also, while every private subnet could be technically used in different ways than original networks class (supernetting) is way safer use shrinked versions of bigger classes.
Better (IMVHO) 172.16.20.0/24 or 10.91.1.0/16 rather than 192.168.1.0/16.
My current (first) IPFire works OK, green subnet is 192.168.0.1/16 red interface is connected to a fritzbox, red IP address is 172.17.0.2.
Goal is now to replace the hardware of first IPFire.
I’ve set up a new (second) IPFire installation on a Sophos SG230 and restored a backup from first IPFire. Additionally some files and configs should be copied from first to second IPFire.
I’m now searching for a solution that enables second IPFire to access the internet trough the (green) LAN of first IPFire, to install required packages. Furthermore, I need access to second IPFire using WebIF and SSH.
Overall question is: How to set up the network on new, second IPFire to achieve above?
Question: Static IP address or DHCP on red interface? If static, which address. If DHCP, which one should I use (from first DHCP)?
Question: Which subnet should I give the green interface, so I can get access to WebIF and SSH from any PC from green network of first IPFire.
Option 1: you change the RED interface IP address and connect on the red counterpart of your current IPfire (I am assuming you have a Customer Premises Equipment of your ISP provider), connect then directly to the SG230 with your current setup. Using a small switch if needed.
Option 2: you change both SG230 interfaces IP address (first Green, than red) so you can keep your red interface into your current APU2C4 green subnet.
When ended, connected directly on your SG230, you can revert back to the subnets you need.
Edit: options reported before assume that your scurrent SG230 ip addresses are the same of AP2C4.
If you have the Forward and Outgoing rules set to the default Allowed on your first IPFire then you will just be able to access the internet directly from your second IPFire.
I have a development IPFire on my network whose red interface is on the green subnet of my main IPFire and it access the internet with no problems.
The way I have done it is to have a fixed address for the second IPFire on the dhcp server of the first IPFire. Then my second IPFire has the red interface set to dhcp and it simply gets the fixed address IP from the first IPFire and then you are connected.
The green subnet you are using for your second IPFire makes no difference as long as it is a unique, non overlapping subnet. To access the WUI and the SSH of the second IPfire from the green subnet of your first IPfire, ie on the red side of your second IPFire, you need to create port forward firewall rules to allow the WUI access and another to allow the ssh access. Normally you would not do that but as your red side of the second IPFire is protected by the first IPFire then that is okay in this case.
You might also need to re-create the ssh certificates on your second IPFire. As you restored them from a backup of the first IPFire then the keys will be identical and you could end up in a conflict that your ssh request will go to the ssh server on your first IPFire.
EDIT: You might be okay with the same ssh keys as the ssh command specifies an IP or a resolvable FQDN so that will point to the correct system.
It is just not best practice to have the same ssh key on more than one system but for your temporary setup that you have described, that should be okay.
The main idea of a router is connect several different networks.
Your first IPFire connects the FritzBox network 172.17.0.0/24 (…/16?) and your LAN 192.168.0.0/16.
Your second IPFire in the LAN is connected on the RED interface to the 192.168.0.0/16 network. The interface GREEN must establish a disjunct network, because 192.168.0.0/16 is a complete private network you must choose some other private network ( are a part of ).
BTW: Why do you use the whole 192.168. network for GREEN on your 1st IPFire? Are you expecting 65534 devices in the LAN?
No, of course not. I’m doing some grouping of devices for better handling in e.g. firewall groups and later on in Grafana dashboards.
Which means there are five persons in my household. Each person’s device gets its own IP group. E.g. P1 192.168.21.x, P2: 192.168.22.x and so on.
There are several APs, virtual machines, guest Wifi, IoT devices, Sonos speakers and much more. Again each of them are grouped into their own “subnet”.
When adding FW rules I can use a network like 192.168.21.0/24 in rule definition instead specifying each device by its IP address or MAC.
Works perfectly well even when it comes to reporting in Grafana. I can visualize the persons’s traffice again by specifying a range of IP adresses like 192.168.21.1 to 192.168.21.254 that is related to P1.
The same applies for uncountable virtual machines running on my proxmox. Either for allowing access to internet or isolating them from doing so.
Maybe there is a slight overhead in IP addresses, however it works and hopefully will later on as usual when I migrated the current IPFire hardware.
These arguments are understandable.
But with a /24 network you can also build 8 /27 networks, if we neglect the two special addresses .0 (network address) and .255 (broadcast address).
Each of these parts contains 32 addresses.
A /17 prefix length can be used for two networks 192.168.0.0/17 and 192.168.128.0/17.
This means that any outgoing access from the second IPFire’s zones can occur without any problem. However you still need to create a FW rule to allow access from the red side to the WUI port.
Basically you are on the internet side of the second IPFire so any attempt to access the WUI of the second IPFire will get dropped.
I have created a tcp service called IPFire WUI with the port number 444 but you can also just use tcp with port 444.
This works fine for me and I can access the WUI of a development IPFire from a machine on my production green subnet which the red interface of that IPFire is also connected to.
It saves me from having to connect a separate machine to the green side of that IPFire, although I can also do that.
Hope this helps.
EDIT:
With FORWARD blocked on your first IPFire it means that if you want to access the internet from your second IPFire then you need to create a firewall rule on your first IPFire to allow access out, the same way as you will have done to allow access for your other machines on the green subnet of the first IPFire to access the internet. Unless your FW rule for those machines on that first IPFire green subnet gives access to all machines on the green subnet, in which case the red connection of your second IPFire will be covered by that rule.
On the dev machine, so the second ipfire in your case. By default nothing can get into an IPFire from the red interface unless there is a FW rule allowing it.
The source was an IP from the machine on the prod LAN that I want to access the WUI on.
You can use whatever you like. I used a 192.168.xxx.yyy/24 subnet.
The important thing is that I ensured that the subnet of that green network on the dev did not overlap with any other subnet I am using anywhere in my network. That also includes things like OpenVPN tunnel subnets, IPSec subnets and WireGuard subnets (RW & N2N).
All of the subnets I use are always /24 which means if the third octet is different in the subnet then it will not overlap. It just makes it easier to deal with.
All of my tunnel subnets are always 10.10.xxx.yyy/24 subnets so I can be sure they will not have any match to any of the lan subnets I am using.
OK, so I’m already one step further now. I will use the names dev and prod now for simplicity.
My dev’s red network works since I can use pakfire to install some needed packages already, dig works, too which means the DNS address from prod IPFire was assigned to red on dev IPFire. An additional FW rule on prod was necessary of course.
But, now the last riddle to be solved: As mentioned above, I’ve given the subnet 10.10.10.1/24 to the dev’s green interface.
Adolf, you mentioned with quote above, you added a FW rule to the dev with source IP from prod LAN and target the red dev IP, which can be selected from the appropriate drop down box in FW rule definition, target port 444.
This said, it’s now clear from the perspective of the dev machine why I need this rule, you mentioned it, too.
But, how can I add this rule in WebIF on the dev machine, if I cannot access it before creating this rule?
Dev machine, red network set up as mentioned before, assigned an IP address from DHCP pool from prod IPFire: 192.168.0.98
Dev machine, green network. First used an IP address from prod, not yet used. E.g. 192.168.0.99/16 and accessed WebIF of dev with https://192.168.0.99:444 all others IP addresses failed.
Afterwards I could access the WebIF fromdev and added two FW rules.
First rule: source network 192.168.0.1/16, target RED 192.168.0.98 port 444 and a second rule with source 192.168.0.1/16, target RED 192.168.0.98 port 222.
The source addresses are those from the green network of prod IPFire.
Basically this means all incoming requests on port 222 and 444 on dev red network will be forwarded to the RED network.
Puhh, hard work. Anyway, thanks for all participating this thread
This has to be done by connecting a machine to the green network of your dev machine just the same as described in the IPFire documentation for installation.
This is your only possibility because by default you can’t access the dev green from the dev red interface without FW rules to allow it.
This basically means that your green and red subnets overlapped. As you were able to access inside the dev machine from the dev red interface without a FW rule present then it means that you have a big security hole between your red and green interfaces on the dev machine.
You need to fix that overlap by changing the subnet for green or red so they no longer overlap but likely then the FW rule you created might no longer work so then you will need to connect something like a laptop to the green connection of your dev ipfire.
