OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: rebuilder on January 31, 2022, 09:39:39 pm
-
Done a 22.1 clean install. Previously using 21.7.8 and loading the old
config file. Getting messages on the console as follows:
Quote
em0:link state changed to UP
em0:link state changed to DOWN
em0:link state changed to UP
em0:link state changed to DOWN
arpresolve: can't allocate llinfo for 70.44.90.1 on em0
em0:link state changed to UP
em0:link state changed to DOWN
em0:link state changed to UP
em0:link state changed to DOWN
em0:link state changed to UP
em0:link state changed to DOWN
arprequest_internal: cannot find matching address
unquote
The above just repeats every few minutes
em0 is my WAN interface. There does not seem to be a problem with the
other interfaces.
Would appreciate guidance on the best steps to diagnose what is going on
-
Same issue here... tried:
- clean 22.1 install with configuration restore from 21.7.8
- upgrade from 21.7.8 on another firewall
I have disable intrusion detection now on the down/up interfaces and restarted the firewall's, that "fixes" this issue for me at the moment.
Have you figured out a solution?
-
What are we looking at here? What's the operational issue? A message on the console?
Cheers,
Franco
-
Hi Franco,
In my case the WAN interface goes physically down and up every few seconds and is not working any longer. This happens as soon as scuritia is fully started and only on WAN (one port of a 4 * X710 Intel NIC or the other system is Intel i225 on WAN).
I see the the exact same console output (includeing arpresolve error's) as rebuilder.
But probably it's a misconfiguration in my intrusion detection settings?
I'll do further testings this evening... I've testet at the moment:
- Version 22.1.1_3 + 22.1.2
- Clean Install with restore vs. Upgrade
- Promiscuous mode on/of
=> the only workaround at the moment is disable intrusion detection
Regards
-
Further tests/results:
- IPS mode disabled => issue fixed... but then no protection :-(
- all rules deleted doesn't matter
- just a few rules downloaded doesn't matter
- no error's can be found in intrusion- or sysetm-logs
So no idea what to test next... propably a new clean install with just intrusion detection enabled?
-
And last but not least I have installed a fresh new vanilla OpnSense 22.1.2 without config restored, just a WAN+LAN and intrusion detection equal configured (enabled/IPS on/pattern hyperscan/some rulesets enabled&downloaded/rule defined to drop by classtype) => works great???!!!???
Can it be MAC spoofing?
Or OpenVPN servers?
Or some old tunables that I don't remenber?
-
I've seen cases where IPS mode is shoved on any interface regardless if hardware or not. The problem then was that down/up via kernel to enable Netmap mode triggered an IPv6 configuration loop in said tracking software interfaces and this brought WAN into a reconfiguration loop as well. We've taken steps in the development version to be less reactive to linkdown events on tracking interfaces, but it hasn't been moved to 22.1.x yet.
Cheers,
Franco
-
Hi Franco,
I figured it out by try and error... deleted all the special configurations step by step (additional OPT interfaces, OpenVPN client and servers, ...) and it's really the MAC spoofing!!!
I could reproduce the WAN down/up behavior together with IPS on my clean vanilla test installation.
=> if there is a spoofed MAC address entered on the WAN + IPS enabled it's starting if-down/up after netmap is loaded
=> as soon as I delete the MAC in the web GUI on the WAN and hit "Save" the down/up messages on console stops (I don't need to press "Apply changes" to stop the messages???)
=> after the spoofed MAC is remove I need to restart the firewall (because it is already in a non-working state)
=> after a restart all works great then
Regards
-
Hi subivoodoo,
Thanks for testing. Also very interesting... this is actually very helpful to be able to look into it further.
Cheers,
Franco
-
Hello,
updated to 22.1.2_1 same issue here.
@Franco is there a Fix available?
Thx
-
Hello!
After update from 22.1.1_3 to 22.1.2_1 same issue here.
Disabling IDS (and restart afterwards) stops "link state changed to down/up" every few minites.
WAN IF (Intel i350-T4): DHCP & spoof the MAC address of the interface
Deleting the MAC address on the Interface does not work ("link state changed to down/up" every few minites).
Will there be a fix?
Best Regards
-
Hello,
Any updates?
Issue exists on 22.1.7_1
Updated from version 21.7.8
The same issue and fix - when MAC address for WAN is changed - "link state changed to down/up" and "arpresolver: cannot allocate llinfo for xxx.xxx.xxx.xxx on em0" stops occuring and router became stable and accessible when intrusion detection is disabled.
GUI is unusable when IDS is active - I had to turn it off from /conf/config.xml.
-
Some people indicated the current Intel driver version or local FreeBSD 13 modifications are causing these issues and the stock Intel driver with a newer version doesn't (assuming igb/em driver). FreeBSD 13 hasn't updated drivers so no movement there I would think. If somebody points us to an upstream commit to include that fixes this we will gladly include it of course.
Cheers,
Franco
-
Run into the same issue, and can verify that it is indeed the combo of a spoofed MAC and IDS that triggers it.
-
Some people indicated the current Intel driver version or local FreeBSD 13 modifications are causing these issues and the stock Intel driver with a newer version doesn't (assuming igb/em driver). FreeBSD 13 hasn't updated drivers so no movement there I would think. If somebody points us to an upstream commit to include that fixes this we will gladly include it of course.
Did you create an issue in the upstream (FreeBSD) bugtracker or is there on, already?
If not, somebody who can reproduce the problem locally probably should do that. ;)
-
i have the same problem, wan mac spoofed and running OPNsense 22.4.1-amd64 Business edition on a DEC750
-
Unless you have specific need to run Surricata or IPS on WAN port, then you should set it to LAN port, protection wise it doesn't matter if you set it on LAN, but setting IPS on WAN can cause issues like these.
Also if you set IPS to WAN port, then you need to un-check the box for "Block private networks" on WAN interface settings.
-
thx, but for me it make no sense running it on LAN.
Maybe i will switch back to older verison freebsd12.1 until the bug is fixed.
freebsd12.1 was running fine.