Network cut off when doing backup
-
Today pfsense is driving me nuts >:( >:( >:(
I have a Siemens server with Intel quad-NIC which runs here without any problems for months.
Today I tried to put some Snoms to the fourth NIC channel (with a switch in between) and configured a DMZ (172.23.2.x) for them.
While I was trying to save the pfsense-config with the GUI-backup, the LAN on the first NIC-chanel (172.23.1.x) cuts itself down, so the GUI is not reachable via the first NIC-channel any more.
It is still possible to login locally to the server, and still possible to reach the 3 other NIC-channels (with different subnets), beside the 172.23.1.0-subnet. Also the WAN-interface is reachable.
What is strange also: if I just backup the config without the RDP-data, everything is fine, the backup completes and the 172.23.1.x-subnet stays on. To bring back the 172.23.1.x-subnet, I rebooted the server, it stays on till I do a full backup (including logs) again.
Any hints?
-
forgot to mention: there is no suspicious entry for the NIC-cutoff in /var/log/system.log or …ntpd.log
-
As I did not get any response here, I restored a backup-conf and everything is fine again.
-
Fu…
Some hours later, same problem again, now with another NIC-port.
Could it be that the NIC has quit service?
If so: should'nt I find any errors in the logs?
Please give me some hints.
-
I've never heard anything like that before. Absolutely nothing in the System log at the time of the incident? Doing a backup of your RRD data is disk-intensive so I would look at that first. Saving your config has nothing at all to do with your NICs other than using your LAN NIC to send you the file.
Today I tried to put some Snoms to the fourth NIC channel
What's a Snom? What's your hardware config in general? 'Siemens server' doesn't tell us much. What version of pfSense? Do you have any IDS packages like Snort or Suricata installed?
-
I just read that the Intel 1000 VT NIC (I have a Dell-OEM-Version of that card) tends to make troubles on pfsense. Could that be the reason?
On the other hand I do not understand that the NIC did work perfectly for months.
-
@KOM:
I've never heard anything like that before. Absolutely nothing in the System log at the time of the incident? Doing a backup of your RRD data is disk-intensive so I would look at that first. Saving your config has nothing at all to do with your NICs other than using your LAN NIC to send you the file.
That's what I have thought also. RRD-data is about 4 MB, so not that much.
@KOM:
What's a Snom?
VoiP-Phone of a Berlin company.
@KOM:
What's your hardware config in general? 'Siemens server' doesn't tell us much.
Fujitsu MX130 S2 Micro Server // 8-Core AMD Opteron 3280, 8 GB ECC RAM
@KOM:
What version of pfSense? Do you have any IDS packages like Snort or Suricata installed?
latest version of pfsense, Suricata installed on all NIC-ports.
-
My experiences here over the past few years have taught me that if anything bizarre is going on, temporarily disable any IDS you have. It might be tripping a false positive about something and blocking traffic on the NIC or something else just as bizarre. Disable Suricata and try again. You could also try doing a packet capture on the NIC that is down and see whats going on there.
-
Thanks for that hint with suricata.
I disabled it on the correspinding NIC and now the line "survices" even a full backup, so it seems to be a got first step.
Oddly there had been no prio 1 entries (which block traffic) during the time when the cutoff has happened.
What I did find were some prio 1 entries some hours before the cutoff:
- ET INFO Session Traversal Utilities for NAT (STUN Binding Request)
- ET TOR Known Tor Relay/Router (Not Exit) Node Traffic group 516
- ET TOR Known Tor Relay/Router (Not Exit) Node Traffic group 438
-
I can't really help you further with that as I tend to avoid IDS for the exact reason you're seeing – weird behaviour due to false positives. The IDS/IPS forum may be a better place to get some guidance on what to do next.
-
Ok, thanks, KOM, for leading me to the right direction. ;)
Could a mod please move the thread?
-
I found the solution now: it had been a problem with "inline mode" in suricata.
I changed it back to legacy mode and now everything is as it should be: it blocks under certain conditions, makes a log entry and cuts the connection to the offender (not the whole network).
