Topics

1

20.7 Legacy Series / radvd stops announcing IPv6 prefix after a while (radvd freeze?)

« on: September 08, 2020, 07:53:05 am »

Hi,

I have a problem which was introduced after updating to 20.7:

After round about two days of uptime of my OPNsense box, IPv6 in my networks stops working. This has nothing to do with chaning prefix (mine chages every 180 days) but I figured out that radvd does not announnce the IPv6 prefix any more. This means all clients will lose IPv6 connectivity eventually.

Clicking the restart button for "radvd" in the web UI fixes this and clients re-gain their internet connectivity after this. The strange part is that radvd is always running (output before restart):

Code: [Select]

# ps aux|grep rad
root    42763   0.0  0.1 1061048  3196  -  Ss   Sun21       0:30.35 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog

Between radvd restarts the radvd.conf and the output of "netstat -6an" does not change.

This really looks like a bug to me (radvd freezing) but I don't know how I can debug this. Any hints here on how to get to the root cause of the radvd issue? It looks like the "strace" command is not available so I am a little helpless here.


Regards,
direx

2

19.7 Legacy Series / How to create alias for current IPv6 prefix

« on: August 03, 2019, 11:56:20 pm »

Hi,

I want to write firewall rules for IPv6 and I need the delegated prefix from my ISP (WAN interface) in the rule. I think saving the current prefix in an alias would be the best option, but what's the best option to do that?

- direx

3

19.7 Legacy Series / 19.7.1: CRON-Job executed every minute spams log

« on: July 29, 2019, 08:28:08 pm »

Hi,

after upgrading to 19.7 I have noticed an excessive amount of writes in system.log. The culprit is a cron job (flock), which is run every minute. This is a part of the system.log:

Code: [Select]

Jul 29 20:07:00 gate /usr/sbin/cron[65861]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:08:00 gate /usr/sbin/cron[6378]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:08:00 gate /usr/sbin/cron[97992]: (root) CMD ((/usr/local/sbin/ping_hosts.sh) > /dev/null)
Jul 29 20:09:00 gate /usr/sbin/cron[59705]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:10:00 gate /usr/sbin/cron[86440]: (root) CMD (/usr/libexec/atrun)
Jul 29 20:10:00 gate /usr/sbin/cron[88207]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:11:00 gate /usr/sbin/cron[17638]: (operator) CMD (/usr/libexec/save-entropy)
Jul 29 20:11:00 gate /usr/sbin/cron[38445]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:12:00 gate /usr/sbin/cron[91071]: (root) CMD ((/usr/local/sbin/ping_hosts.sh) > /dev/null)
Jul 29 20:12:00 gate /usr/sbin/cron[42659]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:13:00 gate /usr/sbin/cron[16179]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:14:00 gate /usr/sbin/cron[52895]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)
Jul 29 20:15:00 gate /usr/sbin/cron[91449]: (root) CMD (/usr/libexec/atrun)
Jul 29 20:15:00 gate /usr/sbin/cron[32334]: (root) CMD ((/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null)


That's the crontab:

Code: [Select]

crontab -l
# or /usr/local/etc/cron.d and follow the same format as
# /etc/crontab, see the crontab(5) manual page.
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
#minute hour    mday    month   wday    command
1       *       *       *       *       (/usr/local/sbin/expiretable -v -t 3600 webConfiguratorlockout) > /dev/null
2       *       *       *       *       (/usr/local/sbin/expiretable -v -t 3600 sshlockout) > /dev/null
3       *       *       *       *       (/usr/local/sbin/expiretable -v -t 3600 virusprot) > /dev/null
5       *       *       *       *       (/usr/local/etc/rc.expireaccounts) > /dev/null
*/4     *       *       *       *       (/usr/local/sbin/ping_hosts.sh) > /dev/null
11      1       *       *       *       (/usr/local/etc/rc.dyndns) > /dev/null
1       3       1       *       *       (configctl filter schedule bogons) > /dev/null
*       *       *       *       *       (/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null

My questions are:

• What does this job do? I did not notice it in 19.1.
• Does this job really have to be run every minute?

Thanks in advance,
direx

4

General Discussion / Question about log ordering (system.log)

« on: May 23, 2019, 09:19:36 pm »

Hi,

I think this might be a general BSD question: I am wondering about the ordering of log entries in OPNsense. Could somebody explain this to me:

Code: [Select]

# cat /var/log/system.log | awk '{print $1 $2}' | uniq
600:14:56
May16
May17
May18
May19
May20
May21
May22
May23
rc.dyndns:Dynamic
May14
May15
May16
May1CLOG
What I don't understand is:

• Why is the most current log entry not the last line in the file?
• Why does the ordering change somewhere right in between the file? It goes from May 23 to May 14.

I am coming from Linux and I have never seen something this odd before. To me it looks like a corrupt file or filesystem, or is this normal?


Thanks,
direx

5

19.1 Legacy Series / dhcpd: Log pollution

« on: April 13, 2019, 11:25:01 am »

Hi,

I am using IPv6 on my OPNsense box (dynamic prefix, with prefix tracking on LAN interface). I am not using any manual IPv6 configuration.

What bugs me a little is that every 10 second I am getting a log message for each client on my network in /var/log/dhcpd.log:

Code: [Select]

Apr 13 09:03:26 opnsense dhcpd: Information-request message from fe80::96de:80ff:fe79:xxxx port 546, transaction ID 0x87D31C00
Apr 13 09:03:26 opnsense dhcpd: Sending Reply to fe80::96de:80ff:fe79:xxxx port 546

Does anybody know what is up with that? Does that really need to show up in the log? As I said these messages are logged every 10 seconds for almost every IPv6 client on my network (except Android clients).

I am a little worried about my flash media here because this really causes a lot of writes.

6

German - Deutsch / IPv6: Wie kann man den aktuellen Präfix in Firewall-Regeln referenzieren?

« on: March 25, 2019, 06:44:08 pm »

Hallo,

ich betreibe OPNsense 19.1.4 an einem DualStack-Anschluss der Telekom. Mein IPv6-Präfix ändert sich leider regelmäßig. Damit habe ich nun folgendes Problem bei den Firewall-Regeln.

Ich besitze derzeit folgende Interfaces mit 5 Subnetzen:

• LAN mit 192.168.1.0/24 und IPv6 Prefix-Tracking
• SRV mit 192.168.2.0/24 und IPv6 Prefix-Tracking
• MMT mit 192.168.3.0/24 und IPv6 Prefix-Tracking
• IOT mit IPv4-only 192.168.4.0/24
• GST mit 192.168.5.0/24 und IPv6 Prefix-Tracking
• ... und WAN

Die Netze sollen sich untereinander erstmal nicht erreichen (nur per Ausnahme). Mir geht es jetzt um Regeln der Art:

"Erlaube Internetzugang aus dem LAN-Netz"

Für IPv4 ist das einfach, da ist das pro Interface diese Regel:

ALLOW destination !192.168.0.0/16

Wie mache ich das für IPv6 sauber? Durch den dynamischen Präfix kann ich ja nicht einfach sagen "erlaube alles, außer destination $PREFIX/48".

Die einzige Möglichkeit, die ich gefunden habe, sind pro Interface erstmal 3 DENY-Regeln mit allen lokalen v6-Netzen (SRV-Net, MMT-Net, ...) als Ziel und darunter dann eine ALLOW-All-Regel. Das ist aber zum einem sehr umständlich und zum anderen ist die ALLOW-All-Regel recht fehleranfällig. Kommt mal ein neues Netz hinzu, dürfen alle erstmal in das Netz. Man muss dann immer noch an eine neue DENY-Regel für jeweils jedes v6-Interface denken.

Irgendwas mache ich doch bestimmt falsch, oder? Ich bin doch sicher nicht der erste, der IPv6 mit OPNsense nutzen will.


Danke und Grüße
direx