Messages

I don't know then with the limited info available for two firewalls and their setup.

Sorry for being unclear: Both instances were not running in HA mode or anyhow connected. One is the network's edge router the other one acts as a DevOps testing protection gateway. The only common thing they had: Same software version. But different behaviour.

Are you running them as a HA setup with CARP and pfsync enabled?

No, I don't.

Yes, I can ping the IP address.

Had the chance to run

Code Select Expand

configctl filter refresh_aliases
On the proxmox machine with no issues:

Code Select Expand

{"status": "ok"}
On the barematel machine with issues:

Code Select Expand


(yes, just an empty line)

Hi,

I am running out of ideas what to check with the following issue:

I have two instances of OPNSense, running on 25.1.7_4. One is within a proxmox VM and works fine. The other is my edge router (bare metal) and this is unable to handle new aliases.

What I did to exercise the problem:
1. Create new Alias "PC" (Host, 1 IPv4 LAN). Yes, clicked "Apply"!
2. Create a rule on LAN (Source "PC", Protocol enabled), pass. Yes, clicked "Apply"!
3. Trigger some traffic, nothing in the LiveView Log
4. Updated the rule using the verbatim IP address.
5. LiveView is showing a lot of traffic from the protocol rule.

Observations:
- In the alias section in firewall, the "last updated" column remains empty for "PC", load count is 0
- In the alias section in diagnostics, PC shows up as selectable item but shows no contents.
- Global configuration in /conf/config.xml contains the alias definition
- Checked /var/db/aliastables, no entry for "PC" - the filesystem has plenty of space left and permissions seem ok
- Checked backend log: Nothing of a warning or higher severity, nothing relevant (from my perspective) in less severe levels.
- Checked firewall log: No warning or higher, nothing about alias (had to search for the term "alias")
- Cloudflare, Spamhaus DROP and GeoIP seem to regenerate  as usual, timestamp of /var/db/aliastables matches log entries

The only "interesting" part about this machine is that I replaced the SSD 4 weeks ago, ran a full install and reloaded the last known config / backup. Updated to 24.1.7_4 in the process afterwards.

I know I can stick to hard coded IP addresses for now - and I will not reboot until the next weekend at least, so testing it is currently not possible. My second instance on Proxmox does not have this issue and updates everything as required.

EDIT: (See reply below for more) running configctl filter refresh_aliases returned no output other than an empty line.

Are there any other locations I might have a look for diagnostics or trigger an alias re-generation from the shell?

Thanks.

EDIT2/Resolution: flock was blocking forever on a lock existing for more than 21 days. I'd expect however the firewall to not silently do nothing in such a case.

You may want to provide more information.

Please show your exact rules and diagnsotics information.

From the lack of information you provided here I could guess that you're using public DNS to connect to your proxy which resolves to the WAN IP and results in 403 due to NAT on the client's side. When you use the local IP of nginx you're routed through the tunnel and due to missing NAT everything works.

But again, I might be wrong as you do neither describe IP ranges, possible DNS resolutions nor IP protocols involved.

Another solution is to use

Code Select Expand

ifconfig [-]rxcsum,[-]txcsum

etc.

check its manpage for more options. Or the source code of the web ui for its usage.

https://github.com/opnsense/core/blob/3cbc7927db174f51eec007739b4fcf4247a18948/src/etc/inc/interfaces.lib.inc#L548

First of all:
ntopng default credentials are admin and the password of root from opnsense.

Second:
redis sucks a lot in combination with ntopng. Restart redis. On my machine it crashes from time to time. Probably a memory issue. But due to no need for ntopng any more, I removed both.

There's no need to flush the state table of the firewall as the firewall remains unaffected by unbound's black listing.

What unbound does is to return NXdomain (if selected) or 0.0.0.0 (default, if not another ip is entered). In both cases, your client's local dns resolver will cache that result for the TTL (time to live). So, when you update the behaviour of unbound due to white or black lists you might want to restart unbound and flush the DNS cache on all affected clients. Or wait for the TTL to expire.

E.g. on windows you can do

Code Select Expand

ipconfig /flushdns if I remember correctly.

Interesting scenario.

However, if you want full IPv6 deployment you need to delegate IPv6 address spaces. Enabling IPv6 just for LAN just gives you IPv6 connectivity for the switch.

Hence:
- Get an /48 from HE if not already there
- Configure DHCPv6 on OPNsense to delegate a (let's say) /56 (taken by the switch)
- On the switch make sure it can deal with a delegated prefix
- Check that your OPNsense local networks (LAN, DMZ, WAN) do NOT have the same prefix as the delegated one.

Did you do any of that and if yes, with which outcome?

> Will add screenshots of nat, wan and portforward rules below since max 4 attachments

Would be really helpful.

In 24.7.2 I found ICMPv6 134 Destination Unreachable before the messages like these, my comments in ():
fe80::xxx (Android device)   -> 2a00:1450:4005:801::200a (google as)   ICMPv6   134   Destination Unreachable (no route to destination)

A neighbor advertisement for the device's gua is not shown until after that destination unreachable. I wonder if that was the issue.

Nevertheless, 24.7.3. works and I will now update the unifi ap's back to the most recent fw.

Hi,

some of the major glitches w.r.t. IPv6 seemed to have broken android connectivity via wifi. Seems to work with 24.7.3 again.

Was investigating since 24.7.2 because some androids in my network were dropping wifi every now and then. The wifi is provided by unifi UAPs (no gateway). Windows and Linux PCs had no issue. Androids via wired LAN were also fine. I suspect a possible issue with IPv6 that caused the androids to think that wifi has no internet connection and drop it. Unifi firmware downgrades would not have any beneficial effect and could be ruled out.

I also noticed some reporting by OPNsense that fe80:: wants to talk to 2a00::. I don't know if that's relevant to my issues or just an effect during Android's connection drops.

Nevertheless, androids are now online without frequent drops. 24.7.3 fixed it. Hope that helps others with the same issue.

Did you check the firewall logs if something got blocked and why?

Hi,

there's some information missing:
- What's the VLAN's config in OPNSense (Interfaces -> Other types -> VLAN)?
- What's the DNS setting published by your DHCP server? You allow DNS for IoT address - but I found a lot of installations where the LAN IP is used instead. Hene, I allow "This firewall" instead of "<interface> address"


You could also do some debugging:
Using firewall's live view you could check for DHCP packets going in or out that were blocked and check for firewall misconfiguration
Using packet capturing you could identify if there's even some traffic coming in for DHCP.

That way you could isolate the issue to your switch  (no traffic) or OPNsense (traffic blocked)