Example of how to configure IpFire as internal firewall?

Example of how to configure IpFire as internal firewall? I already have a router which is comparable to IpFire. However, what I need to so isolate part of my local network into two zones. Where zone 1 is behind my current router, then zone 2 is behind the IpFire box. In effect establishing a zone 1 as a DMZ.of sorts.

Say ISP->192.168.0.x->IpFire->192.168.1.x, for example. The 192.168.0.x segment will have DNS and DHCP/static ip assignment via the router. Where as the 192.168…1.x segment will have dedicated DNS and DHCP servers.

Thus, per my (limited) understanding, all I need is for IpFire to forward DNS queries that are non-local, and forward outbound communication to the router. But I have been having trouble finding examples of this? Or maybe my limited understanding is not letting me realize the examples of for this exist?

I found a couple of pfSense and OPNsense examples but the interesting thing is, after implementing these, they don’t work… likely because they all seem to be quite dated… 2021 or 2022 time frame, appears pfsense and OPNsense have moved on or changed such the examples don’t work? I prefer IpFire since I have more experience with it, since my first custom router was based in IpFire.

This ought to be a case where you plug it in and it works, so some more detail on your setup may clarify things.
My understanding is that you are setting up a traditional second firewall to protect Green zone items from possible compromise of the Orange and then of your edge router by inside attack. To this end, you have (I expect) two LAN ports on your edge router where the one to your servers is Orange and speaks only to and from the internet, while the second is to your IPFire and allows access anywhere out (to Orange or Red).

Now, your IPFire will block anything in on its Red and allow anything out from Green. Where it gets its DNS can ultimately be determined by the edge router. DHCP for Green will be managed by IPFire. Any variations on what I have described?

I currently run internal routers for different purposes (using suitable things I had to hand), and this week have one to which this computer is attached for configuration (inside Green on the edge router). It does not get in the way; I’m ‘talking’ through it now. This should all be pretty routine, nothing special in the configuration unless you are trying to vary normal basic configuration and behaviours of the equipment. Please clarify if this is so, perhaps around DNS and DHCP?

2 Likes

Yes, you pretty much have it scoped out, the edge firewall/router is the first layer of protection after the ISP connection, which is via a separate cable modem connected to the firewall/router WAN port. I then have a LAN side port that goes to the ‘DMZ’ rail, and another LAN side port that goes to the ‘Internal’ rail. The IpFire device is connected to this internal rail, and all other internal devices, switches, etc., are downstream from the IpFire device.

The red interface on IpFire faces the firewall/router, green interface faces all internal devices, etc., as you suggested.

Everything is working as expected, with the default installation of IpFire. DNS forwarding is done by dedicated DNS servers on the internal rail. DNS for the DMZ rail is done via the firewall/router. DMZ rail is static IP only, whereas on the internal rail has dedicated DHCP server is used, as applicable.

I only see one explicit rule that is applicable SMTP? But I see elsewhere in documentation that IpFire by default blocks all incoming traffic? Trying to understand where my starting point is. You noted that everything is stopped in-bound at red, and everything is allowed out-bound on green.

In the near future we plan to have a web server and NAS device on the DMZ rail. Likely we will use a private VPN to provide in bound web server and NAS device access, over port forwarding. To do this, I know I will need to modify the edge firewall/router rules, with no changes expected on the IpFire firewall.

For now I just want to understand what basic rules I need to setup to protect the internal rail, if any at this point. With no in-bound requirements, and out-bound requirements seem to match the default configuration.

One rule I would like to create, is to have red interface NOT respond to pings from any device on the DMZ rail. As I recall in reading about IpFire this is one of this first recommended rules. My concern is that if red is blocking everything by default, this does not including pinging?

Our current firewall/router by default blocks all incoming connections, from its WAN side access. I would like to ensure that IpFire as a starting point is doing that as well. To understand how when I look at IpFire configuration, I know this is the case?

IPFire use NAT routing so incoming traffic on RED is blocked because there is no DNAT (Destination Network Address Translation) target defined. You need always rules to accept traffic from red.

1 Like

PING is part of ICMP (Internet Control Message Protocol) and should never blocked! This can cause delays and timeouts. It is needed for Auto Path MTU and other features.

Hiding by droping icmp requests counts as security by obscurity and will not work becuase the router before your system gives an error if an IP really not exist via an ICMP not reachable message. If this message is not generated a IP is active even if it not answer to ping…

1 Like

You are right, I did some more research, and realized blocking type 8 would be a problem, so I just set a rule that does a rate limit on pings for type 8.

One more question… For testing I am using the IpFire (integrated DNS and DHCP) services. However I need to disable these functions and use the existing dedicated DNS and DHCP servers.

Am I correct that I just need to disable DNS and DHCP on IpFire? Then:

  1. Set the dedicated DHCP server to assign the default gateway as the IP address of the IpFire Green0 rail

  2. Given DHCP server assigns DNS server for the clients, that should work as expected, DNS server is set to forward to ISP DNS servers

  3. Need to ensure the DNS server, since static IP, is using the IpFire device as default gateway target

On Red0 rail, i.e. DMZ, all devices on this rail work as expected, they use the DHCP/DNS services on the edge router, that router as gateway of course.

I guess the next thing to enable/test is that DNSSEC is completely functional on Red0 and Green0.

Anything else I need to look at once I complete the above steps?

Unless I have missed something about what you are doing, or how it is being expressed, using the edge router to provide DHCP to devices on Green means you have abandoned the internal firewall – it will be acting as a bridge. Was that your intention?

DNS is independent.

2 Likes

Or maybe I need to clarify a bit… Rereading my note above, I was bit loose with the wording.

Green scope use dedicated local DHCP and DNS servers, forwarding queries only when applicable to internet resolution.

Red scope is static IP assignment, and DNS using ISP provided DNS servers.

I have yet to validate DNSSEC for green scope, i.e. our local DNS servers.

Outstanding tasks, setup a functional VPN to red scope, for a specific server that will be internet visible. And, using ISP static ip or dynamic DNS as well.

Interesting thing is, I found setting up IpFire as an internal firewall much more straight-forward, i.e. easy, than either OPNsense or pfSense. May have a bit of bias… having used IpFire before, a couple of years ago.

Everything has been working fine for some time now, but I did discover one quirk or issue. I can ping my dedicated cable modem from green and red rails. but I cannot access my cable modem via its administrative ip address, from either the red or green rail? As is typical with cable modems, its ‘LAN’ side ip address is static, cannot be changed. But before I setup IpFire, I could always connect to it from the LAN side.

Old setup…
ISP<>Modem<>Router<>PC
New setup…
ISP<>Modem<>Router<>IpFire<>PC

Arris Surboard Cable Modem, I can ping it via PC and even if I move my PC to the red rail to test, can still ping it, but if I try to connect HTTTP nothing? Since it is an outbound HTTP connection from the PC perspective, puzzled why I cannot connect to it? It is not a certificate issue with the browser, I am overriding the HTTPS requirement. Any suggestions?

If you have static IP address on your PC, then it needs the address of green0 set as a DNS server.

Sorry but how would DNS be applicable when I can ping the modem IP address but cannot connect to it via HTTP using the IP address? Maybe I did not qualify that well… But to be explicit… I think I just have a protocol/firewall rule issue which seems odd given it is outbound from PC in green, to cable modem on the far side of red0.

My IpFire is an internal firewall… The route to modem, which is working in all respects but accessing its ‘LAN’ side, i.e. red side, administrative interface…

ISP<>Modem<>Router<>IpFire<>PC

So wonder if anyone else has seen this odd behavior. In that, the HTTP attempt is from green, across red to cable modem… that should be fine, as I understand it, since it is outbound from green. I have added no custom rules to IpFire. So this issue may not even be IpFire related, just that the last change to the enviroment was the add of the IpFire as an internal firewall.

I think you need a static route on your edge router.
To reach edge router GUI.
You can’t reach it because you are in a different subnet.

@jibun-no-kage , do you have this effect just after a reboot of the cable modem also?
My cable modem ( in bridge mode ) ‘forgets’ its HTTP server role after some time. Don’t know why, it is the property of my ISP, which administers and updates the device.

That occurred to me as well, about the time I posted my question. I will be rebooting the modem this evening, and report back. My cable modem I own, but I know the ISP has pushed changed firmware at times, they removed the ability to do a remote (over HTTP) reboot for example, so you raise a valid question of course.

@hvacguy, I can get to the edge router with no issue from the far green rail, i.e my internal LAN. The cable modem is of course on WAN side of the edge router. I made no changes on the edge router at all, I just added the IpFire box.

For sake of discussion, if the cable modem is 192.168.100.1, and red rail is 192.168.0.x and green rail is 192.168.1.x. So…

192.168.0.2 Edge Router Red Rail
192.168.1.3 Green Rail Default gateway

If I do a trace router from PC (Windows 11, tracert)…

> tracert 192.168.100.1

Tracing route to 192.168.100.1 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.3
  2    <1 ms    <1 ms    <1 ms  192.168.0.2
  3     2 ms     1 ms     1 ms  192.168.100.1

Trace complete.
>

Clearly there is a route. And ping of course works as I noted above, so the issue has to be either the modem is not responding to HTTP, or there is some filtering of HTTP protocol, is my current thinking.

Reboot of the modem did not resolve the issue. Tomorrow I will direct connect to it. If that works, then I really do believe there is something blocking the HTTP protocol unless someone else has any additional idea?

Well, this pretty much tells the story…

[root@frantic ~]# telnet 192.168.100.1 80
Trying 192.168.100.1...
telnet: connect to address 192.168.100.1: Connection timed out

Since 192.168.0.2 is red rail on IpFire, the IpFire box can’t transverse the edgerouter, or Spectrum Cable has blocked the UI access on the cable modem.

The edge router has an explicit static route to 0.0.0.0/0 next hop 192.168.100.1. Which explains the previous trace route success. So all that I can do is direct connect to the cable modem and see if 192.168.100.1 responds to port 80, it not, ISP has yet again customized the firmware on the SB8200, not really a surprise… there was a recent upgrade to the base service level.

1 Like

I have a similar problem with a router in my blue zone. Can’t connect to GUI from blue.
Not sure how to fix this.
Could it be that IPFire red appears to have lots of mac addresses there by is not offered access to GUI?
No mac to ip association ( ARP table? ) In the Modem.
Some layer 1 , 2 magic?
Perhaps SNAT rule in IPFire?

You should not need a static route/nexthop on your edge router, I believe. As 192.168.100.x does not exist on the edge router LAN is should automatically forward it to its WAN.

1 Like