Messages

It is not the NAT rule, but the "pass" setting you specified with it. When you select "manual", you can tailor and prioritize a specific rule to your liking, which is what I wrote in #4 already.

The instructions to do this are literally on the linked page.

You can use virtual IPs on the WAN interface even if the initial IP is obtained through DHCP. While VIPs can be used to gain access to a WAN bridge like a modem or ONT, you can also create additional routeable IPs like that.

The normal way to go forward would be to place the real servers behind those IPs behind OpnSense in one or more separate (V)LAN(s).

With that, you can do whatever you like with the WAN IPs, like port-forwarding them to the internal hosts or simply using a reverse proxy, just as you please. By using a reverse proxy, you can also lay the burden of gettings ACME certificates on OpnSense.

I do it like that and I use separate VLANs for any DMZ host, such that when one gets compromised, it cannot reach any other DMZ host directly. Also, my DMZ targets usually are VMs or LXCs on a trunked virtualisation host.

You can even do both OpnSense and your VMs on the same host using that concept, see this. If you do not have to pay monthly for each physical machine, like in a home setup, I would prefer to separate OpnSense and the virtualisation host, however.

As I said: That is a potential, theoretical cause, which is highly unlikely, because that IP does not have an open NTP port, so it will most surely not be in any NTP pool list.

However, if it was, then your firewall would be open once your NTP instance tried to contact it.

I highly doubt that only this single IP can get through at this time, as only this one contacting you means next to nothing - you do not know how their selection process for outbound connections is. Maybe that one is the only one trying. Unless you have proof the other ones are being successfully blocked, that is.

You can easily check which pf rules really apply or result from your GUI settings, as I said: Look at /tmp/rules.debug.

You can also check what IPs are in the alias that is built from your list, they are in the firewall status.

It is simply illogical to assume a single IP from a range to be "forgotten" - a misconfiguration is more likely, that is all I can say.

(This one is purely theoretical, because 66.132.186.197 has no open NTP port)

NTP is a UDP protocol, which is stateless by default. If that one IP is in one of the NTP time server specifications, which often are specified as pools, which in turn can have thousands of entries, you querying them will also allow them contacting you for a short time.



What I think the real reason is:

You did an NTP redirection which creates an implicit allow rule if you do not specify the "manual", but the "pass" rule. I think that goes before any interface-specific rules. This is not as easy to see with the new rules than with the old ones. It was the main reason for me to have such block rules in the "Floating" section of the old rules - even if they applied to just one (i.e. WAN) interface: Otherwise, any other "Floating" rule could not be blocked.

With the new rules, this is not possible any more: Once you only have one interface, the rules are not floating any more.

You will find the answers here: https://en.wikipedia.org/wiki/Unique_local_address

Site-local-adresses (fec::/10) have been deprecated and are in the global allocation block, so potentially could be routeable at any point.

fc00::/8 is proposed to be managed, but is not at this time. So, only fd00::/8 is truly locally administered and thus "private" in some sense.

Not that it matters much if you do not have explicit allow rules and also use such ranges, which would go against specifications, anyway.

Also:

MTU value is for the PPPoE

You have to deduct something for the VPN header overhead from your actual MTU, you know that?

Also, Patrick is right: That blocked packet clearly shows that the default deny rule applies, so whatever rule is supposed to allow that VPN traffic seems to be incorrect.

Your clients must somehow get to your OpnSense, normally this is done via some kind of dynamic DNS update - unless you have static IPs.

The only ways your remote clients know at which IP they must direct their WG VPN packets to are:

1. Static IPs.
2. A DNS entry that can be resolved and points at whatever IP your OpnSense has at the time, especially with dynamic IPs. It is this entry that must be present in the client configuration - and AFAIK, it is not automatically included in the peer configuration that OpnSense generates.

So, you must create and upkeep a DNS name under which your OpnSense can be reached - at least if your WAN IP address changes at times. Also, when the connection drops, the connection must be re-initiated by the client, potentially with the same DNS entry now pointing to another IP adress.

If the connection is not created at all, logs will not help you. You can try to do a tcpdump on the WAN interface in order to see if packets on the Wireguard target port even reach your OpnSense. If that is the case, you can try to enable logging for dropped packets and find out why they are blocked.

Obviously your clients cannot connect from outside. That may be because of different reasons, it can even fail before your own WAN firewall rule kicks in, like:

- bad DNS resolution, so that your client cannot find your Wireguard endpoint.
- double NAT setup (router-behind-router), like when your OpnSense is behind an ISP router instead of a bridge modem or ONT.
- your ISP providing CG-NAT only, which essentially is double NAT as well.

Show-the-rules (i.e.: all of them). Order matters. Interfaces matter. Direction matters. New rules or old matter - especially, when old rules have not been deleted.

From what it sounds, you have a preceeding rule to allow that kind of traffic before your blocking rule can hit.

You can also get /tmp/rules.debug and throw it at an AI of your choice together with the packet you think it should block for an explanation. For those types of work, an AI is actually quite good.

What else would be the intent of HTTPS introspection? As I said, Adblocking (and even kid safety) can be done with DNS and / or IP blocking (that is, iff you also control DNS tightly).

The easiest point to intercept HTTPS traffic is on the endpoint device itself, not by interfering with traffic on any intermediary (to prevent that is essentially a design goal of traffic encryption in the first place).

In my experience, if you want enterprise-level security, you conceptually will have to use a layered approach, because punctual measures will be circumvented sooner or later. If you do not need to protect your users from themselves, you do not need most of that, anyway.

That of course includes 802.1x, DNS redirection (plus blocking of DoT and DoH, which is also hard), and control of HTTPS traffic (preferably on the endpoint), not to forget blocking VPN traffic of any kind.

To do all of that is a major effort which most people - including me - will not take, but it is certainly a nice playing field.

Try to do it with your IoT devices and you will see what I mean. Essentially, they will have no internet access at all, because you cannot inject your own CA into most of them. If you then exempt them from HTTPS inspection, you are all set when somebody uses an IP in the exempt range.

That means: a homelab with IoT devices and stuff means exemptions are neccessary and then anybody can use those IPs. Even if you use VLANs, if you do not also have 802.1x (aka "enterprise features"), anybody can circumvent it. I never said that it can only be justified in an enterprise context - it is only achievable in an enterprise context (with a lot of work), not in your average home network with lacking features and given requirements. And as you say: "At work...".

That is what I meant by "you can't". You can - but it will not keep your kids safe, not even speaking of them using LTE on their mobile phones when they find blocking in your WLAN or using a free VPN. Ad blocks and other stuff can easily be done via DNS blocks, so what can you actually achieve?

I think that this is not worth the effort, but you do you.

Sorry, but I still do not get what the actual problem is:

a. You can tell the dyndns updater to use any (static) suffix you like.
b. You cannot know which temp addresses a client will use - so you cannot update dyndns "in lieu" for a client for a temp address - but that is not neccessary, because there will always be a static IPv6 under which the client can also be reached, so you can use that.
c. Same goes for OpnSense itself, iff that even used temporary adresses.

When you forget about your scripts and formulate the exact problem: what type of dyndns adresses are those that you want to make accessible that are problematic? OpnSense itself or clients? Temp addresses or "static suffixes"?

The next step is to understand how to do and implement https inspection.

Easy: You don't. See this, point 12.

Deine Screendumps zeigen ein /56 für das LAN, das wäre falsch, es muss /64 sein. Du musst ein beliebiges /64 Präfix aus Deinem /56er Bereich wählen.

Typischerweise ist die WAN-IP übrigens /128. Geht IPv6 von der OpnSense selbst?