I understand that in bridge-mode, the public IP is directly assigned to the red interface of the ipfire. There is no NAT, but when an application is incoming on port 993 for example, it is going directly to the firewall interface at port 993. In router mode, this is not possible. The Ipfire does not see the public IP, but the local IP that was assigned by the router to the red interface. There is an additional firewall in front of the ipfire. Still, incoming services can reach the ipfire by a port-forwarding rule of the Cable router.
My question is: In which scenario is the bridge mode the better choice? Only when one does not want to create a lot of port-forwarding rules? Is there maybe better performance and power savings? Does it make sense to have an additional firewall in front of the ipfire (the function of it is often a complete blackbox, so its hard to evaluate). I mean, when the ipfire needs an additional firewall in front of it, how much does it say about its security?
Just my opinion.
In most cases ( all? ) it is better do operate in bridge mode. It is the most straight forward configuration.
My system consist of a cable modem, which mainly does the conversion from coax cable internet ( DOCSIS ) to plain ethernet ( IP ).
Surely there are some performance gains in switching off router mode. Routing isn’t a zero cost functionality.
Further there are conditions defined by the ISP for the internet access contract. In Germany, for example, the access device is owned by the provider. So you don’t have the possibility to configure the router optimal. Another benefit of this situation is the obligation of the ISP to maintain this device. You buy internet access at the ethernet interface of the device with a certain reliability. Therefore the ISP must handle problems or defects very quickly.
Your question of an extra firewall in front of IPFire isn’t really meant seriously, I hope.
The basic articles in the wiki about IPFire answer this question.
Surely there are some performance gains in switching off router mode. Routing isn’t a zero cost functionality.
Can you confirm this with accurate measurements (ping, throughput, power consumption).
In Germany, for example, the access device is owned by the provider.
As far as I know you can use your own cable and dsl modem or DOCIS modem on the access point. So, the ISP is not necessarily owning it.
The basic articles in the wiki about IPFire answer this question.
Which ones? Other users recommended using it only in router mode and using port forwarding rules. But as I mentioned earlier: I would like to hear arguments for and against.
I don’t know about recommendations to use IPFire in router mode only.
I thought my arguments were clear enough for the use of a cable bridge or cable modem in front of IPFire.
If you can choose the device, I would prefer a modem. A dedicated internet access firewall like IPFire ( see also wiki.ipfire.org - What is IPFire? ) realizes networking on an ethernet/IP basis, 802.11 ( WLAN ) is also ethernet based. So it is consequent to get internet access over ethernet also. The minimal requirement for this is device converting the real carrier to Ethernet/IP; this is a modem or modem/router in bridge mode.
i agree with @bbitsch that i would prefer the bridge or modem usage but in my case i have one point why we use the router mode in the office.
The point has nothing todo with IPFire directly but it was a showstopper for us.
The problem here (german Telekom) was the ip based phone connection and our internal telephone system.
So the provider router does a port forwarding to ipfire and the phone but all systems are behind the IPFire gateway. OVPN and IPSec is working the only problem you have is you can only initiate the IPSec connection from the IPFire gateway because of the NAT from the router.
I would assume from the beginning that bridge mode is more suitable when you have an firewall appliance. It appears to be the more logic and straight forward approach, also, because you don’t want to have any stuff in the routers lan in front of the actual firewall. Still, my question is: Is it only a question of convenience or are there metrics that stand in favor of bridge mode. Therefore I want to test the power consumption (idle, real world) for example for 3 days in router and in bridge mode. And perform maybe speedtests in bridge and router mode. Still, when I performed the speedtest by the pakfire addon, it did not even come close to the max. bandwidth in up- and downstream specified in my current isp plan. Is there a way, to get better, more accurate throughput rates and latencies measured directly from the ipfire? It would be interesting if there is a trend to see here in performance and consumption.
I would say that in almost every situation where your entire network is going to go through the IPFire box and then to the cable modem, that you would want to set the modem in bridging mode and let IPFire be your sole firewall and router. An example layout would be:
Modem ↔ IPFire ↔ Switch/WAP ↔ Devices
IPFire is a firewall distribution and is designed around the intention of having it serve as a firewall and is quite capable on that front. Putting another firewall in front of it (or behind it) doesn’t really add much security and adds a layer of complexity that is more likely to cause you headaches and problems in the end (i.e. having to create two or more layers of port forwarding rules for every service).
If you are connecting other devices directly to the modem, allowing them to bypass your IPFire box, then Bridging Mode would be a non-starter and you would have no choice but to use Router mode. An example would be:
Device(s) <—> Modem <—> IPfire <—> Switch/WAP <—> Other Devices
NOTE THAT IF YOU ARE USING YOUR CABLE MODEM FOR WIFI THAT THIS ABOVE SCENARIO IS THE ONE YOU HAVE
It is important to have at least one firewall (and preferably only one) between your devices and the internet.
A different consideration would be whether or not to make any Wireless Routers that you have on the green side also be set up in Access Point mode. If you don’t, they will effectively be a firewall behind IPFire and create issues with LAN clients not being able to connect to WLAN clients. There are situations where you might want that to be by design, but in most cases your entire local network is generally trusted and this would cause problems with sharing printers and network drives.
As you stated, it is much easier to do firewalling in just one appliance; IPFire is a firewall appliance.
If something is blocked you have to look at just one device. With several chained devices you must inspect each single one and additionally the relations between them. This is raises complexity.
How did you do the speed test? To what endpoint? Remember, the throughput of a internet connection can’t be higher than the throughput of the slowest line segment. Extreme example: coupling two Gb ports with a line of two dialup modems.
By using speedtest-cli.
The download rates are way off. From my laptop, I easily get 400 Mbit downstream, measured by the avm test. And this is after the ipfire, to my router/accesspoint with wifi to my computer.
Also my ping normally shows 20-25 ms. Normally I would get even more, but the problem is that my wifi connection seems to limits the connection speed under the max. possible downstream rate. The wifi should deliver 866 Mbit/s, but I never received more than 400-450 Mbit downstream. The line should deliver up to 1 Gbit/s (850 Mbit/s are more realistic). This laptop does not have an RJ45 port and I only have an USB 2.0 adapter so the result is biased. Still, it’s way more than everything the comandline on ipfire shows.
Selecting best server based on ping…
Hosted by Deutsche Telekom: 45.784 ms
Testing download speed…
Download: 72.12 Mbit/s
Testing upload speed…
Upload: 49.30 Mbit/s
I have a 1Gbit/s glass fibre connection for both upload and download and with the as installed IPFire I get 800+Mbit/s using the same speedtest-cli directly on IPFire.
If I turn on IPS then the upload/download goes down to around 300Mbit/s.
IPS requires a reasonable amount of memory but more importantly it requires a reasonable cpu capability.
The wiki mentions
The IPS also load-balances packets over all available processor cores. That, however, works best when good network adapter are in use that have multiple queues and also spread receiving and transmitting packets across multiple cores.
My system has intel network adaptors that are carrying some of the processing power but when running various speedtests I have often found that not all cores are active to the same extent indicating that the firmware is not maximising the load balancing
Hmm, yeah. Turning down ips increased the download from approx 10 Mbyte/s to 112 Mbyte.
So, I assume the only way to use the more advanced filter capabilities is by getting a stronger processor?
That’s similiar HW like Lightningwirelabs’ Mini Appliance. So I think, it should be possible to manage the requirements for IPS with your ISP’s parameters.
Maybe @ms can tell more about this.
The wiki page on performance considerations benchmarks the various Lightning Appliances and the Mini Appliance runs at around 130MB/s with IPS enabled.
I would always be a bit careful with ISP provided speed tests.
My ISP testing system includes all bits that are transmitted in it’s calculations, so including all the TCP header information etc.
This is not the real data that you and I will send down the line.
It is of course the actual number of bits being sent down the line because it is the data bits together with any header, sync, retransmit etc bits that are added to the data stream as required by the TCP protocol.
Most ISP’s want to show you the most favoured picture so they will always count any bit that gets sent down the line.
