Just upgraded to the latest snapshot to try and get rid of this…
-
Sep 22 17:41:02 php: : There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]:
Sep 22 17:41:02 php: : New alert found: There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]:Any ideas why this is happening?
Hardware:
Supermicro P4 3.0GHz CPU
2.5Gb RAM
80Gb SATA diskPackages loaded:
bandwidthd
darkstat
pfBlocker
LCDproc-dev
mtr-nox11
nmap
OpenVPN Client Export Utility
Strikeback
Snort - removed prior to snapshot update due to other errorsI've had some ugly problems lately as follows:
Upgraded Hardware (now backed out) to another Supermicro with Core2Duo CPU, extra dual Intel Pro1000 nic (for a total of 4 Intel Pro1000 ports -2 onboard & 2 in new nic), 4Gb RAM. When I restored my old config.xml (with a few edits due to the new ports jumbling up the em0-em3 ordering), DHCPd refused to issue fixed addresses on ipv6 space. It also refused to give out addresses from the defined pool and instead gave out 2001:xxx:xxxx:xxxx:0:0:0:1000-2000 addresses. It failed to write my preferred range into the dhcpdv6 conf file as well. The extra interfaces gave more problems than they were worth, so I turned the box off, moved the nic card to the old box and reloaded. After editing the config.xml backup file to use the correct interfaces, I imported it in a restore operation. Everything came back up and worked properly.
After allowing it to run "stable" for a few days, I decided to try and use one of the additional nic ports to create a DMZ. It locked the entire machine up on reboot at "configuring DMZ interface". Locked keyboard, locked everything. I rebooted in single user mode and edited the <enable>tag out of that interface config. When I rebooted it all came up ok and I removed the entire interface config via the UI, due to being tired of messing with it for the weekend.
Then I began running into problems with Snort reloads, where the services panel would show that snort was loaded and running, but the memory stats weren't matching my expectations (8% usage rather than the usual 79% usage showing via the dashboard). The services panel showed snort as running but the system logs showed it having a failure during parsing on some of the categories. I removed snort and will save that drama for another day.
But I am concerned about the error in the first two lines of this post. Because I've been getting that one off and on during various releases of the beta codebase. With all the other troubleshooting, I guessed that I might have bigger "fish to fry" with the extra nic installed. But now I'm getting down to crunch time and need to get this fixed before I leave town on my next business trip.
If anyone has info on this, or if anyone has a suggested path for resolving the errors, I would be appreciative. Let me know what you want me to provide first in terms of logging, testing, etc. OR let me know what I should try doing first. I'm guessing that losing all the extra packages would be a first step towards resolution.
Thoughts?
Thanks!
David/Treffin</enable> -
Update:
I just opened up the box and removed the jumper for enabling the second on-board interface so now the remaining on-board Pro1000 interface comes up as em0 (as usual) and the cards interfaces are now em1/em2 –same as before, but without the other on-board interface showing up (em3). I thought I might try this and see if there was some sort of conflict between the card and the onboard interfaces.So now I seem to be able to get em0 configured as LAN, em1 configured as WAN (spoofing the mac from the on-board LAN2 interface --the only way to keep my dhcp issued address from my provider from changing), and it actually seems to have allowed me to configure OPT2/em2 as a DMZ interface without killing everything else. OPT1 is a tunnel from HE.net, attached to the Gif interface.
I have configured a firewall rule from the em2 subnet 10.0.7.0 (any) to ANY which should allow (for now) communication from the DMZ to the LAN and out the door as well. I don't have anything on the DMZ yet so don't need anything blocked until I am ready to use it.
Question: Do I need to configure anything special in terms of explicit 10.0.7.0/DMZ network to the other nets or to the WAN for wide open access? Or did my rule above accomplish this? I modeled the rule after the same specs as my default LAN to any allow rule and the same on my IPSEC interface allowing any from there to any.
DHCP is configured to hand out addresses from the 10.0.7.1 interface and provide that interface as the gateway for those devices. Before when I tried this, I plugged in a laptop to that interface and the errors that I got back indicated that it was attempting to get a DHCP address from the WAN DHCP provider at my ISP. And yes the DHCP service WAS configured to hand out 10.0.7.x addresses to clients on that interface. But for whatever reason it wasn't doing it's job.
Thanks,
David/Treffin -
DHCP is configured to hand out addresses from the 10.0.7.1 interface and provide that interface as the gateway for those devices. Before when I tried this, I plugged in a laptop to that interface and the errors that I got back indicated that it was attempting to get a DHCP address from the WAN DHCP provider at my ISP.
What was your evidence for "it was attempting to get a DHCP address from the WAN DHCP provider at my ISP."? Do you have pfSense DHCP Relay enabled? (I can't think how else a DHCP request on your DMZ interface would get to the ISP unless you have bridged the DMZ and WAN.)
Does the request appear in the pfSense DHCP log? What response was recorded in the DHCP log?
-
It did actually show up on the laptop logs as trying to reach the external (ISP) gateway and DHCP server. My ISP (TimeWarner) for whatever reason uses a DHCP server that is on the 10.x.x.x network even though my network address is public, as is the gateway. I have to turn off the "block private IP" rule on the WAN else I'll never end up getting the address. The cable modem gives a temporary 192.168.100.x address for a very short time when the cablemodem boots up. Once it has it's config, it reverts to bridge mode and the 192.168.100.1 gateway is no longer reachable. However, these guys still use a 10.x.x.x addressed DHCP server to hand out my 76.x.x.x address. I little weird on their side for sure.
But anyway, I saw in the laptop's log that it was trying to contact the 10.x.x.x server address that is on the WAN/ISP side. I did not in fact have DHCP relay enabled and actually never have used that option here at the house. That's why I thought it was quite strange that anything on the DMZ net would be contacting the outside DHCP server.
David
-
But anyway, I saw in the laptop's log that it was trying to contact the 10.x.x.x server address that is on the WAN/ISP side. I did not in fact have DHCP relay enabled and actually never have used that option here at the house. That's why I thought it was quite strange that anything on the DMZ net would be contacting the outside DHCP server.
Perhaps the laptop got its IP address previously from a 10.x.x.x server and you observed it trying to get a lease from the previously used server rather than it trying to get an entirely new lease from "any" server.
-
I will try to find the log files for the laptop also from pfSense for that timeframe, but it will be the end of the week before I get back to the home lab. I can assure you that the laptop has never had a network connection that would allow it to be on the public leg of the network. It's the only Windows box that I allow at the house…a Dell netbook that my niece returned to me when I gave her a Macbook Pro last Christmas. Everything else here is either Linux/CentOS, FreeBSD, MacOS, SGI or Sun.
Thanks!
David