Topics

[best]

I think subject says most of it.

I have an ONT/ONU device on one of my WAN interfaces that has a management IP, but after a while it stops answering ARP requests for that IP (I suspect this might be a "security" feature but I'm not positive, but I don't think it's something I can easily change).

Easy fix is to just add a static ARP entry on my WAN interface, and an IP Alias to that interface in the same subnet, and I can have permanent management access to the device.

What is the best way to add a static ARP entry that will survive reboots as well as upgrades? There doesn't seem to be a way to do it in the GUI. I found this ~4 year old post that suggested adding some lines to /etc/rc.conf but I assume this won't survive an upgrade and isn't really the "right" way to go.

If it was on the LAN side, I know I could add a DHCPv4 static entry with the "ARP Table Static Entry" option enabled, but I don't know if this will work for something in a different subnet that isn't actually being served by the DHCPv4 daemon...

[only]

This was happening on 22.1.8 and is still happening after upgrading to 22.1.9. Unfortunately I'm not exactly sure when it started happening. I noticed it after I changed the router's hostname (while still running 22.1.8 ).

I have dual-WAN, plus a LAN interface, and an OPT/secondary LAN that is disabled most of the time (but does have a static IP).

I'm using a subdomain of a public domain (that I own) for my LAN, and my opnsense machine is named "router.bh.example.net"  (example.net is standing in for my public domain here).

If I use dig against the router's hostname from my LAN, it is returning not only the LAN IP, but also the OPT, and both WAN IPs.

This is obviously somewhat of a problem because then hosts on the LAN aren't sure which IP to try to access for HTTPS / ping / etc.

I'm able to "fix" this by changing Services -> Unbound DNS -> General -> "Network Interfaces" to only list my LAN interface... but this is not desirable if I should ever want to use the OPT/secondary LAN. I don't want both interfaces to have the same hostname, and I definitely don't want public WAN IPs being resolved (internally) to the LAN hostname of the system.

I'm fairly sure Unbound / OPNsense didn't have this behavior in the past, as I think I would've run into problems trying to ping router.bh.example.net otherwise. Anybody else noticing this?

[only]

I am running dual WAN with two different cable ISPs. Both modems are in bridge mode, both WAN interfaces are DHCP. The two ISPs are Spectrum and WOW Cable.

I do not (currently) attempt any load balancing; I just have two different gateway groups that are setup for failover, with one connection preferred over the other. However, I also have a few rules in place to policy-route traffic from specific hosts out each of the connections - these hosts are "monitor-io" monitoring devices, so I can get "user friendly" visual status indication of problems with one provider or the other. (The monitor-io is a really cool device to give easy at-a-glance status of your uplink, I use them at home and one at my parents' house... but it's offtopic here.) Important to this story: I currently have WOW set as the primary connection, and Spectrum is the secondary.

Yesterday, Spectrum was having significant problems; packet loss was through the roof, and latency was very high as well. dpinger was constantly toggling the connection between "alarm" and "clear" states every minute or two. (I have all of the interval / timer settings for gateway monitoring at the defaults.)

It seemed like every time the Spectrum gateway went from bad to good status, something was being reloaded on opnsense, and it was causing traffic interruptions for management sessions to the firewall, as well as causing a fair amount of delay on traffic going out to the (still functional) WOW connection.  I also noticed (via SSH log output, before I'd get kicked off) that the "nut" service (UPS monitoring) seems to get restarted each time this "something" gets reloaded, too.

In order to get everything to a usable state again, I had to disable the gateway for Spectrum (clicked the enable/disable toggle to the left of the entry, by the checkbox, then applied).

After disabling the gateway for Spectrum, policy routing was not behaving like it should. One of my policy routes is supposed to send one of the two monitor-io devices out the Spectrum connection, and only that connection... but it was not working. The device that should've been monitoring Spectrum was showing "all good," even though I had manually disabled that gateway.

So, my two main questions:

• What exactly is supposed to happen when a gateway goes from online to warning / bad due to packetloss or latency? Should it be interrupting nut? Should it be affecting SSH sessions to the firewall/router itself? Any idea why it was impacting other traffic flow through the firewall via the remaining good WAN link?
• When a gateway is manually disabled (not "marked as always down," but fully disabled), should policy routing still be working against that gateway? My intent is for certain traffic to just be dropped on the floor in this state, but it wasn't happening.

The hardware in play here is not exactly new - quad-core Atom C2558 on a Supermicro A1SAi, quad Intel igb interfaces, and plenty of RAM (32GB ECC). Beyond nut and UPnP, I don't have anything special on the system; it's a pretty basic firewall (other than dual WAN and a few policy routing rules). I did not notice significant load spikes (even when dpinger was changing the gateway state)... CPU would blip a little, but it wasn't sitting at full load or anything. Load average was no higher than 1 or 1.5 on the shorter end, the longer timeframes were obviously lower.

I'm happy to share my rules or config if someone can give me a suggestion on the best way to do that while anonymizing passwords / etc.

I have a dual WAN setup at home, using WOW cable and Spectrum cable.

Right now, WOW is setup with a lower priority (under Gateways > Single), so OPNsense itself uses WOW as the "default route."

I have Dynamic DNS configured for both interfaces, with two different hostnames (wan-wow and wan-spectrum), but both are on the same domain at Namecheap (so they're both using the same update password, too).

The hostname for the WOW connection updates correctly.

The hostname for the Spectrum connection is throwing errors when it tries to update, like so (the ".example.com" is not my actual domain name of course):

Code Select Expand


2020-10-04T15:47:13 opnsense[59877] /services_dyndns_edit.php: Curl error occurred: OpenSSL SSL_connect: Connection reset by peer in connection to dynamicdns.park-your-domain.com:443
2020-10-04T15:47:13 opnsense[59877] /services_dyndns_edit.php: Dynamic DNS (wan-spectrum.example.com): Current Service: namecheap
2020-10-04T15:47:13 opnsense[59877] /services_dyndns_edit.php: Dynamic DNS (wan-spectrum.example.com): _checkStatus() starting.
2020-10-04T15:47:03 opnsense[59877] /services_dyndns_edit.php: Dynamic DNS (wan-spectrum.example.com via Namecheap): _update() starting.
2020-10-04T15:47:03 opnsense[59877] /services_dyndns_edit.php: Dynamic DNS (wan-spectrum.example.com): running dyndns_failover_interface for wan. found igb3
2020-10-04T15:47:03 opnsense[59877] /services_dyndns_edit.php: Dynamic DNS (wan-spectrum.example.com): 173.91.x.y extracted
2020-10-04T15:47:03 opnsense[59877] /services_dyndns_edit.php: Dynamic DNS: updatedns() starting


Any suggestions? I already enabled the "Verbose logging" option for this hostname, and that's the output above. When it's not Verbose, there are fewer lines, but the same error.

This identical setup worked correctly on pfSense, both hostnames (using Namecheap and the same base domain) were updated as expected.

I'm running 20.7.3 OpenSSL version.