The uppdate went well accept this?
Thx for a good joob
OPNsense 22.7_4-amd64
FreeBSD 13.1-RELEASE
OpenSSL 1.1.1q 5 Jul 2022
firewall: do not emit link-local address on IPv6 network outbound NAT
cannot forward src fe80:1::9c68:c6ff:fe81:a8b3 dst 2a03:2880:f00a:8:face:b00c:0:2 nxt 6 rcvif em0 outif em1
Geez, I hate this issue. ;)
I think I know what's wrong if you can confirm the issue persists after a reboot of 22.7.
Cheers,
Franco
Yes it does, dont help reboot
//Peter
Hi Peter,
Untested patch at https://github.com/opnsense/core/commit/b5bda2bda
Will try to confirm on Monday.
Cheers,
Franco
Thx Franco it will be interesting!
I hope it works
Tjoooo
//Peter
Small typo there it seems:
https://github.com/opnsense/core/commit/fe52702a8b0
So patch command is:
# opnsense-patch b5bda2bda fe52702a8b0
After a filter reload the issue should be gone.
Cheers,
Franco
Hello again Franco
I did the patch but sorry to say
same problem persists
//Peter
Hi Peter,
Not sure if this applied correctly or was reconfigured properly or some other issue at play...
# grep -n 'inet6.*-to*fe80' /tmp/rules.debug
This would show all bad rules (if they still exist).
Cheers,
Franco
Hello Franco
Here is the file
//Peter
That's just the start of the file :D I simply need the output of "grep -n 'inet6.*-to*fe80' /tmp/rules.debug" (there may be none which is what should be the case).
Cheers,
Franco
Did you get the file Franco?
//Peter
Hi Franco
I have now a mismatch checksum in my Rule .php
after the patch?
//Peter
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.7_4 (amd64/OpenSSL) at Mon Aug 1 15:04:14 CEST 2022
>>> Check installed kernel version
Version 22.7 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.7 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-theme-cicada 1.29
os-theme-rebellion 1.8.8
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: ....
opnsense-22.7_4: checksum mismatch for /usr/local/opnsense/mvc/app/library/OPNsense/Firewall/Rule.php
Checking all packages......... done
>>> Check for core packages consistency
Core package "opnsense" has 63 dependencies to check.
Checking packages: .
Where did you send it? The modification of Rule.php is expected at least.
Cheers,
Franco
Sorry Franco missunderstand you about the file ;D
I have now put back a backup and run the patch again
so fahr no fault really dont know what was going wrong
and no mismatch of the Rule.php any longer
//Peter
Hi Peter,
Thanks, I cannot find any indication of the problem with the patch at hand.
The only rule where the patch still applies is:
pass in log quick on em0 inet6 from {(em0:network),fe80::/10} to {any} keep state label "b868871c1924b50b684c1addaeb35adb" # : Default allow LAN IPv6 to any rule
and that doesn't have a "route-to" or "reply-to".
It seems we either hit a dead end or an older issue.
Cheers,
Franco
I have now put back a backup and run the patch again
so fahr no fault really dont know what was going wrong
and no mismatch of the Rule.php any longer
20min now no more fault on screen i think its working
Thx alot Franco for the help
//Peter
Crap now its back again
I post the Rule.php anyway if you wana take a look
//Peter
Hi, I have the same problem. It has been happening for a long time.
I use OPNSense virtualized on ESXi and the virtual console is filled with these messages.
Hi muchacha_grande
Did you upd to OPNsense 2.7_4?
I did not have any problem before i upd
Did you read what Franco wrote?
Small typo there it seems:
https://github.com/opnsense/core/commit/fe52702a8b0
So patch command is:
# opnsense-patch b5bda2bda fe52702a8b0
After a filter reload the issue should be gone.
//Peter
Hi @YipieKaie
Quote from: YipieKaie on August 02, 2022, 12:03:28 AM
Did you upd to OPNsense 2.7_4?
I'm running 22.7_4 already.
Quote from: YipieKaie on August 02, 2022, 12:03:28 AM
Did you read what Franco wrote?
Small typo there it seems:
https://github.com/opnsense/core/commit/fe52702a8b0
So patch command is:
# opnsense-patch b5bda2bda fe52702a8b0
After a filter reload the issue should be gone.
//Peter
I'll give a try to these patches...
thank you.
If the issue existed piror to 22.7 we might be chasing shadows here.
For one, conceptionally the message is just what it is: an information that link local packets cannot be forwarded to a global IPv6 address. This is a fact and probably not an operational issue.
Instead, let's try to pin down the message in the network stack:
https://github.com/opnsense/src/blob/3edcfbc578fd9df737aac660ea0aa85b680a8123/sys/netinet6/ip6_forward.c#L202-L231
This is very likely caused by the "route-to" (firewall rule gateway) setting, something that might need to be prevented inside pf code itself. If you set a gateway rule without a matching address link-local address on the interface could match as well causing this to happen in the first place (despite the explicit link-local handling we have added in 22.7).
Cheers,
Franco
Hello again m8
After spending a bit more of time i know what my problem
is, its the mobile phones that dont get any IPV6 IP
only a link local address. so its something wrong
in OPNsense i think. This was ok before upd to 22.7
//Peter
I tend to disagree, unless you have a packet capture with a GUA destination and a link-local source but then it's the phone not the OPNsense? oO
Cheers,
Franco
Yoo Franco
But something must have been changed in22.7
because it was working before and i have not
changed anything in the setup.
And the strange is that its only 2a03:2880 facebook
address that fuck this up no other addresses
//Peter
Well, the basic question now is what device is fe80:1::9c68:c6ff:fe81:a8b3 and why does it insist on connecting to facebook using the wrong source address (scope)?
Cheers,
Franco
If i take my old phone
fe80:1::4e66:41ff:fec4:aabd <get this lnik lokal
4c:66:41:c4:aa:bd < mac address
i dont know why the only thing i know is
it started after update 22.7
So 22.7 makes the phone send invalid IPv6 packets by messing up its scope addressing? While I agree that it may not get a GUA to pull this off it shouldn't be sending this and I have the feeling a Facebook app is involved as well?
Cheers,
Franco
Could be like you say an app but if its an app
it should give same problem when i use my pc
at facebook i presume, but it doesn´t
//Peter
In my case I can confirm that all link local addresses are from smart phones and tablets. All of them Lineage OS except for one that still has Android.
None of the devices gets IPv6 because I'm not using SLAAC, just DHCPv6.
But it seems that they are sending some IPv6 packets using the link local...
Thx muchacha_grande for the input
I still think that its 22.7 makes the phone sending
invalid IPv6 packets by messing up its scope addressing
Or maybe it have been like this all the time but not
sending it to the console until the new upd 22.7.
But i am confused why its only the facebook Ip if
surfing on Tradera nothing happend but immediately
when starting facebook it pop up at the console
Even it looks like it send some check every 10-20 min
when facebook is not active (closed) on the phone
//Peter
More testing ;D
Its Facebook and Messenger that make
the console popup so its not only Facebook
its all facebook related IP adddresses.
I think the only reason the console messages appear now in 22.7 is because we allow "link-local" origin for LAN interface in default IPv6 rule, which lets through these crappy phone packets with invalid addressing where they were previously discarded.
You can take your 22.1.x and add a default allow for IPv6, from "fe80::/10" network and watch the same happen on 22.1 most likely.
Cheers,
Franco