Messages

Please allow renaming gateways. There has to be a way to make this possible...

I have a multi ISP configuration and when I moved recently and brought up all of my gear, got a new primary ISP installed, and discovered I cannot rename gateways with incorrect names. Creating all new gateways and gateway groups, applying them all across the firewall rules where I specify different gateways, etc is tedious and error prone. I just want to update their names 🥲

Aha! I had Failover States enabled, but not Failback States. I don't know why you wouldn't want that as the default behavior, though.

When my WAN fails over and fails back it doesn't clear firewall states so traffic still tries to use the WAN that was previously routing the traffic. This is most noticeable when my primary WAN comes back online and traffic still flows through my backup WAN because the states still exist and the network is still functional, so it's not like it's going to have any TCP RSTs or timeouts that push the traffic back to my primary WAN.

Is there a solution to this that I'm not aware of?

I am having no issues with mine, but I'm using SSL / port 636. If you can switch to that I'd recommend it as implicit TLS is more secure that explicit TLS anyway.

Something did change because it used to work just fine roaming the VPN between LTE/5G and my LAN. Even if you change it to "UDP IPv4" so those errors go away in the logs the connection gets established but traffic seems to fail to pass. It broke for me with OpenVPN and Wireguard at the same time.

It was working flawlessly in the past for several years...

With pf and ipfw it's quite easy to write a single line rule that lets you define the allowed ICMP and ICMP6 types, but with OpnSense you have to create an individual rule for each type. Can this be refactored to allow selecting multiple types just like you can select multiple interfaces?

�

Code Select Expand


feld@gw:~ $ netstat -I ax0
Name    Mtu Network        Address                             Ipkts                 Ierrs                 Idrop       Opkts                 Oerrs                  Coll
ax0    1500 <Link#5>       f4:90:ea:00:62:2d                  382472  18446744073709551610                     0  1703087022                     0                     0
ax0       - fe80::%ax0/64  fe80::f690:eaff:fe00:622d%ax0           0                     -                     -           0                     -                     -



this is impossible :)

It needs to have avahi installed and configured for this to work, but it's not currently available as a plugin/package in OpnSense

There are changes to the OpnSense kernel that are not going to be in your FreeBSD kernel. Whether or not they are important is a different discussion, but it may cause issues.

If you really want to run this on the same hardware it should be run in a bhyve VM.

I've witnessed this happening again so now I'm doubting the previous diagnosis. I think there's something wrong with the accounting of packets and octets for the ax driver on the DEC840. It doesn't seem to provide correct values for the ax1 interface.


edit: I wonder if these bogus errors are part of the problem too?

I've been adding additional monitoring to a network with OpnSense as the firewall and noticed a curious problem with the data I was receiving. The internet uplink / WAN is on interface ax1 and I was running network tests which should have shown multi-gigabit data transfer rates with my SNMP graphing and monitoring. However, it was not showing me this in the results. The correct data rates were found on the ax0 interface instead which is not possible because that interface is only gigabit.

I believe this situation was caused by my removal of the igb1 interface which was no longer being used. The igb interfaces are earlier in the SNMP IF-MIB::ifDescr table than the ax interfaces so this seems to make sense. My problem was resolved after restarting the snmpd service and running additional tests.

I think the correct solution here is to require a restart of the snmpd service every time an interface is created or destroyed to ensure the data being served is correct. However, this may produce interesting challenges for systems that only "walk" to learn the SNMP information periodically which I recall being the behavior of Observium/Librenms. I don't know if there's a good solution for that other than recommending that admins are aware they should manually run the SNMP discovery mechanism after interface changes on OpnSense to ensure their monitoring and graphing stays consistent with reality.

If I attempt to login and manually create the user I get the following error, so it's a compile-time issue with net-snmp

Code Select Expand


# net-snmp-config --create-snmpv3-user
Enter a SNMPv3 user name to create:
snmpro
Enter authentication pass-phrase:
REDACTED
Enter encryption pass-phrase:
  [press return to reuse the authentication pass-phrase]
REDACTED
adding the following line to /var/net-snmp/snmpd.conf:
   createUser snmpro MD5 "REDACTED" DES "REDACTED"
adding the following line to /share/snmp/snmpd.conf:
   rwuser snmpro
touch: /share/snmp/snmpd.conf: No such file or directory
/usr/local/bin/net-snmp-create-v3-user: cannot create /share/snmp/snmpd.conf: No such file or directory


Hello,

After upgrading to 24.1 my SNMPv3 user no longer works. If I add in a community and try to snmpbulkwalk with v2 it works fine, but with SNMPv3 it always gives me an error.

Code Select Expand


Error in packet.
Reason: authorizationError (access denied to that object)
Failed object:


I've checked multiple times and the username, SHA, and AES settings are all correct. They just don't work.

Please expand the configuration options for os-frr or allow us to edit the config file as there is a ton of missing functionality. I really want to use peer groups so I can connect peers/neighbors and accept announcements from any address in a given subnet which is a fairly normal deployment option but this is not possible due to the severely limited configuration.

Sorry about the late reply, but this problem has been resolved for a while. I'm not sure which Opnsense update fixed it, but it did.

I was experiencing this with both wireguard-kmod and wireguard-go