Messages

1

German - Deutsch / Re: DrayTek Vigor 167: Uhrzeit aktualisieren

« on: May 06, 2024, 05:41:54 pm »

Dann möchte ich mir aber noch einen kleinen Hinweis erlauben:

So ganz umsonst war Deine Arbeit trotzdem nicht. Es lesen ja auch noch andere mit, und das war sehr hilfreich. 

Ich hatte nämlich bisher gedacht, das ist schwierig, und ob das Modem die richtige Uhrzeit hat, ist mir eigenlich auch egal, deshalb hab ich mich darum bislang nicht gekümmert.

Grüße, chris

2

German - Deutsch / Re: Download Geschwindigkeit sehr langsam

« on: December 08, 2023, 02:44:28 pm »

Ich würd erst mal genauer gucken, also per SSH einloggen, Web GUI schließen, Speedtest laufen lassen und mit

Code: [Select]

top -aSH gucken, ob wirklich ein Kern überlastet ist und wie sich das so verteilt.

Bei System / Settings / tunables:

Code: [Select]

net.isr.bindthreads Bind netisr threads to CPUs. boot-time 1
net.isr.dispatch netisr dispatch policy runtime deferred
net.isr.maxthreads Use at most this many CPUs for netisr processing boot-time -1
ausprobieren und gucken, ob Besserung eintritt, ist  meiner Meinung nach immer einen Versuch wert.

Ggf. auch die Meltdown/Spectre Mitigation ausschalten, braucht auf einem Heim-Router kein Mensch.

Grüße, chris

3

German - Deutsch / Re: Web-GUI schickt Pakete auf falschem Interface raus

« on: December 06, 2023, 03:33:37 pm »

Das könnte an der Firewall Regel liegen, die den Zugang WAN in erlaubt, da gibt es unten bei advanced eine option reply-to oder so ähnlich, da könnte es bei Multi WAN Probleme geben, daß da das richtige Gateway steht, falls nicht default ausgehend verwendet werden soll.

Grüße, chris

4

German - Deutsch / IPv6 mit SIP/UPD: MTU Probleme mit Fragmenten

« on: December 03, 2023, 03:14:30 pm »

Code: [Select]

                WAN                  WAN
                 :                                 :
                 : FTTH                            : vtnet0 (MTU 1500)
                 :                                 :
             .---+---.                        .----------.
        WAN1 | GPON  |                        | OPNsense |
             '---+---'                        |     2    |
                 |                            '----+-----' 
        PPPoE1   | (MTU 1492)                      |
                 |      .----------.        wg1    | (MTU 1412)
                 +------| OPNsense | - - - - - - - +
                        |     1    |
                        '----+-----' 
                             |
                         LAN | (MTU 1500)
                             |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-------------+-----...
                     (Clients/Servers)     |
                                     (Freeswitch Server)


Obige Konfigruration mit der OPNsense 2 auf einem VServer, um fixe IPv6 Adressen zu bekommen. Das Problem ist, daß eingehende Telefonate meistens nicht ankommen, sondern auf der OPNsense 2 hängenbleiben. Alles per IPv6, SIP über UDP.

Packet capture auf OPNsense 2 zeigt, daß der INVITE vom SIP Provider ankommt und zwar in der Regel als fragmentiertes UPD Paket z.B. mit 1500 + 100 Bytes Länge. Dann schickt OPNsense 2 ein ICMP packet to big mit MTU 1412 an den SIP Provider was ja auch korrekt ist für den Wireguard Tunnel nach OPNsense 1. Der SIP Provider schickt dann den INVITE nochmal in 1412 + 188 Bytes Fragmenten. Soweit ok, aber OPNsense 2 antwortet wieder ICMP packet to big mit MTU 1412. Das wiederholt sich ein paar Mal bis der SIP Provider aufgibt.
Was läuft da schief?

Wenn ich als Workaraound den SIP Provider auf TCP statt UDP umstelle, funktioniert alles.

Ich hab mir dann mal die scrub Regeln auf OPNsense 2 angeguckt:

Code: [Select]

# pfctl -s rules | grep scrub
scrub on wg1 all fragment reassemble
scrub on vtnet0 all fragment reassemble
und es fällt auf, daß da nicht scrub in steht, also auch ausgehend scrub mit fragment reassemble angewendet wird.
Was soll das bezwecken?

Ich hab dann mal folgendes probiert:

Code: [Select]

# pfctl -s rules | grep scrub
no scrub out on wg1 all
scrub on wg1 all fragment reassemble
scrub on vtnet0 all fragment reassemble
und das funktioniert: nach dem ersten ICMP packet to big werden die korrekt fragmentierten UDP Pakete weitergeleitet.

Wo liegt hier eigentlich der Fehler, oder übersehe ich was wesentliches?

Grüße, chris

5

German - Deutsch / Re: PPPOE WAN Upload Geschwindigkeit

« on: November 26, 2023, 11:56:19 am »

Die CPU ist sicher nicht die schnellste, aber wenn 300 Mb down funktionieren sollten auch 100 Mb up gehen, denke ich.

Wie wird denn gemessen? Könnte es ein MTU Problem geben, daß evtl im Upload fragmentiert wird? Ist es mit IPv4 und IPv6 identisch?

Grüße, chris

6

German - Deutsch / Re: NAT Port Forward durch VPN zum Webserver

« on: November 13, 2023, 06:20:06 pm »

Bei dem Setup spielt die MTU/MSS eine große Rolle. Durch den Wireguard Tunnel haben die Pakete mehr Overhead.

Hier muss auf beiden seiten MSS TCP Clamping passieren, ansonsten funktioniert z.B. SSH oder HTTPS nicht.

Nur zum Verständnis gefragt: Warum eigentich funktioniert die path MTU discovery nicht? Natürlich könnte es langsamer sein weil die Verhandlung zu Beginn der Verbindung länger dauert oder Pakete fragmentiert werden, aber durchkommen sollte es nach meinem Verständnis schon.

Grüße, chris

7

German - Deutsch / Re: Alle Öffentlichen IPs aus dem gleichen Subnetz zeigen wieder auf mich selber.

« on: November 13, 2023, 06:16:29 pm »

Ich glaub nicht, daß die Provider config kaputt ist, es könnte ja wirklich so sein, daß das lokal am WAN so funktioniert.

Wie sieht es denn mit Ping aus, geht das zu deinem Kumpel durch? Nicht daß da eine zu großzügig greifende NAT reflection Regel oder sowas auf Deinen eigenen Webserver bei Dir zeigt?

Grüße, chris

8

German - Deutsch / Re: Router und OpnSense ohne NAT

« on: November 13, 2023, 05:35:35 pm »

Fritzbox eine Route àla 192.168.70.0/24 via 192.168.84.2 bekommen hat

Tippfehler oder Problem 192.168.84.2?

Ansonsten weiß ich nicht, ob man auf der Fritzbox Packet Capture hat, mal gucken ob die ICMP Pakete ankommen und wo sie hingehen.

Grüße, chris

9

German - Deutsch / Re: Port Forward funktioniert nicht; nginx DataStream funktioniert

« on: September 16, 2023, 04:24:58 pm »

Die Filterregel auf dem WAN Interface, die die eingehende Verbindung erlaubt, hat die unter "Advanced features" reply-to das entsprechende Interface gesetzt?

Vielleicht muß die Filterregel manuell eingerichtet werden anstatt der automatischen.

Grüße, chrs

10

German - Deutsch / Re: Port forward über OpenVPN Tunnel Problem

« on: September 13, 2023, 06:51:20 pm »

Beim letzten Post ist mir gerade die Idee gekommen: Die Filterregel eingehend auf dem VPN Interface ist der Kandidat, hier muß unter Advanced features: reply-to  das VPN Interface gesezt werden. Die Filterregel wird nach der redirection Regel bearbeitet und reply-to stand natürlich auf default.

Jetzt funktionierts, nachdem ich drei Abende damit verbracht habe zu verstehen, was passiert. 

Nochmals Danke fürs mitdenken,

chrs

11

German - Deutsch / Re: Port forward über OpenVPN Tunnel Problem

« on: September 13, 2023, 06:34:03 pm »

Ja, das Gateway ist eingerichtet, Upstream ist angekreuzt.

Bei Firewall: Rules: LAN hab ich das passende Gateway ausgehend:

Code: [Select]

PASS IPv4 TCP/UDP 192.168.44.51 * * * PORTUNITYVPN_VPNV4 * Mail auswaerts

Aber die Regel greift hier auch nicht, die ist nur für ausgehende Verbindungen zuständig.

Eingehend greifen nur die Filterregel auf dem VPN Interface, die Port25 nach außen öffnet, und die forward Regel.

Trotzdem, Danke fürs mitdenken!

12

German - Deutsch / Re: Port forward über OpenVPN Tunnel Problem

« on: September 13, 2023, 05:41:55 pm »

Der Mail Sever get über ovpnc1 nach draußen. Diese Regel habe ich bei Firewall: NAT: Outbound stehen:

Code: [Select]

PASS PortunityVPN 192.168.44.51/32  * * * PortunityVPN address * NO Mail OUT 
Das funktioniert ja auch. Ich kann Mail versenden. Aber diese Regel greift nicht für die Pakete ausgehend einer eingehenden Verbindung. Leider.

13

German - Deutsch / Port forward über OpenVPN Tunnel Problem

« on: September 13, 2023, 03:35:01 pm »

Guten Tag,

ich habe das Problem, daß ein port forward zu einem lokalen Recher (Mailserver) nicht funktioniert, wenn die Verbindung über einen OpenVPN Tunnel reinkommt:

Code: [Select]

                WAN                      WAN
                 :                        :
                 : Glasfaser              : DSL-Provider
                 :                        :
             .---+---.                 .--+--.
        WAN1 | GPON  |     Modems      | DSL | WAN2         WAN
             '---+---'                 '--+--'              :
                 |                        |                 :
        PPPoE1   |                        | PPPoE0    ( OpenVPN-Provider )
                 |      .----------.      |                 |
                 +------| OPNsense |------+                 |
                        |          | - - - - - - - - - - - -+
                        '----+-----'                 ovpnc1
                             |
                         LAN | 192.168.44.0/24
                             |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-------------+-----...
                     (Clients/Servers)     |
                                     192.168.44.51 (Mail Server)

Entsprechende NAT und Port forward Regeln hab ich eingerichtet.
Der Tunnel funktioniert ausgehend ohne Probleme. Die eingehende Verbindung auf ovpnc1 kommt auch beim Mailserver an, aber die Antwort Pakete werden über pppoe1 (default gateway) gesendet. Damit scheitert der TCP Verbindungsaufbau; kann man per Packet Capture sehen.

Zum Vergleich hab ich testweise ein port forward  für pppoe0 eingerichtet, das funktioniert. Im GUI sehen die Regeln identisch aus, wenn man die erzeugten Regeln anguckt, ist da ein Unterschied: beim VPN fehlt das replay-to, ich vermute hier die Ursache.

Aber warum? Und wo liegt der Fehler?

Danke für jeden Hinweis!

14

German - Deutsch / Kein IPv6 (statisch) nach Update auf 23.1.7_3

« on: May 14, 2023, 04:45:52 pm »

Guten Tag,

ich hab gerade von 22.7 letzte Version auf 23.1.7_3 upgedatet und hab seitdem keinen IPv6 traffic  mehr.

An der Konfiguration wurde nichts geändert seit Jahr und Tag. Vom Provider tal.de hab ich eine statisches /48 Netz.

Die Gateways für ppp und für V6 sind grün online. Im Firewall log tauchen die Pakete von intern auf, ich weiß echt nicht wonach ich jetzt suchen soll.

Grüße, Chris

1. Nachtrag: Ich hab mir mal die Routen angeguckt. Komisch finde ich die zweite IPv6 route auf lo0; und ist das normal das keine default route für IPv6 vorhanden ist?

15

German - Deutsch / Re: VoIP/NAT mit Asterisk

« on: November 19, 2018, 01:06:54 pm »

re-register alle 75s

Nur mal als Versuch: was passiert wenn Du den re-register auf 60s setzt. Ich meine mich zu erinnern, der UPD timeout ist 60 Sekunden.