Messages

[not]

No, uPnP is not enabled - as I said, it's a plugin, you can find it in "Plugins" section, then install it. It's not installed (hence not enabled) by default.

[System: Firmware: Plugins]

Hi!

Sorry I would not come with a tutorial explaining in details and with pictures what should be done (lack of time), but until somebody else will (maybe) do that, I will point you to the following 2 scenarios:

• Use uPnP plugin - Find it in System: Firmware: Plugins - especially if your torrent client is uPnP compatible
• Use NAT, Port Forwarding Rule - Firewall: NAT: Port Forward - Chose a range of ephemeral ports (typically between 1024 and 65535) in your torrent client, and then create a new NAT (Port Forwarding) rule in your firewall for those chosen ports towards your torrent machine. (For that sake, it is possible to use a single port, but this requires the torrent client to use that particular port every time it restarts)

For how to do it for each of these cases please wait for someone else with more available time than me to write a step-by-step tutorial, or read the docs and search the forum for "upnp", "NAT" and/ or "Port Forwarding" - even if you can't find your exact case in particular, those search keywords will bring up posts describing how uPnP and NAT Rules work and examples of Port Forwarding done for alike scenarios, for other services.

Hope it helps... :)
Good luck!

Also, pay attention to non-standard DNS ports used by public DNS servers, ports like 5353, 9953 and alike... And for DNS-over-TLS the standard port is 853.

A really tech savvy user will bypass your forced DNS redirection anyway!

Is it interface for Suricata to inspect?
Can I select multiple ones?

Hi!

Yes, and Yes!

I never knew it behaves like that. It does, indeed! :-O
Thank you for pointing it up, it must be about a page refresh, and I don't remember seeing an option/ setting for this behavior anywhere.

Maybe somebody else could help? :)

192.168.0.0/16 and 10.1.0.0/16 are different subnets. You need a router, not a bridge.

Since OPNsense is a router out of the box, your first point of call should be correct (static) routes for the two endpoints. I.e. does your LDAP server know that it needs to take 192.168.1.19 to get to the 10.1.0.0/16 subnet?

I suspect that the hosts on the 192.168.0.0/16 subnet have OPNsense as their default gateway, and OPNsense knows where 192.168.0.0/16 lives, since it has an interface on it.

Check the routes both ways, and do some ping tests with simultaneous packet captures.

Bart...

Very nice explanation and recommendation, Bart, my applause for you! :)

Hi!
Where is 10.0. on your schematic? I only see 10.1. (/16 - so 10.0 is not there).

+1

Glad it helped! :)

To be completely honest, I was suspecting this, but I wasn't 100% sure, so I chose to cover all angles here, knowing that you would get to the point anyway.

Good luck!

Had the same problem, but for my case "Enable Forwarding Mode" is already on, so this is/ was not a solution for me.

[installer]

Hi!
What you say is very weird, since you tried to boot and reinstall from USB, but it still stay the same, with no updates.

What I would do is:

1. Boot from an USB media having the last available version of OPNsense, chose to load config file when prompted during OS/ FW load process, load the config found on the local storage, and see if everything works as expected.
2. If everything's OK, first and foremost export a config file, so that you have a config back-up somewhere else than OPNsense itself
3. Reboot from the USB media and, after complete load of OS/ FW from USB (live CD mode), login to the console using username: installer and password opnsense. This will trigger the install to the local storage.
4. Login to the web interface and restore config from the back-up file made at 2.

Explanations:

During 1., you boot from USB so that every and all files from the local storage is ignored, the last available version of OPNsense is loaded. The only exception is the configuration (when prompted, since you so have chosen) which is loaded from the local storage. So, you are testing your current config with the freshest version available on USB media without losing the old/ existing versions + config.  ;)
During 3. the local storage is wiped out (including config - so step 2. is necessary so that you are not required to start from scratch) and a fresh version of OPNsense is installed on local storage.
During 4. you are restoring the old config over the fresh install.

It should work.
Let us know if this helped solving your issue.

Good luck! :)

Just tested, it's OK now!
Thank you, you hard workers, really thank you! :)

I confirm: if dest port is different than NAT port and an alias is used for NAT port, the FW rule generator places dest port (WAN port) in place of NAT port in the associated FW rule, so the rule is not matching traffic, and datagrams are droped by "Default deny rule".

Same here, and for me it was the fact I use aliases: in the NAT rule I changed from using an alias port for NAT to using that particular "other" (ephemeral) NAT port, and it worked.

Reading FW logs I concluded it must be a bug which changes the internal destination (NAT) port set in the port alias with the external destination port (for which I also have an alias, but I didn't check further if not using an alias for destination port would make a difference).

It only happens for rules which have a destination port <> of NAT port

Hi!
Yes, me, and for me the culprit was "abuse.ch/URLhaus" ruleset. Stop using it, if you do, and should be fine.
Cheers!