MikeX last edited by
Extremely vague title… I apologize.
Currently I have a single PF Sense CARP config which handles firewalling, routing, and NAT for a mix of public and private networks. I would like to move to a more secure platform with two sets of firewalls, but I'm not sure what would be the best of two options:
Edge Firewall + Internal Firewall
-First firewall Pair is 'edge' firewall for primary routing and firewalling. No NAT, privately addressed transit links between edge router and internal router
-Second firewall pair remains mostly the same config as it stands today, handles routing for public and private network blocks, NAT, VPN termination, etc.
-Almost 'transparent' firewall/routing at the edge with privately addressed transit links.
-Traffic can be blocked without opening the edge firewalls to attack.
-Less chance of spoofing.
-Public and private networks still exist on one device.
-NAT/VPN termination exists on same router as unNATTED public devices (web servers, etc).
Edge Router and Firewall + Internal Router/Firewall
-First firewall pair would handle all routing between edge routers and Internal firewall pair. This would also handle all routing for public networks, and serve as transit to the Internal Firewall Pair. This would create an insulated DMZ network.
-Second firewall pair would only be used for firewalling and routing, NAT, and VPN termination to internal networks and servers. It would have several public IP addresses in different VLANs for these services to run on. The gateway for those public interfaces is the Edge router.
-Public and private networks completely separate. NAT/VPN terminated to devices that ONLY have other NAT rules set up. No public services exposed.
-Takes some routing burden and spreads it out over two pairs.
-More complicated to deploy/migrate to
-No insulated firewall pair like in Option A.
Whatever you come up with. :)
Note: There's no double NAT here, so don't worry. Internet providers are two tier 1 providers with BGP running. The Edge Router/Firewall has a default route to the next hop with no dynamic routing protocols or NAT needed.
To be honest the best option is THREE pairs, combining both Option A and B above, but I don't have the resources yet to pull that off, and I really would like to keep this as uncomplicated as possible.
A Former User last edited by
My head hurts from reading that :P
For production systems this is the recommended setup:
2 managed switches at the perimeter WITHOUT an IP on any publicly accessible interface. No, just stop. NO IP on publicly accessible interfaces.
–-> 1 managed switch at the perimeter. All primary WAN links come into this. If the aggregated bandwidth is more than a single interface's bandwidth, LACP links to pfsenses. Minimum 1 interface per WAN connection + 1 interface per CARP member (more if LACP) + 2 interfaces for inter-switch trunking.
---> 1 managed switch at the perimeter. All secondary (backup) links come into this. See notes above
2 pfsense systems behind the above mentioned switches
---> 1 master CARP member. Minimum 6 physical interfaces, more if LACP.
---> 1 slave CARP member. Minimum 6 physical interfaces, more if LACP.
2 managed switches behind the CARP cluster.
--->1 primary (or "half primary if aggregating links on servers across switches). Minimum 1 interface per CARP member + 1 interface per server + 2 interfaces for inter-switch trunking.
--->1 secondary (or "half primary if aggregating links on server across switches). See notes above.
In full you need 4 managed switches and 2 computers. Simplifying it you need 2 managed switches and 1 computer. Simplifying even further (and ending up in the typical home scenario) it's 1 switch for LAN ( since pfsense is directly connected to the DSL/cable modem) and 1 computer.
Don't forget to run (simple) firewalls on the servers behind the cluster. Same net attacks and small stuff like that. They why not a second pair of pfsenses? Why analyze the entire network twice? If an internal server is under an attack from another internal server, let that "victim" server deal with it and push the banned host to the admins so they can deal with the other internal server that's doing the attack.
Just my $0.02.