Messages

...with no karma anymore?

If some sites work and some do not, there must be something off. Try to narrow it down, like IPv4 vs. IPv6, DNS vs. routing and so on.

There is a site with many different tests: https://ipv6-test.com/

@vortex111: Since this is your first post and you have set up a bridge: Did you set the bridge tuneables?

See #2 here.

When both of those protocols are slow upstream, it seems like the BDP is high on your connection. You could use traffic shaping or try disabling "Optimize connection buffer size" there. This is explained here.

For starters, you will have to wait until most backbone providers support that. On page 12 of the underlying paper, this is clearly stated:

L4S requires two parts to work: 1) senders and receivers with L4S-capable congestion control in the
application; and 2) L4S AQMs and isolation mechanisms deployed in the bottleneck node(s) on the
end-to-end path within the network. It is not sufficient to have only one of these two parts. Application
providers and network operators, therefore, each hold one half of the key to enabling the performance
benefits of L4S.

Part of this is that ECN bits be transferred from end to end.

So, while it is nice to see that there will be progress on this by incorporating it into widely deployed platforms like FreeBSD, there is yet little benefit to support it in OpnSense - apart from lab setups, that is, but these do neither suffer from high latency nor packet loss or congestion unless synthetically induced.

Apart from that, OpnSense usually is neither a client nor a server, only a router - apart from cases where it hosts a forward or reverse proxy. As a router it just forwards packets and has little impact on timing (modulo traffic shaping).

Have you tried using more than one stream (iperf -P8)?

[s]

Maybe a too obvious question to ask, but did you notice the the blue note here?

To be more specific: What signatures did you download that include the EICAR test signature? You can check under "Services: ClamAV: Configuration".

After I made sure that signatures were loaded, Squid was restarted after having applied all settings and specifically enabled inspecting SSL traffic as well (because the test file is on https://pkg.opnsense.org/test/eicar.com.txt), I got this (I used no transparent proxy, but explicit client settings and no additional web filters):

Well, at least they are behind SOME interface connected to OpnSense. You could add a bypass rules like this one:

You seem to misunderstand something here: Most of the users here try to help one another and are not Deciso employees - that includes Patrick, so he has nothing to be defensive about.

I see this is at least the second time you are defensive and seem to know everything. You have made a posting about the same thing about a year ago, remember?

If there really is a bug, we need to be able to recreate that in order to verify, yet you gave no hints on what you did exactly, including exact order of rules and such. Guessing from what I know and what can be publicly seen (you know, OpnSense is open source?), there is no backdoor in OpnSense.

Thus, the assumption that you did something wrong is a possible alternative, but up front, you say "Don't tell me it's MY mistake"? Alrighty then. So, wiseguy, go ahead and find someone else to solve your problem - I am outta here and I bet Patrick is, too.

P.S.: You can buy the business edition of OpnSense or pay Deciso for support. I doubt that they will accept your attitude, though.

You may find it worth reading this.

There are many setup instructions for Hetzner that show a single-IP setup, but they rely on routing because of the limitation you just found. Routing in turn has the implication that your outbound NAT will get fairly complicated (as the OpnSense WAN IP is not the "real" IP any more).

Therefore, you should consider having at least two IPv4s, one specific for a separate MAC on the WAN ip of your OpnSense.

This is unfortunate in that the IPv4 of your Proxmox host will probably not be used at all for security reasons. You could also switch MACs and use the "official" MAC for OpnSense, but that would mean that when you use a rescue system, the former OpnSense IP will then be the rescue system IP, which I find confusing.

You obviously did not get my point (or I did not get yours): You can choose on what interfaces you enable IPS. Each interface corresponds to one of your subnets, so you can choose which subnets IPS acts upon.

So what are you missing that should be added?

I can almost guarantee you that there will be no fix unless someone reports a bug on Github. I do not use that feature, so I won't.

There seems to be no processes using up all the CPU. Lighthttpd is fine. I do not know what that configd process does.

I only see that you use netflow and a captive portal, maybe you should disable them to see if that fixes the problem. With Netflow, I have seen database corruptions that repeatedly hogged the CPU. There is a button to reset the netflow data, or you can disable that altogether.

[Not the same here: Maximum valid lifetime is 7d instead of 1d (Windows 11 Pro).]

Yes, rebooting the clients this time did reset the tempory IP.  Not sure why rebooting OPNsense the other day did not do it.

That seems to answer the question, obviously OpnSense does nothing different after some time has passed, since the client behaviour changes when you reboot them.

This begs the question of lowering the lifetimes and seeing what exactly is the problem.

Code Select Expand


root@firewall:~ # cat /var/etc/radvd.conf
# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface vlan0.1 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        prefix 2601:xx:xxxx:xxx1::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS fd83:cc80:4fc3::1 {
        };
        DNSSL home.arpa {
        };
};
# Generated RADVD config for manual assignment on opt2
interface vlan0.20 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        prefix 2601:xx:xxxx:xxx2::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS fd83:cc80:4fc3::1 {
        };
        DNSSL home.arpa {
        };
};
# Generated RADVD config for manual assignment on opt3
interface vlan0.30 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        prefix 2601:xx:xxxx:xxx3::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS fd83:cc80:4fc3::1 {
        };
        DNSSL home.arpa {
        };
};
# Generated RADVD config for manual assignment on opt4
interface vlan0.40 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        prefix 2601:xx:xxxx:xxx4::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS fd83:cc80:4fc3::1 {
        };
        DNSSL home.arpa {
        };
};
# Generated RADVD config for manual assignment on opt5
interface vlan0.50 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        prefix 2601:xx:xxxx:xxx5::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS fd83:cc80:4fc3::1 {
        };
        DNSSL home.arpa {
        };
};


Not quite the same as mine, but the difference should not matter (all "Stateless", "Unmanaged" and "Assisted" should work the same):

Code Select Expand


# Generated RADVD config for manual assignment on opt8
interface igc1_vlan5 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        AdvManagedFlag off;
        AdvOtherConfigFlag on;
        prefix 2001:xxxx:xxxx:xx05::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS 2001:xxxx:xxxx:xx05:yyyy:yyyy:yyyy:yyyy {
        };
        DNSSL dmz {
        };
};


P.S.: It seems normal that the clients do not issue a new RS when they set a new temporary IPv6 [...]

Excellent!  Thank you for corroborating that observation.

The clients normally just do the prolongation after the preferred lifetime has ended. They do not send another RS, but they probably should do NS to avoid a duplicate address (DAD). This is something you should be able to observe when you lower the lifetimes. I would guess that something here is the problem.

Code Select Expand


>netsh interface ipv6 show privacy
Querying active state...

Temporary Address Parameters
---------------------------------------------
Use Temporary Addresses             : enabled
Duplicate Address Detection Attempts: 3
Maximum Valid Lifetime              : 1d
Maximum Preferred Lifetime          : 1d
Regenerate Time                     : 5s
Maximum Random Time                 : 10m
Random Time                         : 6m38s


There is a formula for this in RFC 8981 section 3.8:

Not the same here: Maximum valid lifetime is 7d instead of 1d (Windows 11 Pro). But still, I would focus on Linux, because it is easy to lower the lifetimes and try there.

Code Select Expand


Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0xe1ed [correct]
    [Checksum Status: Good]
    Cur hop limit: 64
    Flags: 0x00, Prf (Default Router Preference): Medium
    Router lifetime (s): 1800
    Reachable time (ms): 0
    Retrans timer (ms): 0


Therefore, the formula can be reduced to just

2 + (0) = 2s

So I guess this it, in theory?

I doubt that, because:

#tcpdump -i eth0 -X -vvvv -ttt icmp6 and 'ip6[40] = 134'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
 00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) _gateway > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 112
        hop limit 64, Flags [managed, other stateful], pref high, router lifetime 1800s, reachable time 0ms, retrans timer 0ms

Those zeroes for "reachable" and "retrans" also only mean "not specified".


So, no VLANs or VMs interfering with ICMPv6.

I use Unifi equipment here, too, but I have no L3 switch that I am aware of. Theoretically, it is possible that this interferes (via RAs or filtering of ICMPv6 messsages). Alas, if you have a router-on-a-stick, you cannot try to connect something otherwise.

The subnets correspond to logical interfaces (= VLANs). See this: