Suricata doesn't start automatically at boot

bmeeks

No, your access point should be out of the picture.

The only time, in the past, I've seen problems such as yours in $HOME_NET is when a defined interface is not properly configured on the pfSense side. By that I mean it does not have an IP address assignment.

I really need to see the entire error message. Your screenshot is cutting off the far right part of the message due to the horizontal scrollbar.

The default behavior for constructing the $HOME_NET value is to include all locally-attached networks, the WAN public IP, any configured DNS servers, any VPNs and VIPs, and the default gateway. So look at the list of IP subnets and IP addresses shown in the error message and figure out what appears to be missing. In other words, what network address from the list I gave above is missing in the $HOME_NET message? That's likely the one causing the "Array" entry that Suricata is balking at.

Koff

Thanks @bmeeks. The router was what slowing it down. I unplugged it, rebooted and suricata was up.

Koff

Sorry, but the issue came back after I updated pfSense.

suricata.log after failure to start at boot

28/8/2021 -- 16:16:13 - <Notice> -- This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
28/8/2021 -- 16:16:13 - <Info> -- CPUs/cores online: 4
28/8/2021 -- 16:16:13 - <Info> -- HTTP memcap: 67108864
28/8/2021 -- 16:16:13 - <Error> -- [ERRCODE: SC_ERR_ADDRESS_ENGINE_GENERIC(89)] - failed to parse address "Array"
28/8/2021 -- 16:16:13 - <Error> -- [ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - failed to parse address var "HOME_NET" with value "[10.10.0.0/24, 10.10.10.1/32, 10.10.20.0/24, 10.10.30.0/24, 127.0.0.1/32, 192.168.1.14/32, 192.168.1.254/32, 193.19.108.2/32, 194.242.2.2/32, ::1/128, Array, fe80::a236:9fff:fe18:6f7c/128, fe80::a236:9fff:fe18:6f7d/128, fe80::a236:9fff:fe18:6f7e/128, fe80::a236:9fff:fe18:6f7f/128]". Please check its syntax
28/8/2021 -- 16:16:13 - <Error> -- [ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - basic address vars test failed. Please check /usr/local/etc/suricata/suricata_10842_igb0/suricata.yaml for errors

HOME_NET after manual start

HOME_NET: "[10.10.0.0/24, 10.10.10.1/32, 10.10.20.0/24, 10.10.30.0/24, 127.0.0.1/32, 192.168.1.14/32, 192.168.1.254/32, 193.19.108.2/32, 194.242.2.2/32, ::1/128, fe80::a236:9fff:fe18:6f7c/128, fe80::a236:9fff:fe18:6f7d/128, fe80::a236:9fff:fe18:6f7e/128, fe80::a236:9fff:fe18:6f7f/128]"

pfSense 2.5.2 or 2.6.0-dev.
So, I gave WAN a static address (I am behind the router of an ISP).
I removed other interfaces and unplugged anything on them until only left with WAN and LAN.
I removed other packages.
I tried Legacy Mode or Inline Mode.
Same result : whichever interface doesn't come up fast enough according to @bmeek.
I have a smaller form factor box and it does it on both. maybe it's the ISP's router.

bmeeks

After it fails to start at boot, do not manually start it. Instead go here and examine the suricata.yaml file to read the actual runtime value for HOME_NET from the file.

The file will be in a subdirectory for each interface under /usr/local/etc/suricata/. Use the DIAGNOSTICS > EDIT FILE menu option in pfSense to browse the directory previously listed. In it you will see one or more subdirectories (one for each configured Suricata interface). The subdirectorties will have the physical NIC device name and a random UUID in their name. Inside each subdirectory you will find the suricata.yaml file for that interface.

Open that file in the GUI editor and scroll until you see the HOME_NET definition line. Examine that line and compare all the IP addresses and subnets listed to what is defined on your firewall. See which defined IP is missing in HOME_NET and is instead showing as "Array". That's going to be the guilty party interface.

Koff

@bmeeks This is exactly what I did. as you can see there's any differrences.

I started from scratch again but I didn't import the aliases (the only thing I imported each time, there's too many of them).

bmeeks

@koff said in Suricata doesn't start automatically at boot:

@bmeeks This is exactly what I did. as you can see there's any differrences.

I started from scratch again but I didn't import the aliases (the only thing I imported each time, there's too many of them).

Do you have Wireguard or OpenVPN in use? Another possible suspect would be a VPN interface that comes up late in the boot process (after Suricata has already started, for example). Trying to correlate your symptoms with those of a Snort user with a similar problem. Wireguard and/or OpenVPN might be a common denominator.

Koff

@bmeeks As I said, even with a clean install with only the aliases imported, suricata had this behavior.
Right now, I didn't import the aliases and it works normally for the last 3 days.

bmeeks

@koff said in Suricata doesn't start automatically at boot:

@bmeeks As I said, even with a clean install with only the aliases imported, suricata had this behavior.
Right now, I didn't import the aliases and it works normally for the last 3 days.

So that narrows your problem down to one or more of the aliases not populating correctly. Although it should warn you when choosing aliases in Suricata, be aware that it does not support FQDN aliases. Snort does on a limited basis, but not Suricata.

Are you using a nested alias in a custom HOME_NET declaration, or are you using the default HOME_NET value? I assumed you were using the default, so with the default HOME_NET configuration an alias should not matter as none are defined in HOME_NET by default.

Koff

@bmeeks I 'm using the default HOME_NET value.

bmeeks

@koff said in Suricata doesn't start automatically at boot:

@bmeeks I 'm using the default HOME_NET value.

Now I am very confused. If you are using the default settings for HOME_NET and EXTERNAL_NET, then there is no way importing or not importing an alias would matter one bit.

Do you maybe mean you originally had a custom HOME_NET definition using an alias, and now, with the aliases not imported, you have reverted to the default HOME_NET?

I'm not understanding your setup here, and thus your problem does not seem logical.

Koff

@bmeeks The aliases are for firewall rules. I didn't add them to the HOME_NET value

bmeeks

@koff said in Suricata doesn't start automatically at boot:

@bmeeks The aliases are for firewall rules. I didn't add them to the HOME_NET value

Then there is no way they are related to your problem with having "Array" defined in HOME_NET. We are back to the original suspect -- an interface (likely a VPN) is not up and configured at the time the IDS/IPS starts and constructs the automatic default values.

Perhaps the alias would impact the VPN startup, and that in turn might influence how HOME_NET gets constructed. But there is not a direct relationship between firewall rule aliases and HOME_NET and EXTERNAL_NET in the IDS/IPS packages.

Koff

@bmeeks You are probably right, wireguard is the last package to start... So I will import the aliases and see what happens.