Messages

Go to the NUT configuration page. Next, select the "UPS type" tab and choose "Netclient" using the little down arrow on the right side of the tab. From there, you can enter your client credentials.

Interestingly it does not show up any traffic in the firewall log which is pretty weird. I log everything to see and learn.

Traffic on the same subnet is layer 2 (switched), which is why you won't see anything in the logs due to it never reaching the firewall.

I disabled and enabled google drive backup, nothing more.

It looks like that since the update to 25.1 the backup function is not working automatically.

What I am saying is that a backup is only made to Google Drive when changes to your config have been made since the last backup. For example, I made some minor changes to firewall rules on Jan 31st. That night, a backup was saved to Google Drive. For almost 2 weeks, I made no changes to any settings in OPNsense so no new backups were saved until I made another change on Jan 13th. Try making a minor change to a rule description or something like that and see if it prompts a backup to be saved by the next day.

Are you actually changing any settings in OPNsense? A daily backup is only created if settings have been changed.

Here is the screenshot of Firewall Rule for OPT1:

As was already mentioned, that rule doesn't accomplish anything. After creating an interface, all traffic is denied by default until allow rules are created. To accomplish your intended goal, edit that rule to be an allow rule and check the inverse box for the destination. That will allow traffic to any destination that is not your LAN net; i.e. the internet.

Please show the interface configuration, the DHCP settings, and the firewall rule(s) you configured for OPT1.

Firewall Rules:
LAN = No custom rules all default generated rules
OPT1 = IPv4+6 *    *    *    LAN net    *    *    *       OPT_Block

It's not clear what that one OPT1 rule is supposed to be doing but you certainly don't seem to have any rules that allow internet access. If your goal is to allow OPT1 internet access but no access to the LAN, create a rule that allows all traffic to the inverse (check Destination/invert box) of LAN net.

It's still not very clear what you're trying to accomplish. Post a screenshot of all rules (excluding the auto ones) on your LAN interface. Just showing the one rule isn't relevant because the order of the rules matters.

It looks like you're trying to block LAN clients from reaching a particular Adguard DNS server? From your 1st screenshot, it appears you put the rule after the "allow all" rules. That's not going to work since the "allow all" rule will be matched first and all following rules ignored. Once you fix that, the 2nd rule you posted is not needed.

[* Port forward incoming TCP on port 2222 to port 22 on server on LAN - FAILURE!!!]

* Port forward incoming TCP on port 2222 to port 22 on server on LAN - FAILURE!!!

- Forwarding to : Single server <IP of LAN server>
- port: 2222

Based on your requirement, you should change to the following:

- Forwarding to : Single server <IP of LAN server>
- port: 22

[/32]

...that will allow a computer (IP address 192.168.100.2/24)...

Just a heads up. For a single host, you want 192.168.100.2/32. If you express your rule as 192.168.100.2/24, then you'll be allowing the entire range of IPs from 192.168.100.0 thru 192.168.100.255 to pass.

What exactly is concerning you about those rules? I believe it's required for NAT functionality. Also, did you happen to notice the rule direction?

You can copy the latest configuration from /conf/config.xml or locate a prior one in /conf/backups if available.

To restore a config, select option 13 from the CLI menu as root.

I believe the source will be the IP of the client on the remote network. Try changing the source to "any".

I would confirm that OPNsense is actually the reason. If you log the rule(s) that would normally allow the traffic to pass between the LAN and VLAN, then you can check your logs to confirm whether or not it's being passed. Could it be a coincidence related to an update on the VM? Try using nmap to confirm that the VM is actually listening on the RDP port. Also, check the logs on the VM and see if there are authentication errors or anything similar which would indicate that the traffic is actually getting through.

Kind of hard to help out with this little detail. Are you trying to RDP out of your network? In? Across VLANs?