2 Pfsense with snort in bridged mode CARP setup

hkjarral

Hello all,

I am trying to look on some pointers if someone has already done similar setup. This is what I have

2 pfsense with 5 Interfaces each
1 Interface on each dedicated for LAN GUI/SSH access
Other 4 interfaces on each is 2 bridged each

I do have identical configs/packages on both pfsense boxes.

I want the configs/snort rules/firewall state/DHCP to be synced since both boxes will be in active active state.

Whats is the best path to go forward, leave them without CARP or setup CARP ?
If I keep both without CARP only issue is DHCP which will be 2 DHCP servers in setup.

Also will CARP also sync the whitelist black list IPs for snort ?

If I go forward with CARP what caveats should I keep in mind.

bmeeks

@hkjarral said in 2 Pfsense with snort in bridged mode CARP setup:

Hello all,

I am trying to look on some pointers if someone has already done similar setup. This is what I have

2 pfsense with 5 Interfaces each
1 Interface on each dedicated for LAN GUI/SSH access
Other 4 interfaces on each is 2 bridged each

I do have identical configs/packages on both pfsense boxes.

I want the configs/snort rules/firewall state/DHCP to be synced since both boxes will be in active active state.

Whats is the best path to go forward, leave them without CARP or setup CARP ?
If I keep both without CARP only issue is DHCP which will be 2 DHCP servers in setup.

Also will CARP also sync the whitelist black list IPs for snort ?

If I go forward with CARP what caveats should I keep in mind.

I can't answer your other questions, since CARP is not my area of expertise in pfSense. I can, however, tell you that the Snort package itself will sync any Snort IP lists. Those are independent files stored in /var/db/snort/iprep. The SYNC tab in Snort can be configured to sync the configuration between one or more firewalls including copies of those IP lists. One requirement for Snort package Sync to work correctly is that all of the firewalls must have identical interface setups. This means the same NIC hardware (so the physical interface names match) and with the physical NIC ports used the same way (i.e., if Port 1 is the LAN on firewall 1 it must also be the LAN on firewall 2, etc.).

hkjarral

Thanks bmeeks, Yep I noticed that snort has its own sync settings. I can let these two boxes sync with that too but only issue in event of actual firewall failure who would take care of DHCP or I guess I can just live with it till the box with DHCP comes back up.

Also about snort sync, how do you set it up A>B or A<>B, Under IP settings which IP you put if you want both boxes to sync to each other.

bmeeks

@hkjarral said in 2 Pfsense with snort in bridged mode CARP setup:

Thanks bmeeks, Yep I noticed that snort has its own sync settings. I can let these two boxes sync with that too but only issue in event of actual firewall failure who would take care of DHCP or I guess I can just live with it till the box with DHCP comes back up.

Also about snort sync, how do you set it up A>B or A<>B, Under IP settings which IP you put if you want both boxes to sync to each other.

You have only a "master" and "slave" or "slaves" setup. So the box you configure the SYNC tab on is the defacto "master", and it will send its Snort configuration to all slaves listed on the SYNC tab by their IP. You don't want to configure the SYNC tab on a "slave" and try to have that slave send its configuration back to the "master". That is an undefined type of scenario and will probably lead to a bad outcome.

The sync feature within Snort (and Suricata also, if installed) is designed as a one-way path from a designated master to one or more slaves.

And only the basic Snort configuration is synchronzied. Realtime data such as alerts and blocks are not synchronized.

hkjarral

In that case, I dont think I can deploy it in active active scenario. I will see how can I make it work with CARP

bmeeks

Yeah, the SYNC replication feature in Snort and Suricata is really designed to help admins who need to push the same IDS/IPS configuration to a number of identical boxes such as remote firewalls in branch offices, for example. It was not designed to replicate the parameters needed for an active-active cluster.