Messages

I am joining the horde of frustrated people when dealing with the default values for `reply-to` and `Disable force gateway`.

In my case it was a "simple" (I thought) DNAT (Port Forward) to expose the internal email server. Everything worked fine except for all clients in the WAN subnet.

After pulling my hair out for a while, I managed to do it with manual (no reflection) rules for both DNAT and WAN.

Only after that I discovered that the reflection was not the culprit, but the default of `reply-to`.

Since I have a single GW, I disabled the `reply-to` option globally and re-created the fancy, reflection-enabled port forward rule.

Hopefully these defaults get changed at some point. For now, I have yet another thing to do on fresh OPNSense installs. :)

I totally agree with Patrick:

Force gateway and reply-to are the two "features" I like the least. Not so much the fact that they exist but the fact that they default to active.

A firewall is first and foremost a router with filtering capabilities on top. It runs on a single IP stack with locally connected interfaces and a routing table. And that should be all that is taken into consideration by default when forwarding packets.

Policy routing is of course a nice and frequently necessary feature but there should be no policies active on a newly installed system, IMHO.

Hello guys,

Just my 2 cents on this and sorry for being tired of hearing "security through obscurity" mantra thrown around all the time.

If the obscurity does not replace security then it's fine.

Changing the default ssh port from 22 to a random upper port can also be considered security through obscurity, but just changing it takes care of 99% of fully automated probes.

Same goes for the default Web UI.

Why not go one step further and add knockd? A simple, unencrypted sequence does not replace your usual security, but it sure gets rid of the vast majority of mindless scanning bots.

Let's all agree to put a huge warning on the knock configuration page, use it if we are tired of deleting logs from exotic countries and keep our opnsense up to date as usual.

Thank you. :)

PS: we still have a GRE device available, right? That's a clear text tunnel. No warnings there, no security required. Yes, I saw noobs doing GREs like they's spliting the atom :)

Well actually, I found this one in the feature request https://github.com/opnsense/core/issues/6646

I'll try to create a new feature request that would fulfill the requirements so it doesn't get automatically closed.

Hello,

I have configured an OpenVPN instance with clients certificates from a fresh new internal CA. The openvpn server certificate is also generated from that CA.

To my surprise, I was not able to see any controls in the UI to reissue/renew an expired certificate. Moreover, I wasn't able to find anything on the internet apart from this old topic https://forum.opnsense.org/index.php?topic=24900.0

Any advices would be welcome. Perhaps I should open a new feature request? Using `openssl x509 -x509toreq -in old.crt -signkey private.key` and then sign the request is clearly a non-starter, since both certificates (the expired one and the new one) will remain in the long "Certificates" list, with the new one missing the private key...

Thank you.