Messages

Spamhaus ZEN blacklist

It's in ZEN because it's listed in their PBL. Unless the node at this address is attempting to deliver e-mail's directly, it isn't a problem.

EDIT: If I go to firewall > Diagnostics > aliases and select the qfeeds malware alias in the dropdown, and search for the IP, it does not appear to be in the list. Why is it being blocked? What can I do to work out why this is suddenly being blocked. If I disable the qfeeds rule, all is well.

The IP in question is 43.131.7.8

It is in there and caught by a CIDR entry - search for 43.131.0.0.

After updating from 26.1.11_10 to 26.7.1_1, the Events are now shown.

There was also some additional piece of software for Unbound that can cache frequently requested stuff for you for longer periods based on your personal preferences, but I can't remember the exact name...

The man page for unbound.conf(5) lists this option, is it what you are thinking of?

Code Select Expand

cache-min-ttl: <seconds>
            Time to live minimum for RRsets and messages in the cache.  If the
            minimum kicks in, the data is cached for longer than the domain
            owner intended, and thus less queries are made to look up the
            data.  Zero makes sure the data in the cache is as the domain
            owner intended, higher values, especially more than an hour or so,
            can lead to trouble as the data in the cache does not match up
            with the actual data any more.

            Default: 0 (disabled)

The setting in Services -> Unbound DNS -> Advanced is;

[Reject]

The Reject action plays a critical role here.  These rules are throttling all of the DNS queries from the Roku group, not just the undesirable ones.  I need them to fail fast with feedback so that the streamer doesn't hang and has the best chance of retrying quickly when one of the necessary queries gets dropped.

I see now, thanks

[Action]

block return in quick inet proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
block return in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}

If you were to change the Action in these rules to Block, by how much would the rate of queries drop?

Code Select Expand

block drop in quick inet proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
block drop in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}

[Loopback]

Why not?

Refer to the fine manual - https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces.

If you don't want to bind to all interfaces a tip is provided in this section where you set an address on a Loopback interface. The next step will be to include the newly created interface to the Listen Interfaces bindings.

After applying the settings, open a connection using the address you assigned to the Loopback interface. When you've signed in remove the LAN interface bindings.

Note, the anti-lockout rule rule will apply just as it did before.

If the single Interface the webGUI is bound to goes DOWN and then UP again it can become unreachable

FWIW, I performed some tests where the DHCP server was unavailable. Rebooting OPNsense from the WebGUI, dhclient eventually assigned an address to the interface using the one it obtained earlier, as it was within its lease time. When the address was applied the OPNsense login banner appeared - just stating an observation.

My configuration has it explicitly set to LAN.

But still, it should also work with a DHCP address on that interface

I've set up a test system to trial the upgrade from 26.1 to 26.7.

For the purpose of testing, I set the LAN interface to use DHCPv4 - I have an IPv4 environment but no BGP.

The Web GUI is available every time OPNsense boots.

If your DHCP server is slow to respond, it may be the interface doesn't have an address when the Web GUI service starts, or, FRR/BGP is in some way affecting it as you wouldn't normally have DHCP assigned addresses on the internal interfaces of a router.

and then run
Code Select Expand
Code Select Expand

Code Select Expand

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0to update the BIOS bootloader (with "nda0" in the original post changed to "ada0" for my setup).

I tried this on my test system and updated the boot loader and bootcode.

I then moved the HDD & NIC's over to a much older computer and it booted successfully.

I changed the BIOS to Legacy mode and it booted just fine.

It's good to known in the event of a failed system, I can move the HDD to an older machine and be up and running again :)

In addition, to see the source address that has been used by your NAT rule, you could run 'pftop'. The address will be listed under the 'GW' column.

Code Select Expand

pftop -s1 -v state -f 'icmp and host 212.XXX.XXX.XXX'
The output should look something like this;

Code Select Expand

pfTop: Up State 1-2/2 (101), View: state, Order: none, Cache: 10000                                                 22:28:53

PR    DIR SRC                    DEST                  STATE   AGE   EXP  PKTS BYTES  RATE  PEAK   AVG RU GW
icmp  In  10.11.0.5:1            212.XXX.XXX.XXX:8      0:0      3     9     6   360               120  *
icmp  Out 87.XXX.XXX.XXX:27203   212.XXX.XXX.XXX:8      0:0      3     9     6   360               120  * 10.11.0.5:1

[which is connected to another private network behind a consumer internet connection]

09:33:06.465186 IP 212.XXX.XXX.XXX > 87.XXX.XXX.XXX: ICMP echo reply, id 19708, seq 59, length 64
09:33:06.465207 IP 212.XXX.XXX.XXX > 10.11.0.5: ICMP echo reply, id 61649, seq 59, length 64

It appears as if the packet has been reflected back out to ix1.

Just curious, what is the TTL in the echo-reply packets?

Code Select Expand

tcpdump -pnvi ix1 icmp and host 212.XXX.XXX.XXX
If you're not using a dual-WAN configuration, I would suggest you review _all_ of your rules which include 'Reply-to'.

To do this, in your 'Rules [new]' view, click on the column selection drop-down list, scroll down towards the end and select 'Reply-to'.

Ensure you have selected 'All rules' and then expand 'Automatically generated rules' so that you see them too. Identify any rule which is using 'Reply-to' and review if it may be interfering with the pings.

Have you tried pinging your phone system from another device on the home LAN and also from one of your other networks, which access the Internet through OPNsense?

One suggestion, disable the OPNsense interface which is connected to another private network behind a consumer internet connection and see if there is any change in behaviour.

Also review your Source and Destination NAT rules.

can someone with these problems share the output of this command?

Code Select Expand

/usr/local/opnsense/scripts/qfeeds/qfeedsctl.py logs

https://forum.opnsense.org/index.php?msg=271988

Having read in another post that someone can't see Events since upgrading, I thought I would check mine.

I am still on 26.1.11_6 and the problem has returned.

Here is the output from the command:

Code Select Expand

/usr/local/opnsense/scripts/qfeeds/qfeedsctl.py logs
Traceback (most recent call last):
  File "/usr/local/opnsense/scripts/qfeeds/qfeedsctl.py", line 65, in <module>
    for msg in getattr(actions, action)():
               ~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/opnsense/scripts/qfeeds/lib/__init__.py", line 219, in logs
    yield ujson.dumps({'rows': PFLogCrawler(feeds).find()})
                               ~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/opnsense/scripts/qfeeds/lib/log.py", line 82, in find
    lline = self._parse_log_line(line)
  File "/usr/local/opnsense/scripts/qfeeds/lib/log.py", line 64, in _parse_log_line
    if fw_line[6] == 'pass':
       ~~~~~~~^^^
IndexError: list index out of range


[Mirrored PC Port Mode]

Why you are wanting to use a bridge in OPNsense for this, you would be better off with a switch.

You've not provided any details, such as how you make external calls.

Different firmware may fix the phone crashing when capturing packets.

I would hazard a guess your problem is related to STUN.

You could perform a packet capture on your OPNSense box, or have a look at this site - https://tanshiyiing.com/get-syslog-using-wireshark/

What may work is Method 1 and using Mirrored PC Port Mode - if I understand this method, you don't even need a syslog server.

Of course, if you've got a syslog server on your network, you could point it to that.

Better still, if all the incoming and outgoing packets are mirrored on the PC Port, you could capture all of the communications there.