Aliases and orange network

[1] Could we use public IP range (assigned by the ISP and different from the red range with its own gateway) for Orange network or must it be private range with port forwarding from red interface range with aliases?

BTW, should I use public ip range (assuming its valid configuration) in the orange zone for DMZ, should I turn masquerading off for orange under firewall options?

[2] Lets say we use aliases for red interface, how do we scale when the range is exhausted; for example in a /28 we have only 13 IPs usable; however, I want to have more than 13 DMZ hosts to be port forwarded to?

Also, what happens when I obtain a second ip range for the red zone and how do I configure that? Does aliases for red work from a different subnet? How would the routing be then?

Please advise. Thank you.

Hello @trine. Welcome to our community.

First question

you’re seeking an IPFire configuration that leverages public IP addresses, allocated by your ISP and routed to IPFire’s RED0 interface, for direct use by devices in the DMZ (ORANGE zone), bypassing the use of Network Address Translation (NAT). This approach requires a careful blend of Layer 2 and Layer 3 networking strategies, utilizing the Address Resolution Protocol (ARP) to accurately direct incoming internet traffic to IPFire, which then routes the traffic to the designated servers in the DMZ based on precise network routing and firewall configurations.

For this setup, I think there are three critical steps. It’s important to note that my networking knowledge has its limits, as I’m primarily an enthusiast. Therefore, while I offer this guidance, I encourage seeking further validation, perhaps from a more experienced developer or network professional.

Firstly, the RED0 interface on IPFire needs to be set up with aliases corresponding to the public IP addresses your ISP has provided. This configuration is crucial for enabling IPFire to recognize and manage incoming traffic meant for these IPs.

Secondly, within the ORANGE zone, you’ll need to assign some of these public IPs directly to your devices. This can be achieved either through static IP configuration or by deploying a DHCP service specifically tailored for the ORANGE zone, which assigns public IPs based on the MAC addresses of the devices.

Lastly, establishing firewall rules on IPFire to permit internet traffic to reach these DMZ devices is essential.

Putting all together, when an external system attempts to communicate with one of the public IPs, it issues an ARP request to determine the MAC address associated with that IP. Because the public IPs are aliased on IPFire’s RED0 interface, IPFire responds to these ARP requests with the MAC address of RED0. This response directs the external system to send its traffic to IPFire. Upon receiving this traffic, IPFire then relies on its internal routing table and the specified firewall rules to forward the traffic to the correct server in the ORANGE zone. This forwarding process, rooted in Layer 3 IP routing, should not necessitate any alterations to ARP behavior beyond ensuring that IPFire can respond to ARP requests for the public IPs it manages.

This methodology represents a non-traditional application of IPFire, which is typically employed to improve LAN security by segregating the public and local IP spaces and leveraging NAT for traffic management. Nonetheless, I believe that IPFire’s versatility as a Linux-based firewall allows for various configurations, including the one you’re considering.

Second question

I believe assigning IP aliases in different network range should be possible by using <IP-Address>/<Mask> notation.

To scale your system beyond the initial allocation of public IP addresses, integrating traditional Layer 3 (IP addressing) and Layer 4 (port services) methodologies is a possible solution. This involves port forwarding, where a single public IP address directs traffic to multiple internal IPs, distinguished by specific port numbers.

Alternatively, employing a reverse proxy offers another common solution for traffic management at the application layer. A reverse proxy can intelligently distribute incoming traffic based on the requested service, domain name, or other application-layer attributes. This not only facilitates the efficient use of public IPs but also enhances security, load balancing, and service reliability.

Both strategies—port forwarding and reverse proxy deployment—provide viable paths for scaling your network’s capabilities, each with its advantages in terms of resource optimization, security, and traffic management.

1 Like