Network cut off when doing backup
-
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).
