Messages

None/ACPI means "ACPI only" - but ACPI is included on top of both the AMD and Intel core temp sensors, so if there is nothing shown with either one enabled, there will still be nothing with None/ACPI.

Aus Deinen Angaben wird immer noch nicht klar, was Du eigentlich erhältst:

IA_NA?
IA_PD? Wenn ja, mit welcher Präfix-Länge? /56, /64 oder gar nicht?

Beachte auch, dass manche Provider nur Präfixe aushändigen, wenn man "Request prefix only" anhakt, siehe: https://forum.opnsense.org/index.php?topic=45822.0

Am Rande bemerkt, müsste der Provider und nicht die RegTP die Anschlussdaten bereitstellen. Offenbar ist der ISP aber so rigoros, dass er auch nicht sagt, wie man beispielsweise mit einer Fiber-Fritzbox oder sonstigem eigenen ONT arbeiten kann - und dass muss er, weil Endgerätefreiheit != Routerfreiheit. Wenn Du also aus dem Vertrag raus willst...

Take a look at this, point 23.

As expected (but with the community edition):

You cannot view this attachment.

I neither use the business edition nor have I monitored the size of the Ipinfo database over time. I use it with the community edition and for me, it works:

Code Select Expand

# wc /usr/local/share/GeoIP/alias/BE-IPv?
    9736    9736  158563 /usr/local/share/GeoIP/alias/BE-IPv4
   24323   24323  566429 /usr/local/share/GeoIP/alias/BE-IPv6
   34059   34059  724992 total

# fgrep ,BE, ipinfo_lite.csv | wc
  34059   64340 2112133

Seems like there is some kind of extraction process from the Ipinfo CSV that failed to generate all entries, maybe because of a subtle syntax error in the CSV. For example, I find this line inside the CSV:

Code Select Expand

2a14:3d02::/35,Belgium,BE,Europe,EU,AS57234,"LLC ""IT NETWORKS CHAT""",ichatua.com.ua

Note the multiple quotes. Also, there are missing ASNs in some lines. So maybe this is a parsing error within OpnSense code, but probably in the business edition only?

Hi Fabian, I think the problem is the road warriors (as they do not notice the IP change of your server).

I wrote the stale connection job and of course, it only does half of the job...

Wireguard is inherently symmetrical, such that when a potential connection exist, both peers will send handhakes. If one side changes its IP, the other side will lose contact, but it can still try to reach the other side - this is normally true with a site-2-site connection, including new DNS resolution.

Thus, it is usually beneficial if one side (the server, so to speak) has a fixed IP, because it will always come up on that IP and can be reached regardless. The cron job fixes a lot of thing when both site-2-site partnes are behind dynamic IPs and both use the job. In that case, regardless of who is changing its IP, the other side will notice that the last handhake was older than 135 seconds and re-initiate the connection.

This can take a while, depending on how fast the DynDNS updates are and may be neccessary multiple times.


In your scenario, with a road warrior, the cron job on the "server" side does not help at all, because the road warrior peer has to initiate a new connection. If he fails to notice the stale connection, it will never restart and thus the DynDNS update will go unnoticed.

Luckily, for M-Net, there is a fix to that: They usually do not change their IPv6 prefix on reconnection, much unlike the IPv4. Thus, if you use IPv6 only or IPv6 and IPv4 in your DynDNS, it will effectively work as if you have a fixed IP(v6). In that case, your roadwarrior clients will regain contact within the same Wireguard session.

Call me any time if you have questions, you have my number!

Not quite. Obviously, you can currently use an MTU of 1492 bytes only according to your tests. That I read from your previous posts and it hold true unless you succeed in applying the method explained here to enlarge that WAN MTU to 1500 bytes. In order to do that on a Proxmox VM, the whole chain ISP -> physical NIC -> Proxmox bridge -> OS NIC -> OS VLAN -> OS PPPoE WAN Interface must be configured right and capable to support 1500 bytes MTU on the WAN interface.

Without that, at least on the WAN side, you obviously need a 1492 bytes MTU, probably because of PPPoE involved in your WAN setup.

From there, you have two options:

1. Use a LAN MTU of 1500 bytes and employ MSS clamping (Firewall: Settings: Normalization) to adapt the mismatch of WAN vs. LAN MTU.
2. (Better) Use a LAN MTU of 1492 bytes, too.

AFAIK, the business edition uses IPinfo per default, if not configured otherwise.

In theory, MSS should be set to MTU-40, but OpnSense does some trickery with the input value, so I would not set it at all.

Korrekt. Ganz safe wären 1488. Die Telekom erlaubt tatsächlich 1500 Bytes plus VLAN Tag abzüglich PPPoE - wie heutzutage die meiste Netzwerk-Hardware auch.

Die Bemerkung mit der Erhöhung der Proxmox-Payload bezieht sich darauf, dass man das tun muss, weil sonst die virtio-Karte auch auf 1500 Bytes plus VLAN beschränkt ist, nämlich als Antwort hierauf:

https://forum.opnsense.org/index.php?msg=257341

Wenn wir schon spitzfindig werden:

"Meistens" - nicht bei allen ISPs, die Telekom ist ein gutes Beispiel, sonst bräuchte es ja die Reduktion auf 1492 Bytes MTU dort nicht.

Und ja, es ist richtig, dass nach der Einführung von 802.1q die Hersteller dafür gesorgt haben, dass die VLAN-Tags noch zusätzlich zu den üblichen 1500 Bytes passen. Das war aber nicht immer so, z.B. vor Einführung von 802.1q und außerdem stimmt das spätestens nicht mehr, wenn man dann QinQ macht, das ist nämlich NICHT einkalkuliert.

Klar, es kann funktionieren, weil manche moderne Netzwerkhardware sogar Frames bis 9014 Bytes unterstützt, ich habe das aber im Guide so beschrieben, dass es IMMER funktioniert (gesetzt den Fall, dass Mini-Jumbo-Frames auf der ISP-Strecke auch gehen).

Mal ganz abgesehen davon, dass OpnSense auch noch ein paar Glitches hat bei der automatischen Berechnung von MSS usw. aus den gegebenen Werten. Deshalb rate ich dazu, die Werte explizit zu setzen und eher zu hoch als zu niedrig. Und dann: Nicht glauben, sondern testen - deswegen gibt es das Tool.

Actually, it would also work for disk cloning on physical installs which often becomes neccessary with cheap SSD disks or when replacing them with larger ones. IMHO it should probably be the default. I can only imagine exotic cases where it would not work as intended, like when somebody wants to leave room on the disk for another OS. There was a case just these days, but I wonder who needs OpnSense other than as a 24/7 appliance?

gibt es eine beschreibung wie man das macht leider kein erfahrung,

Wie immer, in der Tutorial-Sektion: https://forum.opnsense.org/index.php?topic=36936.0 oder auch hier, Punkt 11.

You probably used something like this: https://github.com/FingerlessGlov3s/OPNsensePIAWireguard to do this.

If so, that means you added non-standard functionality to OpnSense, including scripts that are probably still being called and creating configurations on-the fly via cron or other means. If you cannot undo these modifications, your best bet would be to save your configuration, reinstall and import your configuration again in order to restore system state.

Just made it into the HOWTO, thanks @Maurice!