Messages

Hi, this solution works for me! Thanks.

I changed IPS>Administratiom>Settings Advanced and changed pattern matcher to Hyperscan
As pointed out by user geotek
And Detect profile to medium, may not have needed to change that
Its working for now

I have solved this by adding a rule guiding traffic from the LAN to my own external IP's to 127.0.0.1
Makes sense but wasn't needed prior 24.7?!

I have 2 WAN-connections with rules to direct traffic depending on source IP on the LAN. Also, LAN traffic gets rerouted when one link goes down.
I now have issues reaching public URL's that are managed by nginx on the router.
When I try to tracert these URL's from a PC on the LAN the tracing goes on even after the first line shows that the destination is reached?! When I tracert from the router using the LAN address I get time-outs...
Before the upgrade this was all OK. What is the cause?
How can I 'correct' this?

Yesterday evening my router stopped responding. It was still making the start/stop sounds however.
Turns out config was reverted to default settings.
After logging in it became clear the disk was full due to a +30GB Suricata log...
I understand this clogging brings the router to a standstill but I cannot understand why the router reverted to default settings?
Question: is there an easy way to limit the size of the Suricata logging?

Same issue here but strangely enough only on 1 of the 2 WAN connections?!

The 'standard' WAN interface (igb0) stopped working but the other fiber interface (pppoe0) continued working. Both interfaces are in my Suricata interfaces list...

Second time in 2 days that Unbound stops working after the update.
Will try to figure out more and post here.

Same issue with nginx here. Same error.

I am just a simple user and have idea about upstream commits.
But the logic behind it seems pretty simple: if the spoofed MAC address is the same as the physical MAC address just ignore the spoofed address.

Just to clarify: this 'issue' is not solved in release 22.1.7.

Meaning that when you spoof the actual physically present MAC your interface will have strange behaviour.

I introduced MAC-spoofing again and immediately the problems start all-over.
What surprises me is that the responsiveness from the router-GUI on the LAN-side gets crippled as well making it hard to change the settings back to 'normal'.


The log looks like this after entering a MAC-address:

2022-03-06T13:35:07   Error   opnsense    /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'igb0'
2022-03-06T13:35:02   Error   opnsense    /usr/local/etc/rc.linkup: DEVD: Ethernet attached event for dynamic opt1(igb0)
2022-03-06T13:34:59   Error   opnsense    /usr/local/etc/rc.filter_configure: Ignore down inet6 gateways : WAN1FIXED_DHCP
2022-03-06T13:34:59   Error   opnsense    /usr/local/etc/rc.filter_configure: ROUTING: keeping current default gateway '213.118.192.1'
2022-03-06T13:34:59   Error   opnsense    /usr/local/etc/rc.filter_configure: Ignore down inet gateways : WAN1FIXED_DHCP
2022-03-06T13:34:59   Error   opnsense    /interfaces.php: The WAN1FIXED_DHCP IPv4 interface address is invalid, skipping.
2022-03-06T13:34:59   Error   opnsense    /interfaces.php: Choose to bind WAN1FIXED_DHCP on  since we could not find a proper match.
2022-03-06T13:34:59   Error   opnsense    /interfaces.php: Adding static route for monitor 8.8.8.8 via 213.118.152.1
2022-03-06T13:34:59   Error   opnsense    /interfaces.php: Removing static route for monitor 8.8.8.8 via 213.118.152.1
2022-03-06T13:34:59   Error   opnsense    /interfaces.php: Adding static route for monitor 8.8.4.4 via 213.118.192.1
2022-03-06T13:34:59   Error   opnsense    /interfaces.php: Removing static route for monitor 8.8.4.4 via 213.118.192.1
2022-03-06T13:34:58   Error   opnsense    /interfaces.php: ROUTING: keeping current default gateway '213.118.192.1'
2022-03-06T13:34:58   Error   opnsense    /interfaces.php: ROUTING: setting IPv4 default route to 213.118.192.1
2022-03-06T13:34:58   Error   opnsense    /interfaces.php: ROUTING: IPv4 default gateway set to opt4
2022-03-06T13:34:58   Error   opnsense    /interfaces.php: ROUTING: entering configure using defaults
2022-03-06T13:34:57   Error   opnsense    /usr/local/etc/rc.filter_configure: ROUTING: keeping current default gateway '213.118.192.1'
2022-03-06T13:34:57   Error   opnsense    /interfaces.php: ROUTING: skipping IPv4 default route
2022-03-06T13:34:57   Error   opnsense    /interfaces.php: ROUTING: IPv4 default gateway set to opt4
2022-03-06T13:34:57   Error   opnsense    /interfaces.php: ROUTING: entering configure using 'opt1'
2022-03-06T13:34:57   Error   opnsense    /interfaces.php: The command '/sbin/dhclient -c '/var/etc/dhclient_opt1.conf' -p '/var/run/dhclient.igb0.pid' 'igb0'' returned exit code '15', the output was 'igb0: no link ...'
2022-03-06T13:34:57   Error   opnsense    /usr/local/etc/rc.linkup: DEVD: Ethernet detached event for dynamic opt1(igb0)
2022-03-06T13:34:56   Error   opnsense    /interfaces.php: Clearing states for stale opt1 route on igb0
2022-03-06T13:34:56   Critical   dhclient    exiting.
2022-03-06T13:34:56   Error   dhclient    connection closed

Hi, personally not using os-freeradius here.

As for my remark about spoofing the real MAC-address: when I tried on another machine the real MAC-address was different. Meaning that it is the spoofing itself that seems to trigger the problem.

I will try to replicate the issue this weekend by re-introducing spoofing 'just for fun'.

Hi, reading the posts here I decided to remove the MAC-spoofing. As a result everything is back to normal...
I downloaded updated rules for Suricata and enabled it: everything stays normal.

Regarding the MAC-spoofing: the MAC-address I had in the config was actually the real physical MAC of the interface. Can that be a reason?

Same problem here. I have 3 WAN-connections, all get their address from ISP through DHCP. The problematic interface is that one with a DHCP-delivered static address. When I disable that WAN-interface (MAC spoofing) the system becomes stable.
Did a fresh install on another machine with an older version, did the upgrades and face the exact same problem?!
Later today will try 2 things: revert to previous version on the original machine. And try a fresh installation with latest version on the other machine.

You are right. That part can be dismissed.

So it's basically the Domino side that needs tweaking...

Recently installed Nginx on one of the OPNsense devices I manage.
One of the upstream webservers there is a HCL Domino 11 server.

How to get the downstream (client) IP address in the domlog.nsf?

Found this post https://blog.nashcom.de/nashcomblog.nsf/dx/fail2ban-support-for-domino-intrusion-detection.htm to get me started.
Changed the notes.ini by adding HTTP_LOG_ACCESS_XFORWARDED_FOR=1 in order for Domino to register those headers.

In the HTTP Server config TAB in OPNsense, using the advanced mode, choose X-Forwarded-For as Real IP Source. This will add the right headers to the requests to the Domino server.

I changed the domlog.ntf as follows:
- I edited the form fmLogEntry and added the field ForwaredFor next to UserAddress
- I edited the view All Requests and changed the Formula for the column Remote User by replacing UserAddress with ForwaredFor

Doing this now gives me the client IP instead of the OPNsense address in that form and view. You can change the other forms and views accordingly if needed.

Drop me a line in case you want a copy of the edited template.