Hey there,
I thought I'd post this in networking as I believe the root problems are networking related. I am running two FreeBSD 8.0-RELEASE boxes with PF + BRIDGING.
They are both connected to a RST-enabled switch. Currently if both of them are on, one of them completely locks up with no messages on the console whatsoever.
These devices provide firewall services only, but due to the nature of the network (every device behind it posessing only public IPs), a transparent bridging firewall seemed like the best choice.
Unfortunately I cannot have hardware redundancy with seamless failover. Currently one of the two firewalls is off, and will be remotely powered on in the event of a failover. This is completeley unacceptable to me, and I would like insight as to why when both are on, one of them completely locks up.
Here is my relevant configuration files :
RC.CONF
Note that I have tried to add stp options to the ifconfig line for testing, as well as polling, such as the following :
The exact same problem persists even with the above options.
My pf rules themselves are fairly straightforward, with nothing funky or weird. Just a bunch of tables, rdr's, and pass in's with a block in all and pass out all rule. If you want I can post it, but honestly I think its an issue with two FreeBSD bridging servers.
I am at a loss, this issue has existed over the last several years and I have tried upgrading FreeBSD a few times over the last 2 years, but I am unable to even pinpoint to an open or known issue or bug.
Any help whatsoever is greatly (GREATLY) appreciated!
Thanks,
Kevin
I thought I'd post this in networking as I believe the root problems are networking related. I am running two FreeBSD 8.0-RELEASE boxes with PF + BRIDGING.
They are both connected to a RST-enabled switch. Currently if both of them are on, one of them completely locks up with no messages on the console whatsoever.
These devices provide firewall services only, but due to the nature of the network (every device behind it posessing only public IPs), a transparent bridging firewall seemed like the best choice.
Unfortunately I cannot have hardware redundancy with seamless failover. Currently one of the two firewalls is off, and will be remotely powered on in the event of a failover. This is completeley unacceptable to me, and I would like insight as to why when both are on, one of them completely locks up.
Here is my relevant configuration files :
RC.CONF
Code:
hostname="fw1"
sshd_enable="YES"
defaultrouter="x.x.x.x"
gateway_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm bge0 addm bge1 up"
ifconfig_bge0="up"
ifconfig_bge1="up"
priority 10 up"
ifconfig_em0="inet 10.0.0.10 netmask 255.255.255.0"
ifconfig_em0_alias0="inet y.y.y.y netmask 255.255.255.192"
# PF Options
pf_enable="YES" # Enable PF (load module if required)
pf_rules="/etc/pf.conf" # rules definition file for pf
pf_flags="" # additional flags for pfctl startup
pflog_enable="YES" # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags="" # additional flags for pflogd startup
pfsync_enable="YES"
pfsync_syncdev="em0"
# PFSync Interface
ifconfig_pfsync0="up syncpeer 10.0.0.11 syncif em0"Note that I have tried to add stp options to the ifconfig line for testing, as well as polling, such as the following :
Code:
#ifconfig_bridge0="addm bge0 stp bge0 addm bge1 stp bge1 up"
#ifconfig_bridge0="addm bge0 stp bge0 addm bge1 stp bge1 hellotime 2 maxage 5 fwddelay 6
#ifconfig_bge0="polling up"
#ifconfig_bge1="polling up"The exact same problem persists even with the above options.
My pf rules themselves are fairly straightforward, with nothing funky or weird. Just a bunch of tables, rdr's, and pass in's with a block in all and pass out all rule. If you want I can post it, but honestly I think its an issue with two FreeBSD bridging servers.
I am at a loss, this issue has existed over the last several years and I have tried upgrading FreeBSD a few times over the last 2 years, but I am unable to even pinpoint to an open or known issue or bug.
Any help whatsoever is greatly (GREATLY) appreciated!
Thanks,
Kevin
