Do you have full access to the NATing/routing in the ISP’s router ( not just modem )?
If not it is more secure to separate the networks. All incoming/outgoing traffic is filtered, there is no bypass. To avoid double-NAT the ISP router should be in bridging mode ( or much better the device operates as a true modem ).
In my experience, I prefer an IPFire that does NAT, since if it would be Bridge, there would be no Firewall, there would be no IDS / IPS, there would be no GeoIP, there would be no P2P filtering … so what would it have? I think nothing. It would only have the Squid (Proxy) to analyze that, only http?
It is my opinion.
Greetings.
I have full control over the routing in ISP’s router but I don’t want it to be in bridge mode as that would turn off its DHCP server and I would be back to the original problem of having to use IPfire’s DHCP server.
We have decided that IPfire does not do bridged-network mode but SophosXG does.
Just because a firewall doesn’t do NAT, that doesn’t mean that it can’t do all the normal firewall protection services that it would do normally.
In my tests with Sophos, (in bridge-network mode) all the normal rat-bag sites are blocked and nothing gets from the WAN to the LAN unless a rule is created to allow it.
What’s wrong with IPFire’s DHCP server?
How this? The WAN gateway is the ISP router, which is part of the LAN. So each client can decide to go directly to this device.
How do you force usage of Sophos?
As stated earlier, I need to have my network working with or without the firewall in place. If I use the IPfire’s DHCP server, I cannot get the same addresses when it fails and the ISP’s router starts serving addresses.
Simple - all outgoing traffic goes into the firewall’s LAN port, is processed as per the firewall rules and if acceptable, the traffic then passes out the WAN port towards the ISP router.
Let simplicity be the guiding light.
1 Like
Usually by definition when you are bridging the wan RFC1483 what usually is bridged is the device from the ISP, usually called a CPE (customer premise equipment)
This is often only requested by IT staff the prevent a double NAT scenario when the ISP CPE has NAT enabled and does not route another public IP subnet to the Customers Edge Device.
When the ISP CPE provides DHCP in the RFC1918 address pool (192. 10. 172. etc) and the Customer has their WAN set for DHCP client they will also have NAT with another RFC1918 address pool on the LAN that they will also NAT. This can break many things most notably SIP and T.38 telephony.
There are 2 common solutions that are often implemented.
The RFC1483 Bridge mode which in essence turns the CPE into nothing more than a transport (Cable, Fiber, ISDN, DSL, WISP etc) to a simple Ethernet handoff. It then becomes the Customers responsibility to configure their WAN interface on their Edge Device, most often PPPoE with DHCP .and monitor it’s connectivity. NOTE!! It is highly recommended that this configuration has the port Speed and Duplex set to match the ISP CPE! When set to Auto/Auto too often the interfaces will constantly renegotiate speed and duplex causing multiple minor LOS and lost packets. Also along with this is to disable STP CDP to prevent unnecessary traffic overhead and resource utilization.
The other solution, which I would recommend per your reason for asking about bridging is to request a /28 IPv4 Block from the ISP. This would give you 5 usable addresses that you could then use to implement High Availability (HA) with VRRP and other methods (routed VLANS) that are beyond the scope of this reply. 3 WAN IP for the 2 firewalls where each has one at all times and the 3rd is the Virtual IP that is allocated to the Master until it fails and then becomes the “WAN” of the Slave. The 4th address I would assign (if applicable) to Public/Customer/Vendor WiFI/Ethernet Access and the 5th I’ve used for dedicated Point to Point backup replication or as a DMZ.
Hope this helps, if you have any questions do not hesitate to ask 
~frustro
Hope I’ve got it right.
Your LAN logically contains the WAN ( LAN port of the ISP router ). To separate WAN ( network of IPFire’s/Sophos’ WAN port and ISP router’s LAN port ) from LAN ( your local devices connected to IPFire’s/Sophos’ LAN port ) you technically assure, that no local device is directly connected to the ISP router.
So your technical installation fits the requirements of IPFire. Why not just use the routing firewall of IPFire?
The argument about failing of the DHCP server on the IPFire device doesn’t really count. In this case the bridging firewall may fail also. Leaving you with a transporting unsecured network.
A fail of IPFire usually cuts the data transfer to/from the WAN also, which results in an easy to recognize error indication.
Just my opinion.
Quite true, but my envisioned scenario allows me to patch out the faulty firewall while awaiting a fix. I am prepared to accept an unsecured network while the fault continues - at least it is behind the ISP’s router NAT wall.
You are absolutely right.
All modern enterprise firewalls have transparent mode nowadays: Fortinet, Palo Alto, Checkpoint, and also PFsense and OPNsense do have it.
It does almost all next generation firewall filtering and needs no IP address changes.
Just perfect for small businesses where you can just pull out a broken firewall as a quick fix.
Absolutely necessary also for inline harmless diagnose in an unknown network.