Topics

1

24.1 Legacy Series / git backup: ssh hostkey has changed fatal error, but git backup happens

« on: August 15, 2024, 11:16:55 pm »

I'm on 24.4.1_3 of the Business version of opnsense.

I had set up git, running on a proxmox VM, for configuration backups just under a month ago.  I recently noticed a crash report that's filled with php fatal errors of what looks to be the scheduled git backup saying that the ssh hostkey has changed.  See below.

Now, there is an outside chance that the hostkey was changed as I was tweaking some things.

The changes in backups are making it to git.  A test of the git in the backups section of configuration succeeds, so obviously even though this is a FATAL error, it's not blocking the functionality.

Where can I reset that key, so these stop happening.  I care because right now, I basically ignore the fact that there are Crash Reporter errors becuase I know they aren't errors.  I'd like to clear this so that a crash report means I should do something.

Sample php error:

Code: [Select]

[15-Aug-2024 15:17:00 Etc/UTC] PHP Fatal error:  Uncaught Exception: ssh hostkey changed in /usr/local/opnsense/mvc/app/library/OPNsense/Backup/Git.php:181
Stack trace:
#0 /usr/local/opnsense/scripts/system/remote_backup.php(17): OPNsense\Backup\Git->backup()
#1 {main}
  thrown in /usr/local/opnsense/mvc/app/library/OPNsense/Backup/Git.php on line 181
[15-Aug-2024 17:17:00 Etc/UTC] PHP Fatal error:  Uncaught Exception: ssh hostkey changed in /usr/local/opnsense/mvc/app/library/OPNsense/Backup/Git.php:181
Stack trace:
#0 /usr/local/opnsense/scripts/system/remote_backup.php(17): OPNsense\Backup\Git->backup()
#1 {main}
  thrown in /usr/local/opnsense/mvc/app/library/OPNsense/Backup/Git.php on line 181

2

General Discussion / opnsense routing IPv6 link local multicast?

« on: July 05, 2024, 05:45:43 pm »

So, I've been playing with IPv6 after avoiding it for years, and after moving a linux server acting as a router to opnsense.

I've got a number of different networks including a separate IOT and DMZ.  I had permitted IPv6 on WiFi, IOT and DMZ.  I wanted to get a sense of what types of traffic I was seeing in the DMZ and turned on tcpdump to capture 1000 packets.

There are the expected things like router/neighbor advertisement/solicitation.

However, the bulk of the traffic is mdns addressed to the link local address of ff02::fb. 

The disturbing thing is that most of these are from iOS devices on WiFi.  ff02:: addresses are IPv6 link local multicast.  They are not supposed to be routed, as I understand it.

I have checked and as far as I can find, there is nothing handling mdns proxying.  I've played with it in the past to permit airprinting from WiFi to IOT using avahi on linux.  The avahi daemon is not running on that system.  Besides, this DMZ network is for moving various services currently hosted on that linux box.  The linux box has no route to the DMZ.

I did install the mdns repeater on opnsense, but it is currently disabled--and DMZ (where the packet captures happened) is not selected even in the disabled interfaces.

Do I need to do something special in my firewall rules to make link local multicast stay link local and not act as site local?  I've got explicit blocks from all LAN interfaces to DMZ except for my computer to manage them.  That's what makes me think this ff02::fb traffic is somehow coming from the opnsense box.

It's also possible I'm fundamentally misunderstanding something about IPv6 because it's all relatively new to me.

3

Zenarmor (Sensei) / Does the ZenArmor DNS over https also block DNS over TLS?

« on: July 05, 2024, 03:42:47 am »

The subject is basically the question. I know DOH is much more common that DOT.  There’s no ZenArmor policy for blocking DOT. Does the DOH block also block DOT or is there no way in ZenArmor to so that?

4

General Discussion / SOLVED: Multiple NICs. Multiple LANs. Can't get traffic back from IOT printer

« on: June 17, 2024, 10:07:36 pm »

EDIT: see second post for details.  I had static routes on the system I was trying to reach the printer using an older (still existing) router/firewall.

I'm clearly missing something with inter-LAN traffic rules.

I've got multiple VLANs on my network.  However, I have zero VLANs defined on my OPNsense box.  OPNsense has multiple NICs and each is plugged into a switch interface where the untagged traffic is the LAN defined for that interface.  So, VLANs, but just different LANs as far as OPNsense is concerned.

For the most part, I want all the various LANs isolated, but I do want to permit some LANs to contact a printer in the IOT LAN.

It appears that whatever I do, the return traffic for that (e.g. https) is getting blocked on the IN of the IOT firewall.

Here's a simplified explanation.  I'm actually trying to permit a few different ports, but this example just uses https/443 since that is easy to test.


WAN -- (WAN/igb0) OPNsense (LAN/igb5) -- LAN (192.168.252.0/24)
                 (opt3/igb3)
                      |
                      |
                     IOT (192.168.255.0/24)
                      |
                      |
                   printer (192.168.255.196)   


Traffic seems to make it from LAN to printer but is always blocked from printer back to LAN at the IOT interface.

Outbound NATs for all LANs.  All using the same WAN address.

I've created a Group called ALL_LANS.  That group includes LAN and IOT.

There's a rule before any DENIES in ALL_LANS that permits "ALL_LANS net" to connect to the printer IP/32 using TCP/UDP port 443.

I even added an explicit ALL_LANS rule that permits the src IP/32 of the printer using a src port of 443, though I would think that was not needed.  I added this after having issues reaching the printer from the default LAN.

The IOT chain of rules looks like:

1. permit any traffic to the IOT address for DNS

2. permit any ICMP traffic to the IOT address.

3. permit printer ip/32 src port 443 to any.

4. block any traffic to dst port DNS and log.

5. block any traffic to dst net LAN and log.

6. permit src IOT net to any.

7. Deny any to any and log.


When I try to connect a LAN computer to the printer via https, it fails, and firewall logs show it's the return traffic from IOT printer to LAN computer that is blocked.  I suspect this is due to the return traffic not being recognized as related traffic.  I'm stumped as to what to do.

With rules set as above, that return IOT printer traffic is blocked and logged using rule 5.  If I disable rule 5, it is blocked and logged using rule 7.  If I disable rule 7, it is blocked and logged using the automatically generated rule of "Default deny / state violation rule."

I'm terribly confused.  I'd think if this return traffic is causing a state violation, the block would always happend in the autogenerated rules.

I've even tried creating NATs for LAN/IOT and placing those above the default WAN nat for LAN/IOT.  That did not seem to make any difference.

I'm certain I'm missing something simple and obvious. Any suggestions or questions welcome.  Pointing out where I'm clearly an idiot is really welcome if it helps me fix this and solve my issue.