Messages

Hi,

I am currently in the process of setting up an IPv6 range. My provider appointed a /56 range for me, native, but I cannot seem to get it running.

Right now, my network is IPv4 only. I have a /28 IPv4 range. It's setup like this:

xxx.xxx.xxx.1 => Main IP
xxx.xxx.xxx.2 => Mail IP
xxx.xxx.xxx.3 => Game IP

The internal net is:

192.168.1.0/24 => LAN
192.168.2.0/24 => OPT1

The firewall consists of three interfaces, WAN, LAN and OPT1. The three aforementioned public IP's are appointed to the WAN interface, through port forwarding traffic is allowed from, for example, WAN => OPT1. Using reverse NAT, the game PC has the .3 IP as it's outgoing IP.

Now, I wanted to do the same with IPv6. However, this territory is completely unknown to me. I tried it like this:

XXXX:XXXX:XXXX:XXXX:0:0:0:1 => Main IP
XXXX:XXXX:XXXX:XXXX:0:0:0:2 => Mail IP
XXXX:XXXX:XXXX:XXXX:0:0:0:3 => Game IP

And the internal IPv6 range:

fdf1:44a3:70cb:10c6::/64 => LAN

Thing is, however I tried, I can't get this to work. Is this the correct way to set it up, will the picture I've painted even work?

An update for my situation:

It seems like the caps error in the Suricata log, was due to a change in the interface assignments. There is one onboard ethernet controller and one through PCI express. I just changed the WAN interface from the onboard controller to the PCI express one, and poof, no more caps errors.

DNS seems to be resolving now, with IPS mode on. However, it does take a while. I am doing further investigation today, as to where that may come from.

[EDIT:]

Could it be a reason for you too that the change you makes don't resist for a reboot Anon87?

Dear Vincent,

Thank you kindly for your reply, really appreciate it. Theoretically speaking, it shouldn't make a difference, as my WAN is static, there is no DHCP server running upstream. However, I'll be glad to put this to the test nevertheless.

Unfortunately, I can't try this right now, as there is a transfer going on which cannot be interrupted. By estimation, the transfer should be done late tomorrow or early friday, then I am free to reboot as often as I wish ;-)

Also, I assume that you mean IPS mode? The difference is that IDS is detection, IPS is blocking :)

Cheers,
J.

EDIT: Vincent, since you've managed to get it working, if you look through the /var/log/suricata.log, is there something like this reported:

Code Select Expand

[ERRCODE: SC_ERR_SYSCALL(50)] - Unable to set caps for iface "em0": Invalid argument

We would try Suricata 3.2.2 to be sure it's either the binary or a newer ruleset...

Thanks Franco!

The same behaviour happens on v3.2.3 (the default) and v4.0.0, so from my viewpoint, the ruleset causing this issue is more logical than the binary. Does it help if I supply a list of the enabled rules?

I've used Google Translate to help me out with the German, but it doesn't really make any sense - it gets translated rather bad. I am able to follow and interpret spoken German, but reading it is something completely different, gheh.

Hi Franco,

Sure, I'll be glad to help out. I'll try to get into detail as much as possible, most will be completely worthless, but hope something can point you in the right direction.

I am able to reproduce this behaviour through the following steps:

• Perform a clean install of OPNsense - no configuration import whatsoever.
• After the reboot, open the web configurator and walk through the wizard. My system is directly connected through the internet, with a static, public IPv4 IP, part of a subnet. I configured this, with the /29 netmask . Didn't touch any of the other options. As a DNS provider, I use OpenDNS (208.67.220.220, 208.67.222.222).
• After the wizard, I've switched the flavour to LibreSSL and updated the corresponding packages.
• If I, right after that, disable the hardware acceleration (as mentioned in the 'IPS mode' helptext), enable all the rules (except for web-client, except for web-client, game, and inappropiate), download them and enable Suricata with the options from the first posted screenshot, reboot afterwards, it happens.
• If I disable Suricata or disable the IPS mode followed by a reboot, DNS resolves just fine.

My provider doesn't support IPv6 as of now, so that shouldn't be a problem. The only thing I haven't tried - yet - is to try another DNS provider. I am willing to downgrade to 17.1, to make 100% sure that this is 17.7 only behaviour. However, I might need a day or two to get that done, as I am away from home right now.

Cheers
J.

Hello Franco,

Thank you for your swift reply. If the Suricata rules did change and it led to some blocking, it should be listed on the alerts page, correct?

With the troubleshooting I did, one of the first things I thought about was the firewall ruleset. But it's pretty much the default, with all outgoing traffic allowed (IPv4) and the only incoming traffic is to the built in OpenVPN server, with I only enable if I leave home for more than one hour.

A few hours ago, I decided to completely reinstall the box, because theoretically, it could be a bug triggered by the configuration file, which I did import from 17.1.11. I began configuring it again, by hand. Walked through the setup wizard, selected the LibreSSL flavor, upgraded, configured the settings, enabled Suricata - worked all fine. Until I rebooted the machine, exact same problem as before.

I reinstalled it again, but now, I rebooted everytime I changed a single option. Countless reboots later, I think I've found the cause: with IPS mode enabled in Suricata, it causes the DNS queries/resolves to fail. After I disabled IPS mode, rebooted, Suricata ran fine, causing no problems.

Perhaps you can shine a light on this, as I am unfamiliar with the inner workings of Suricata. Is the IPS mode required to drop traffic, even if I set the default behaviour to drop in a specific rule or ruleset?

Last but not least, you mentioned that OPNsense 17.1 and 17.7 are based on the same FreeBSD version and run the same Suricata version. Could it be due to one of the mitigations/hardening techniques in HardenedBSD? As I read the releasenotes, there are some 'intense' changes made....

Thanks,
Anon87

Note to self: I should really, really get a KVM over IP solution for the headless systems at home

Hi!

First of all, thank you very much for your awesome work! It's been a wonderful ride so far.

I upgraded this morning to OPNsense 17.7, but ran across an issue. As soon as Suricata is enabled, the DNS seems to fail after a few minutes. Traffic is still possible, however, DNS queries fail. As soon as I disable Suricata, DNS queries succeed again. There are no rules set to block which might have an effect on this, the Suricata logs mentions doesn't report any block action whatsoever.

I tried it with the default supplied version, Suricata 3.2.3, upgraded to 4.0.0, but the problem remains. However, suricata.log (/var/log/suricata.log) does mention this everytime it's started:

Code Select Expand

[ERRCODE: SC_ERR_SYSCALL(50)] - Unable to set caps for iface "em0": Invalid argument