Bug #6769
closed
Crash PacketFilter in bridge mode
100%
Description
Hi,
I have configured pfsense in bridge mode on the Vmware Vsphere. The VM of Pfsense have 8Go of memory and one socket with 8 cores.
For reproduce this bug, just install a fresh version of pfsense 2.3.2 and configure WAN and bridge with LAN.
set:
net.link.bridge.pfil_member 0
net.link.bridge.pfil_bridge 1
Now, create a VM on the LAN and attribute IP (137.74.245.50).
Install on the VM LAN web service of your choice (Nginx, Apache, etc).
Create a firewall rule on the bridge interface, Allow all source to VMWEB and HTTP port only.
So far, no problems.
BUT now, open this rule and configure advanced paraméter with that :
Max. connections 40
Max. src. conn. Rate 60
Max. src. conn. Rates 4
State timeout 3
State type Synproxy
Well, now apply this rule and create traffic on web service.
Wait, after randomly minutes, Packfilter crash and all connectivity are broken even pfsense gui.
The solution for unblock this situation:
open shell and disable packetfilter : pfctl -d
and delete advanced configuration of rule create before.
Updated by Jim Pingle over 8 years ago
- Category changed from Gateways to Rules / NAT
- Status changed from New to Feedback
- Priority changed from Urgent to Normal
- Target version deleted (
2.3.2-p1)
Does it require that specific combination of settings? Or does it still crash with only one of them active? or two? or three?
We need some more solid information.
I could see synproxy failing on a bridge on its own because of how it operates. You can't proxy on a bridge because the traffic isn't destined for the firewall. Local client sends the packets straight to its gateway, which is upstream and not pfSense, and same in the other direction: gateway sends straight to the client. A proxy style handoff such as that requires both sides address traffic to the firewall (e.g. routed, NAT, etc, but not bridged). I'd remove that option first.
If synproxy is to blame we may have to work out some input validation to reject it on a bridge member interface since it's not likely to be fixable in that use case.
Updated by Johann MONNIER over 8 years ago
Synproxy is not the setting that problem because I left it on and I do not have the problem.
and for information synproxy bridge works even after testing to make synflood spoof. If disabled, the spoofer synflood reached the target, if it is activated, it does not reach the target.
The problem can be found in the following settings:
Max. 40 connections
Max. src. Conn. Rate 60
Max. src. Conn. 4 Rates
State timeout 3
I think it is statetimeout problematic.
Also, I had the same problem on a rule that worked great with the above advanced settings but with only statetimeout 6 and when I passed the firewall to "aggressive" and Packet filter is down. I had to remove the advanced settings of the rules and restart pfsense.
Updated by Jim Pingle over 8 years ago
Can you isolate it to just one of those options then? Or does it require them all? Can you disable/enable them to see if they each crash on their own or if it takes a specific set?
Updated by Johann MONNIER over 8 years ago
i think the problem is with all parameter set and the scenario most probability than is if number connexion over the setting set in advanced (with the parameter statetimeout 3) than packet filter crash.
I don't have possibility to try because my system is in production.
i purpose you try with this setting for reproduce fastly the problème:
Max. 10 connections
Max. src. Conn. Rate 10
Max. src. Conn. Rates 30
State timeout 3
if you want, i have possibility to set up the same système on a other server for you and test
Updated by Johann MONNIER over 8 years ago
I confirm than crash if you set advanced parameter but randomly... for unknow reason. I have reboot five time pfsense and crash again but i delete advanced rules solve the problem.
And strange, now if i set synproxy dont connection is possible to reach webserver. Or this parameter are set pending uptime nine day and opérationnal with the synflood in bridge mode.
I Think look seriously at the problem in bridge mode. I guess no one uses this method because it seems strange to me at this stage of the pfsense version to meet an unstable behavior...
Updated by Johann MONNIER over 8 years ago
Ok, without advanced settings set in the rules on the firewall not more crash. Now it's stable.
Updated by
Updated by Jim Pingle about 8 years ago
- Status changed from Feedback to Resolved
- Assignee deleted (
Jim Pingle)
I can reproduce this somewhat here on 2.3.2. With a WAN/LAN style bridge, putting synproxy on a TCP rule will eventually kill traffic to the firewall. The other advanced parameters appeared to be fine without synproxy, the client ended up in the virusprot table as expected when violating the limits. Clear them out of the table and they're fine.
It's fairly easy to reproduce: Setup a WAN/LAN bridge, (WAN=bridge0, other interfaces are bridge members with no IP address), IP address on the bridge, filtering on the bridge only. Add a TCP rule to pass with synproxy, put a client on WAN and a client on LAN, run iperf from the WAN client to LAN server, after a couple iterations the GUI will not be reachable until pf is disabled and the synproxy rule is removed or disabled.
That said, as I mentioned before, using synproxy on a bridge is likely to be a problem in general. A bridge cannot proxy properly as the host with the bridge is not the true destination for the traffic. Though since it works partially and then fails, there may be some other factor at play.
And above all of that, I cannot reproduce it at all on 2.4. The exact same configuration that has a problem on 2.3.2 works fine on 2.4, I never lose contact with anything. So I'm closing this out.
Updated by Jim Pingle about 8 years ago
- Target version set to 2.4.0
- % Done changed from 0 to 100
- Affected Version set to 2.3.2