Messages

Take a look at this post, it will most probably explain your situation and how to fix it (and knowing the problem will prevent you from creating it again).

[it can ping one of the android tv box only. Not others Window Lan as well.]

A fine example of how you misinterpret things according to your confirmation bias:

One of my LAN - almalinux cannot ping gateway IP. Very strange, it can ping one of the android tv box only. Not others Window Lan as well. I try to disable the firewalld n look the ip route show and found nothing.

 It cannot browser internet anymore. I can browser intenet yesterday. This is proof. Something is broke.

"This proof" means only:

1. You can ping at least one device on your LAN 192.168.1.0/24, so obviously your Linux PC is connected to some network.
2. Not being able to ping Windows PCs on your LAN is perfectly normal, depending on what kind of network connection (private or public) is selected. The Windows firewall does not allow incoming pings.
3. Not being able to ping the gateway can be because of many reasons, most of which are simple misconfigurations:

- Having selected the wrong port to connect to because physical ports are numbered differently than logical NICs
- Using multiple ports as a bridge without having them configured as per docs
- Using another subnet or differrent VLAN
- Cabling problems
- Not having opened the firewall for such kind of traffic (or having blocked such traffic by error in trying to "strengthen security"

For example: Did you try the other way around, namely to ping the Linux PC from your OpnSense?
4. Together with not being able to reach the internet (because of what? Can you resolve DNS names?) it suggests missing connectivity to your firewall for any kind of traffic.

You see: None of "this" is "proof" - only a hint at some kind of misconfiguration. Nobody questions "something is broke", but there is no grounds to suggest any hacker being involved.

Altogether this means:

a. unproven claims of hacker attacks
b. random tries to "strengthen security"
c. (only after asking for facts) connection problems of some kind
d. not enough useable facts for us to start with

Instead of jumping to (false) conclusions, you would be better off to state the facts, like in this case: "I do not get internet connection and I cannot reach my gateway", together with helpful facts about what you have done, including:

- network topology
- firewall rules
- positive and negative results of tests you have conducted to identify the exact problem

Also, stop messing around with random measures like:

I added RESET WAN interface every 10 min using cron job.

Those will do more harm than good if you do not know what you are doing. This alone might account for missing internet access...


P.S.: Your network configuration looks right and the fact that the gateway is in the arp table suggests a blocking firewall rule, no physical or VLAN problem.

Did you actually try to keep the server ID fixed? Or try to use one of the fast Comcast servers now? Obviously, those were never used in 2026 for whatever reasons, thus the numbers are not comparable as such.

Maybe the mechanism has changed for 26.x?

Also, did you heed the warning about dependencies and changing values without a reboot? It sometimes matters in what order the values are being applied.

Matter-of-fact, with some ISP equipment, the enlargement does not work at all, so consider yourself lucky if it works for you.

I keep hearing that multi-threading support is on the top of the priority list for some years now. Sounds like when Trump says "in two weeks".

And yes, you would be hard pressed to find a low-power (embedded) CPU with a high enough single-thread performance to run Zenarmor at >= 1 GBps speeds. Only desktop or high-performance server CPUs (many server CPUs have many cores, but low single-thread performance) would do that.

And even then, you would only use a fraction of the potential power, but have the high cost (both purchase and consumption) until multithreading will be supported.

Yeah, that all sounds too familiar. Considering the style, the claims and even the profil name, I suspect that @peterwkc is the same person, so it is now the bazillionth time, see: https://forum.opnsense.org/index.php?topic=44259.0

@nicholaswkc: I suggest you to find a new hobby besides IT. The way you argue shows that you do not know what you are talking about. It seems like a mix of not understanding why specific things go wrong for lack of technical skill, mixed with a paranoid fear that the problems are not caused by your own mistakes, but by some evil hackers/ISPs/whomever.

You have been advised multiple times now, that your claims (which I cannot even comprehend) do not match reality.

However, remembering the old saying "just because you are paranoid does not mean that they are not after you.", maybe you are right. Are you living in Russia by any chance?

Since Zenarmor still is limited to one thread only, you can simply relate any known CPU's single-thread performance against the C3758R's single-thread perfomance on one of the many CPU-Performance comparison sites. The kind of work Zenarmor is doing here cannot be easily accelerated by a proprietary chip, unlike encryption.

So, choose a CPU whose performance you know and compare it.

1. Such requests can be done via Github.
2. You can achieve the same effect by using categories.

Some things come to mind:

1. Why are the interface names different? By using vtnet interfaces, you could have the same names as before, regardless of which hardware PVE uses.
2. IDK how things are set up when you start the setup wizard with a WAN interface with a fixed IP - maybe, there is no outbound NAT, which would prevent the LAN side from working correctly.
3. Do you know this article?

[Thus, for the time being, it seems advisable to stop Kea, manually delete conflicting (or all) leases from both lease files and start Kea again when changes to static reservations are made.]

I may have found the answer - and the observed problem is most probably uncorrelated to the host discovery service.

Matter-of fact, Kea uses two files to register dynamic leases: kea-dhcp4.leases.csv and kea-dhcp4.leases.csv.2. One of them is a journal that is sometimes flushed to the other file: https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#why-is-lease-file-cleanup-necessary

Also note, that unlike with ISC DHCP, Kea registers static reservatione in these files. If you then change something in the reservation, say, for instance, you change a MAC because you exchange a VM for another on your Proxmox host after an upgrade and want to keep its IP or if you only move a client to another VLAN, the lease file will still hold the old entry. Matter-of-fact, that was exactly what I did before the problem that I described before occured again.

When the newly created client with the static reservation now requests an IP via DHCP, there will be a conflict with the message I showed above.

What is more, is that this seems to trigger a cascading effect in Kea which seems to be a bug and is also discussed here for the "other product":

https://forum.netgate.com/topic/198115/changing-the-mac-address-on-a-kea-static-lease-does-not-work/4

At least one of you who observed the same problem also uses Proxmox, so it is kind of likely that something like this occured.

Thus, for the time being, it seems advisable to stop Kea, manually delete conflicting (or all) leases from both lease files and start Kea again when changes to static reservations are made.

I had reactivated the host discovery service again after this discussion. All went fine until yesterday, when I observed that on one of my VLANs, devices stopped to use their assigned reservations and started to use pool IPs. I had to stop the host discovery service and also delete the lease files completely to fix it, because removing only the affected leases did not work.

At the same time I saw multiple warnings in the Kea log like:

Code Select Expand

WARN [kea-dhcp4.alloc-engine.0x45007886b008] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 b0:f2:08:33:33:33], cid=[01:b0:f2:08:33:33:33], tid=0x94985f43: conflicting reservation for address 192.168.9.6 with existing lease Address: 192.168.9.6

I only noticed it, because one of the affected IPs was directly monitored and I got an alarm that it became inactive (because it was on another IP).
If I did not notice that so early, this might have ended up in a situation like I described, where after a while, all IPs on the subnet would have been taken and my ping-based network monitor would have shown all IPs as active.

I still do not know how this happens, but I never saw it without the host discovery service. I know that it does not ping by itself and from glacing over the code, I cannot see why or how this should respond to pings, either. Maybe the code triggers an obscure side-effect.

I have a somewhat difficult question: How can I implement a rule to allow "local" traffic only for specific named backends?

That means, I want to selectively block external access for specific domains.

I know how this works for IPv4: you can simply create a rule with a condition based on RFC1918 IPs and create a 4xx response if if does not match.

However, my situation is that my LAN clients use IPv6 GUAs generated from dynamic prefixes as assigned by my ISP, so I cannot specify the prefix to match. The WAN IPv6 is also from that prefix ("Request prefix only") and it is the target for the DNS names that HAproxy handles. Since that IPv6 always has more priority than any IPv4 or ULA IPv6, it will be the target for the HTTP(S) requests, thus NAT66 will not really cut it.

Access to lower layers than 4 is impossible within HAproxy, so I cannot use hop limits either. I have not even found a way to ask for the inbound interface because of this restriction.

All solutions I have pondered are too crude and involve scripting or using split DNS. Port-forwarding is also questionable, given the fact that there are internal layer 4 redirects to localhost with this setup already.

Presuming all of your VLANs have outbound NAT: Did you do the obvious and created firewall rules for outbound access for all VLANs?

OpnSense does create a default "allow to any" rule only for the first (V)LAN. If that happens to be your MGMT_VLAN now, it is clear why only this VLAN has internet access.

See this, point 3 - maybe the article also helps with other aspects you will stumble upon later on.

Maybe you misunderstood something, but this thread was about DHCPv6 on WAN not being able to generate random addresses, which is conformant to specs. If the WAN interface was assigned an IP via SLAAC, like it seems to be in your case, privacy extensions should work, if enabled.

So, for the SLAAC case, there is no need to invent anything. If someone actually wanted to enable such a feature for the DHCPv6 case, it would be needed to change the (static) DUID and try to get another WAN IPv6 with that DUID. I think it should be the DUID and not the MAC, because that is be the standard way of doing it, let alone service bindings and firewall rule changes.

That being said, I did not look into it, because it would apply only to the WAN interface, and thus only to traffic generated from or directed at OpnSense itself. Your IPv6 clients are free to choose any IPv6 from their interface prefixes via SLAAC, anyway. And for inbound traffic (say, to a reverse proxy), a static IPv6 would be preferable, as well. Matter-of-fact, somehow, that traffic must be able to reach the WAN interface anyway, so you would even have to announce it via DNS.

In short:

a. This is not an OpnSense bug, but conformant to standards.
b. No feature request was posed on Github.
c. Its merits are highly debatable.

If you really want to hide your identity, use a VPN.

Too little information given here. Sounds like a router-behind-router setup. See this, especially points 1, 4 and 16.

And BTW: There is no such thing as "lo0 routing".