Messages

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 Expand


# 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

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

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 Expand


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 Expand


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

Hi Franco,

thanks for the explanation, that makes sense. I felt like a total Unix noob when first using less/grep/cat on these log files :D


- direx

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 Expand

# 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

Find the device fe80::96de:80ff:fe79:xxxx and take it offline.

It's not just a single device, it's literally all of the computers on my network.

But I found out what is causing this:

By default OPNsense configures radvd to send RAs every ten seconds. Since by default the RAs are of type "stateless" (Statless Autoconfig and optional DHCPv6 Server queries"), whenever a RA is received by the clients they query the DHCPv6 server for additional information (such as DNS servers). I am not sure if that is a bug or a feature, but I think sending DHCPv6 queries every ten seconds is a bit too much.

There are two workarounds (I personally use use both now):

• Increase the RA interval (radvd default is 600, OPNsense uses 10)
• Use completely unmanaged  Router Advertisements (no DHCPv6 at all, not even for additional information)

You can define the RA type and interval on a per-interface basis by selecting "Allow manual adjustment of DHCPv6 and Router Advertisements" for every interface. You can then configure "Router Advertisements" under "Services".

I chose to increase the RA interval to 30 seconds (that's the default interval which Cis*o recommends) and I also set the RA type to unmanaged. Now these log messages have disappeared completely. And I don't need a DHCPv6 running at all.  :)

Hi,

thanks, that /var trick would work around the flash issue.

I would like to know though why these Information-request messages are logged in the first place every ten seconds. This still looks like something is broken.


- direx

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 Expand


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.

@rolfd: Das mit dem Interface in der Regel geht wohl auch nicht. Das Interface in der Regel wird in die Interface-IP-Adresse aufgelöst.

Man hat also derzeit wirklich keine Chance auf eine sinnvolle Lösung. Drückt weiter die Daumen für bessere IPv6-Unterstützung in 19.7  ;)

Zur Info:

• Feature-Request bzgl. Regeln für dynamisches IPv6 Prefix (war schon da): https://github.com/opnsense/core/issues/2544
• Feature-Request für Interface in Regeln: https://github.com/opnsense/core/issues/3380

Drückt die Daumen, dass mindestens eins der beiden Features in 19.7 landet  ;) Zumindest der Dyn-v6-Prefix-Support steht schon als Milestone drin, das klingt ja vielversprechend. Dann könnten endlich großflächig OPNsense IPv6-Deployments erfolgen.

- direx

[lokale]

Moin,

ich glaube wir reden aneinander vorbei :)

Wobei das genau genommen eine "ALLOW -in LAN -out any -proto IPv6" ist..

Genau das ist das Problem. Das "-out any" würde dann auch sämtlichen IPv6-Traffic in andere lokale Subnetze durchlassen, was ich genau nicht möchte. Normalerweise müsste die Regel nach OPNsense-Philosophie IMHO so aussehen:

Code Select Expand

ALLOW -in LAN -out !IPv6_Prefix -proto IPv6

Also erlaube sämtlichen IPv6-Traffic, der nicht wieder zum eigenen Prefix (und damit potentiell in andere lokale Subnetze) geht. Dazu müsste ich aber den aktuellen v6-Prefix referenzieren können.

Eine -out wan mit prefix sieht so aus:

Code Select Expand

pfctl: DIOCGETRULES: Invalid argument
pass in quick on em0 inet6 from any to (nfe0:network) flags S/SA keep state label "USER_RULE: testrule"
root@drexbox:~ #
Ansicht in der GUI ist dann:
"IPv6 *         *       *       WAN Netzwerk    *       *               testrule "

Dann geht der Traffic aber nicht ins Internet, sondern nur in das Netzwerk, was direkt am WAN-Interface anliegt (also das Provider-Netz). Bringt also leider auch nix.

eine selbst gefrickelte

Code Select Expand


pass in quick on em0 inet6 from any to nfe0 flags S/SA keep state"

... also ohne das network... via shell Befehl oder script würde vermutlich auch gehen, auch wenn die GUI das nicht anbietet.

Das ist die einzige sinnvolle Möglichkeit. Wie du sagtest bietet das die UI aber nicht an und selber wollte ich hier eigentlich keine Regeln dazuscripten.

Bleibt also die Erkenntnis, dass IPv6 mit OPNsense in dieser Konstellation so noch nicht vorgesehen ist. Zwei (jeweils unschöne) Workarounds wären also:

• Auf der Shell: Selbst gefrickelte Regel ("sicherer" bzw. robuster, allerdings mit Scripterei verbunden -> unschön und kann bei Updates kaputt gehen)
• Alternativ in der UI: Erst selektiv IPv6-Traffic in alle Netze verbieten (bei mir 5 DENY-Regeln je Interface) und danach dann ein IPv6 ALLOW any. (Das ist die klickbare Variante, die ich aber für sehr fragil halte -> ebenfalls unschön)
  

Eine saubere Lösung wäre also zumindest eins der folgenden beiden Features offiziell in OPNsense bereitzustellen:

• Möglichkeit zur Referenzierung des aktuellen IPv6-Prefix (für DynPrefix-Opfer wie mich)
• Als Destination direkt ein Interface angeben (das ist eigentlich generell praktisch)

Liest hier evtl. auch ein Entwickler mit, der dazu was sagen könnte? Ansonsten kann ich auch mal einen Feature-Request aufmachen.

Also ich habe genau wie His.Dudeness für Drosselkom VoIP nur genau eine Outbound-NAT-Regel bei mir.

Setup ist wie folgt:

• FTTH-Modem -> OPNsense (per PPPoE) -> Fritz!Box (als DECT-Basis)
• Eine einzige Outbound-NAT-Regel mit Static-Port für die Fritz!Box (siehe Screenshot). Andere Regeln brauche ich für VoIP nicht, auch keinen SIP Proxy.

VG
direx

"ALLOW -in LAN -out WAN -proto IPv6" geht doch auch in opnsense?

Eben nicht, sonst wäre es ja ganz einfach. Zumindest wüsste ich nicht, wo man das einstellt. Wo willst du das denn einstellen? Du kannst meiner Meinung nach als Destination nur sagen "WAN address" oder "WAN net", aber beides ist nicht gleich "WAN interface". Oder übersehe ich da jetzt was?


Danke und viele Grüße
direx

Ist auf franco's "long-term TODO list":
https://forum.opnsense.org/index.php?topic=9773.msg44620#msg44620

Das ist schonmal eine gute Nachricht, danke für den Link.  :) Ist zwar schon etwas älter und ins 19.1er-Release hat es das offenbar nicht geschafft, aber vielleicht klappt es mit dem 19.7er.

> Wie sieht das eigentlich bei der Konkurrenz aus? Gibt es gut funktionierende Lösungen für diesen Anwendungsfall?

Nein, weil im IPv6 RFC so ein Bullshit ursprünglich gar nicht vorgesehen ist.

Naja, im ursprünglichen RFC2460 fehlt ja so einiges. Viele Dinge kommen halt erst später dazu, das war schon immer so. DHCPv6 mit "long-lived prefixes" kam halt "erst" 2003 im RFC3633. Aber wie genau "long-lived" zu interpretieren ist, lässt der RFC (wohl bewusst) außen vor. Diese Diskussion führt also zu nix.

Und weil die Frage bezüglich der "Konkurrenz" aufkam, dort gibt es das Problem gar nicht. In IPFire kann man z.B. Regeln definieren der Art "ALLOW -in LAN -out WAN", komplett auf Interface-Ebene und damit entkoppelt von irgendwelchen v4 oder v6-Adressen. Dynamische Präfixe sind demnach dort gar kein Problem.

Und bei Unifi von Ubiquiti geht das auch per Management-Shell. Übrigens sind sogar inbound-Regeln für v6 bei diesen beiden "Konkurrenten" problemlos möglich (bei statisch gesetzten IPv6-Tokens), indem einfach nur die letzten Bits der Adresse gematcht werden (inverted mask match).

Aber wie gesagt, ich wollte hier gar keine Diskussion dieser Art lostreten, weil das zu nix führt. Nur die Behauptung, dass das sowieso alles Bullshit ist und die Konkurrenz auch keine funktionierenden Lösungen hat, wollte ich so nicht stehenlassen. Ich denke wir bleiben trotzdem alle bei OPNsense  ;)

> Das ist glaube ich auch Gang und Gäbe bei so ziemlich allen ISPs

Weil es alle anderen so idiotisch nachgemacht haben, ist es nicht "OK". Nur die Marketing Schiene, dass es ja "was positives" für den Kunden ist und man ja um seine Privatsphäre besorgt ist ...

Mir persönlich wäre ein statischer Präfix für meinen Anwendungsfall natürlich auch lieber. Allerdings ist deine grundsätzlich ablehnende Haltung hier auch wieder nicht zielführend in der Diskussion. Jeder hat andere Anforderungen und ich würde das Privatsphäre-Argument tatsächlich gelten lassen (auch wenn das vielleicht aus einer Marketing-Abteilung kommt). Privacy-Extensions sind relativ witzlos, weil man dich über den Prefix trotzdem tracken kann. Und klar, natürlich kann man dich auch trotz dynamischen Präfix mit verschiedenen Techniken tracken, aber es ist halt etwas aufwändiger. Die IPv6-Adresse als Tracking-Merkmal servierst du halt auf dem Silbertablett.

Und klar ist das eine miese Nummer, dass die Drosselkom statische Präfixe als "Business" verkauft, obwohl der Mehraufwand dafür quasi Null ist. Wir müssen aber halt auch irgendwie mit dem klarkommen, was aktuell (leider) am Markt üblich ist. Es kann sich halt nicht jeder immer seinen ISP aussuchen.

Man sieht es BTW an lokalen oder kleineren Anbietern, die sich mit alten Zöpfen nicht herumschlagen müssen, dass dort statische IPs oder Prefixe oft gar kein Problem sind.

Die kleinen Anbieter sind häufig die bessere Wahl. Besonders die Telekom ist ja bekannt dafür, überall so viel Geld zu erpressen, wie nur irgend möglich - siehe die Wegelagerei mit dem Peering/Double-Paid-Traffic. Aber das driftet schon wieder aber, sorry.

Man muss halt einfach mal der Realität ins Auge sehen. Und die sieht eben so aus, dass die großen ISPs DHCPv6 mit sich ändernden Prefixen fahren. Ich glaube mein Prefix ändert sich auch nur bei der PPPoE-Neueinwahl (also bei jedem Firewall-Reboot) und ist damit tatsächlich quasi "long-lived". In Firewall-Regeln kann ich ihn deswegen aber trotzdem nicht benutzen und da hoffte ich eben auf irgendeine sinnvolle Lösung.

Falls doch noch jemand was zur eigentlichen Problemlösung beitragen kann, wäre ich natürlich dankbar. Aktuell bleibt halt wirklich nur als Workaround auf jedem Interface eine DENY-Regel für jeweils alle anderen v6-Netze. Und danach dann eine ALLOW-any-Regel.


Viele Grüße
direx

Hallo,

also das mit dem dynamischen Präfix finde ich aus Privatsphäre-Sicht eigentlich auch ganz okay. Das ist glaube ich auch Gang und Gäbe bei so ziemlich allen ISPs. Immerhin bekomme ich ein /56er-Präfix von der Drosselkom, damit kann man recht gut arbeiten. Durch das Prefix-Tracking kommt OPNsense ja auch grundsätzlich damit klar.

Also kann man die Aussage wagen: Sobald mehrere Subnetze im Einsatz sind, dann ist "richtiges" IPv6 Pflicht? (Ausser man will basteln oder nur IPv4 verwenden.)

Also "richtiges" IPv6 ist es ja schon. Die spannende Frage ist halt, wie sich das die OPNsense-Entwickler gedacht haben - auf der einen Seite gibt es Prefix-Tracking an den Interfaces (für genau solche Umgebungen mit dynamische Prefixen) und auf der anderen Seite kommt die Firewall damit offenbar nicht klar. Das verwirrt mich halt.

Ich kann auch nochmal im englischsprachigen Forum fragen, vielleicht ließt ja dort ein Entwickler mit und kann Auskunft geben, wie das jetzt konkret gedacht ist.


Viele Grüße
direx