Messages

Hi guys,

I had a couple of month ago this thread here and today I had the time to dig more into it.
My goal is that of my WAN connection (190 MBit/s down, 35 MBit/s up) some interfaces can only consume background traffic. Two queues (100/1).
This works pretty well as long as the pipe is configured smaller or equal than 40 MBit/s. Beyond that value the de-prioritized queue (1) catches up and at ~80 MBit/s the bandwidth is distributed equally.

Is there any chance to get this working beyond this magical 40 MBit/s?

Thanks Stefan

Guys,

it is shit peering of DTAG which is well known for decades now and will last until the end of the universe. The internet is full of that and it will never change.
So if you want a good overall internet experience you should pick any DSL provider except DTAG

Schade, dass du meine Frage einfach ignorierst, so kann man dir leider nicht helfen.
Hier aber zum Schluss noch ein paar Tipps:

1. Wireguard ist kein chatty protocol. D.h. Im Dashboard kann die Tunnelanzeige nur grün werden wenn auch Daten fließen. Ein reines vorhandensein einer (gültigen) Konfiguration bedeutet nicht, dass es automatisch grün wird.
2. Die Wireguard config Seite ist etwas verbuggt. Nicht alle Änderungen führen mittels Apply zu einer (korrekten) Änderung on the fly. Das lässt sich mit wg show gegenprüfen bzw. Im Zweifelsfall reboot.
3. Mit deiner /32 AllowedIPs config würde ping nur von einer opnsense Instanz zur anderen funktionieren, aber nicht aus anderen Subnetzen. Leider unklar was du probiert hast.
4. https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html

Viel Glück!

Von welcher IP hast du versuchst welche zu Pingen?

Hab ich nicht daran gedacht, dass es so wichtig ist, da ich ja die wichtigen Infos gegeben hab, glaubte ich zumindest  ::)
Also in "ALLOWED IP's" sind die Pub-IPv4 nicht eingetragen, da ich gedacht habe, der Tunnel geht von WG1 zu WG2 und es ist egal was dazwischen ist. Hab es aber geändert und funktioniert ebenso nicht.

Die public IP brauchst du nicht in AllowedIPs, macht denke ich auch keinen Sinn. Er würde dann den traffic zur public IP durch den Tunnel schicken, hat aber nichts damit zu tun, dass der Tunnel generell erreichbar ist.

Wireguard soll in der OPNsense laufen und mit dem Handy kann ich ja auf beiden Seiten zugreifen.
Das Problem liegt aber darin, dass dieser Tunnel zwischen WG1(Zu Hause) und WG2(Rechenzentrum) gar nicht zustande kommt. Daher sind ja die Allowed IPs noch nicht interessant oder?

Wie genau ermittelst du, dass der Tunnel nicht zustande kommt? Weil ohne Keepalivekonfiguration und ohne traffic gibt es auch keinen handshake zwischen den endpoints.

Allowed IPs: 192.168.99.2/32 im Rechenzentrum bedeutet, dass er nur an das Subnetz 192.168.99.2/32 Pakete durch den Tunnel routed und nur von dem Subnetz 192.168.99.2/32 Pakete akzeptiert. Ich vermute mal, dass ist nicht das, was du willst, da z.b. alles aus  192.168.2.1/24 was ja anscheinend dein lokales Netz ist gedropped wird.

My current ISP doesn't have a 24h disconnect, but this may change in the future.
To check how well Opnsense can deal with it I enabled the 'Periodic reset interface' cron on the dial-in connection.

What shall I say, it panics at around 50% chance.

Haven't changed anything related to traffic shaping except installing updates. It's working again.

Wahnsinn, als ich letztes Jahr von Magenta Entertain auf Magenta Superstream umstellte, was letztlich nur bedeutete, dass Netflix dazukommt, hat das über eine Woche gedauert.

Ich fasse mal zusammen:
Der Tunnel wird über GUA IPv6 aufgebaut. Der Tunnel an sich funktioniert, aber andere IPv6 die global gerouted werden sollen gehen nicht?

Auffällig bei deiner Wireguard Konfig ist, dass du als DNS den Remote eingetragen hast. Ist das beabsichtigt, dass die DNS Requests. Ist das beabsichtigt?

Geht IPv6 Konnektivität generell, also z.B.:

Code Select Expand


ping 2001:4860:4860:0:0:0:0:8888


Kannst du mal die wireguard config posten? Vor allem interessant sind:
Address
DNS
MTU
AllowedIPs

und mal einen Screenshot der IP Konfiguration + Routingtabelle posten?

Die deny Regel macht eigentlich keinen Sinn, zumindest wenn du die match-first Standardeinstellung hast, Weil dann matched er immer die DSL Gateway Regel und die deny nie.
Mach mal bitte Screenshots wie deine Firewall Regeln jetzt aktuell aussehen mit Detailscreenshot zur Hetznerregel + Info wie der Hetzneralias konfiguriert ist.

Firewall - NAT - Outbound
Static port rule für die Fritte konfiguriert?

Das war das einzige was ich extra für den gleichen use-case konfigurieren musste.

Wildcard SSL Zertifikat + Reverse Proxy der per default eine statische Seite ausliefert.
99,99999% dieser "Angriffe" machen Requests auf die IP Adresse und schlagen fehl, weil dort nur die statische Seite ausgeliefert wird.
Alle Subdomains sind dann "privat", d.h. man erreicht den Dienst nur wenn man die Subdomain kennt.

Wo ist mein Fehler?

Firewall- Advanced - Settings

Skip rules when gateway is down.

Wenn du ein spezifisches Gateway erzwingen willst musst du das aktivieren, ansonsten geht er dann über das default gateway was im Fehlerfall LTE ist.