Test Fritzbox als Wireguard peer

[hoitschau]

Hallo Zusammen

Ich hab mir eine Fritzbox 6850 LTE zugelegt um Wireguard zu testen (neueste Labor Firmware).
Und nach einigen Tests musste ich nun einen Account in diesem Form anlegen, freut mich hier zu sein.
Natürlich hab ich nun auch eine Frage.

Folgendes Szenario:
OpnSense Firewall als Wirguard Server
LAN 192.168.0.1/24
WG Interface 10.0.5.1

Fritzbox (WG Benutzerdefinierte Einrichtung, WG auf Gegenstelle erstellt)
WG 10.0.5.11
Netzwerk 192.168.1.1/24

Der Wireguard-Tunnel baut auf und funktioniert auch, aber es scheint als funktioniert nur eine Richtung.
Aus dem Netz der Fritzbox erreiche ich alle Client im Netz der OpnSense mit allen Protokollen und erhalte auch Antwort.

Versuche ich nun aber aus dem Netz der OpnSense auf die Fritzbox oder die Clients dahinter zuzugreifen,
scheint das Wireguard Interface der Fritzbox die Pakete zu blockieren.
Ausser Ping, das scheint mehrheitlich zu funktionieren, aber nicht immer.
Linux Client hinter OpnSense pingt Fritzbox
10.0.5.11 ok
192.168.1.1 ok
Client hinter Fritzbox 192.168.1.41 ok

Windows Client hinter OpnSense pingt Fritzbox
10.0.5.11 ok
192.168.1.1 nicht ok
Client hinter Fritzbox nicht ok

Andere Protokolle scheinen immer geblockt zu werden:
curl http://192.168.1.41:80/
Wenn ich das Tracefile richtig interpretiere wird schon der TCP-Handshake vom Wireguard Interface der Fritzbox 10.0.5.11 geblockt.

Ein weiteres komisches Verhalten ist, dass die Fritzbox trotz Eintrag 0.0.0.0/0 nicht allen Traffic über das Wireguard Interface routet.
www.wieistmeineip.ch zeigt die IP des LTE Interface, somit läuft die http Anfrage über LTE.

Hat jemand dieses Setup schon getestet?
Kann man da noch was konfigurieren?
Ist es möglich Traffic ausserhalb des Tunnels zu blocken wie in den Wireguard Clients?

Ist für andere FritzBoxen das neue FritzOS schon erhältlich, und reagiert Wireguard dort anders?

Würd mich über Rückmeldungen freuen.
Grüsse hoitschau

 

[blurrrr]

Linux Client hinter OpnSense pingt Fritzbox
10.0.5.11 ok
192.168.1.1 ok
Client hinter Fritzbox 192.168.1.41 ok

Windows Client hinter OpnSense pingt Fritzbox
10.0.5.11 ok
192.168.1.1 nicht ok
Client hinter Fritzbox nicht ok

Hi,

also ich denke nicht, dass es einen Unterschied bei den Clients macht (ausser Netzwerk ist falsch ausgewählt/Firewall verzockt), oder die Clients hängen in verschiedenen Netzen. Wenn ein Ping durchgeht, wird es sicherlich an den Firewall-Regeln der pfSense liegen (bei der Fritzbox ja wohl eher nicht, da ist ja nicht viel zu konfigurieren soviel ich weiss).

Da man an so einer Fritzbox auch nicht groß rumkonfigurieren kann, ausser man erstellt händisch die Configs und schubst sie dann auf die Fritzbox (bzg. IPSec-VPN z.B., k.A. ob das bei WG überhaupt funktioniert), hat man da sowieso nicht soviele Möglichkeiten... Von daher ist es essentiell die Logs stets im Auge zu behalten, die der pfSense, aber auch - sofern da überhaupt irgendwas auftaucht - die der Fritzbox. Auszüge mit ggf. Fehlermeldungen wären ja mal interessant, oder eine Routing-Tabelle der pfSense (bei eingewähltem VPN).

Aber so oder so bin ich der Meinung, dass es erstmal grundsätzlich keinen Unterschied macht, ob Du nun mit einem Linux- oder Windows-Client daher kommst (ausser die Windows-Clients sind halt irgendwie verbogen)

EDIT: Wo ich das grade so sehe....

LAN 192.168.0.1/24
Netzwerk 192.168.1.1/24

Sind doch "Netz"- und keine "Host"-Angaben, oder seh ich das falsch? Hab noch nie was mit WG zu tun gehabt, aber ich persönlich würde Netzangaben mit ".0/24" angeben (oder was auch immer die "Netz-ID" im konkreten Fall wäre).

 

[Barungar]

Ein weiteres komisches Verhalten ist, dass die Fritzbox trotz Eintrag 0.0.0.0/0 nicht allen Traffic über das Wireguard Interface routet.
www.wieistmeineip.ch zeigt die IP des LTE Interface, somit läuft die http Anfrage über LTE.

Ich bin mir nicht sicher, ob da ein Eintrag 0.0.0.0/0 in den statischen Routen der FritzBox ausreicht bzw. aus Sicht der FritzBox korrekt ist. Ohne es näher zu wissen, denke ich, dass die FritzBox intern eine default Route (mit höherer Prio) auf den eigenen Internetzugang hat.

Zumindest kennt die FritzBox diese Einstellung, die nahelegt, dass es eine "geschützte default route" gibt.

 

[blurrrr]

Hatte @tiermutter da nicht mal etwas bzgl. WG und "2" Routen (0.0.0.0/1 + 128.0.0.0/1), weil da auch irgendwas mit der Default-Route "komisch" war? Btw kann man eigentlich bei der Fritzbox irgendwo die Routen-Metriken einsehen?

 

[Barungar]

Nein, die FritzBox (so lange sie Vanilla läuft) zeigt Dir ihre Routing-Tabelle nicht. Du kannst zwar statische Routen definieren, aber ob diese dann in der Prio hochgenug stehen, kannst Du so nicht prüfen.

Der Trick mit den zwei Routen ist ein fieser Workaround, weil per Definition grundsätzlich eine spezielle Route Vorrang vor einer allgemeineren Route hat.

 

[blurrrr]

@Barungar Jo, schon klar, schäbig bleibt es trotzdem...

Ich hab mir eine Fritzbox 6850 LTE zugelegt um Wireguard zu testen (neueste Labor Firmware).

Ist ja schon nicht ohne, hab ich auch mal öfter drüber nachgedacht, aber das war mir immer zu teuer für "kurz mal testen und danach ab in die Ecke". IPsec - muss man ja auch mal sagen - funktioniert jedenfalls bzgl. Site2Site, WG ist für mich noch immer ein wenig... naja... Bastelkram, ich muss auch nicht jedem Hype hinterher rennen... Wenn das dann mal "ein paar" Versionen hinter sich hat, kann man sicherlich mal drüber nachdenken, aber "Labor"-Firmware... ne, sowas kommt mir nicht ins Haus (kann den Spieltrieb aber durchaus verstehen).

Was das hier angeht:

Der Wireguard-Tunnel baut auf und funktioniert auch, aber es scheint als funktioniert nur eine Richtung.

Das "kann" garnicht sein, denn ansonsten könnten die Pakete nicht "zurück", das Routing "muss" also schon stimmen, sobald Du in der Lage bist eine Antwort aus dem Remote-Netz zu empfangen (und die Pakete nicht nur irgendwo versanden). Ergo bleibt eigentlich nur noch eins: Firewall, aber da wiederhol ich mich

EDIT: Bis das mit WG funktioniert, kann man ja glücklicherweise IPSec verwenden zwischen Fritzbox und OPNsense

 

[hoitschau]

Danke für eure Antworten.

Die Firewall kann ich gut ausschliessen, da ich auf dem WG-Interface der Fritzbox trace, und alle Pakete dort sehe.
Bei den abgelehnten TCP-Handshake und bei den abgelehnten Ping bekomme ich die Antwort vom WG-Interface der Fritzbox 10.0.5.11.
Ich bin also überzeugt, es liegt an der Fritzbox, sonst würde ich die Pakete nicht bei der Fritzbox tracen können.

Und übrigens, wenn die Anfrage im fritzbox-Netz startet, und ich eine Anwort über den Tunnel erwarte, routet die Fritzbox die Pakete korrekt zum Client. Das spricht auch wieder gegen eine Firewall Regel.

Und sorry, bei der Angabe LAN 192.168.0.1/24 hab ich mich kurz gehalten.
Das soll heissen Interface ist 192.168.0.1, das Netz 192.168.0.0/24.

Da ich aus früheren Erfahrungen mit Wireguard schon wusste, dass die Fritzbox immer das lokale Netz zusätzlich angibt, hab ich die Konfiguration mit 0.0.0.0/0, 192.168.0.0/24 eingerichtet.
Anscheinend braucht der Windows-Client die Angabe des lokalen Netz der Gegenseite, bei Android z.B. reicht 0.0.0.0/24.
So erreiche ich ja auch alle Client im Netz 192.168.0.0/24.
Aber ich sehe momentan keine Möglichkeit, den gesamten Traffic durch den WG-Tunnel zu leiten, aber meiner Meinung nach müsste das möglich sein (Andoid-, Linux- und Windows-Clients funktionieren ja so, inkl. blocken des Traffics ausserhalb des Tunnels).

Fehlermeldungen oder Logfile-Einträge hab ich keine gefunden, ich analysiere darum jeweils effektiv den Trace des WG-Interface.

Bezüglich Beta-Status von Wireguard, meines Wissens nach ist doch das neue FritzOS für einige Boxen schon releast, oder wird bald,
und Wireguard ist dort drin. Somit hab ich angenommen, dass der Laborbetrieb schon einigermassen stabil läuft.
Die Performance von Wireguard ist halt echt genial, ich kann auf dem Smartphone per Mobilfunk ruckelfrei HD-TV von meiner TV-Karte schauen, das bekomme ich mit keiner anderen Technik hin.
Und da schlussendlich SIP über den Tunnel läuft, will ich natürlich das performanteste Protokoll nutzen.

Ich hab aber auch noch vor, IPSec zu testen, werde dazu mal noch ein update durchgeben wenn ich Zeit hatte.

Bin aber für weiteren Input dankbar, ev. finde ich so noch was raus.

 

[blurrrr]

Ohne weitere Infos wird das wohl eher nur ein "fischen im trüben"...

 

[hoitschau]

An was für weitere Infos hast du gedacht?

Meine leise Hoffnung ist, dass jemand dieses Post sieht, der das selbe Setup hat, und Bestätigen kann dass es bei Ihm glich oder eben anders reagiert.
Oder sich jemand findet der aus Interesse das mal selber testen will.

Gibt es von AVM Infos zu den aktuellen Firmware-Versionen der einzelnen Boxen?Ist die neue Version mit Wiregard schon veröffentlicht?

 

[blurrrr]

Den entsprechenden Auszug aus dem Mitschnitt (inkl. allen Header-Informationen) z.B.

 

[hoitschau]

Hab mal das meiste Angesprochene in einen Trace gepackt.
Trace auf der Fritzbox erstellt, Schnittstelle 1 ('avm-wg')

1. Windows-Client im OpnSense Netz 192.168.0.23

Paket 1-8, Ping zu IP des Wireguard-Interface der Fritzbox 10.0.5.11
Windos meint ok
Paket 9-16 Ping zu IP der Fritzbox 192.168.1.1
Windows meint Empfangen = 0

2. Linux-Client im OpnSense Netz 192.168.0.49

Paket 17-24, Ping zu IP des Wireguard-Interface der Fritzbox 10.0.5.11
ok
Paket 25-32, Ping zu IP der Fritzbox 192.168.1.1
ok
Paket 33-40, Ping zu Client im Fritzbox Netz 192.168.1.41
ok

Fazit: sorry ist mir gestern nicht aufgefallen dass das wohl ein Windows-Problem ist.

3. http request vom Client im OpnSense 192.168.0.49 Netz zu Client im Fritzbox Netz 192.168.1.41
Paket 41-49, da kenn ich mich noch zu wenig aus

4. SIP Register von Client im Fritzbox Netz 192.168.1.21 zu Client im OpnSense Netz 192.168.0.49
Paket 50-53, ok, kommunikation durch den Tunnel funktioniert beidseitig.

Fazit: während ich das so schreibe, geht mir natürlich ein Licht auf, war wohl doch schon zu spät gestern.
Ich hab vergessen auf dem LAN Interface der Fritzbox zu kontollieren, ob die Pakete wirklich nicht ankommen, wie ich vermutete.
Wurde wohl duch das Ping-Problem von Windows auf eine falsche Fährte gelockt.

Der Vollständigkeit halber, falls mal jemand anders auf das Problem stösst, im File 2 ist noch ein Trace der Schnittstelle "lan".

Paket 6-13, Ping des Windows Clients, Problem scheint nicht im Netz der Fritzbox zu liegen.
Paket 14,15,21-31, http request des Linux Clients, scheint auch anzukommen, aber vom Ziel Linux nicht korrekt beantwortet zu werden.
Ist das Ziel im selben Netz funktioniert das problemlos.

Vermutlich bin ich nun im falschen Forum, aber ev. hat jemand eine Idee was da falsch läuft?
Frage 1, warum kommen die Ping nicht im Windows an?
Frage 2, was läuft beim http request schief?

Danke für euren Input.

 

[rednag]

Du bist hier schon im richtigen Forum Du kannst die Logs gerne hier direkt -als Code formatiert- einfügen. Nicht jeder will sich ein ZIP von unbekannter Quelle runterladen um helfen zu können.

 

[hoitschau]

danke für den Hinweis, ist etwas blöd dass man hier keine pcap hochladen kann.
finde die farben im wireshark immer sehr hilfreich.

No.     Time                          Source                Destination           Protocol Length Info
     12 2022-11-09 20:07:08.366995    192.168.0.23          192.168.1.41          ICMP     74     Echo (ping) request  id=0x0001, seq=32/8192, ttl=126 (reply in 13)

Frame 12: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b), Dst: Teracom_00:bc:bf (5c:32:c5:00:bc:bf)
Internet Protocol Version 4, Src: 192.168.0.23, Dst: 192.168.1.41
Internet Control Message Protocol

No.     Time                          Source                Destination           Protocol Length Info
     13 2022-11-09 20:07:08.368335    192.168.1.41          192.168.0.23          ICMP     74     Echo (ping) reply    id=0x0001, seq=32/8192, ttl=100 (request in 12)

Frame 13: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.23
Internet Control Message Protocol

No.     Time                          Source                Destination           Protocol Length Info
     14 2022-11-09 20:07:17.894750    192.168.0.49          192.168.1.41          TCP      74     48180 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1352 SACK_PERM TSval=4093549201 TSecr=0 WS=128

Frame 14: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b), Dst: Teracom_00:bc:bf (5c:32:c5:00:bc:bf)
Internet Protocol Version 4, Src: 192.168.0.49, Dst: 192.168.1.41
Transmission Control Protocol, Src Port: 48180, Dst Port: 80, Seq: 0, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     15 2022-11-09 20:07:17.896623    192.168.1.41          192.168.0.49          TCP      58     [TCP Port numbers reused] 80 → 48180 [SYN, ACK] Seq=0 Ack=1 Win=201 Len=0 MSS=536

Frame 15: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 0, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     21 2022-11-09 20:07:18.897380    192.168.1.41          192.168.0.49          TCP      58     [TCP Retransmission] 80 → 48180 [SYN, ACK] Seq=0 Ack=1 Win=201 Len=0 MSS=536

Frame 21: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 0, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     22 2022-11-09 20:07:18.910627    192.168.0.49          192.168.1.41          TCP      74     [TCP Retransmission] [TCP Port numbers reused] 48180 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1352 SACK_PERM TSval=4093550241 TSecr=0 WS=128

Frame 22: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b), Dst: Teracom_00:bc:bf (5c:32:c5:00:bc:bf)
Internet Protocol Version 4, Src: 192.168.0.49, Dst: 192.168.1.41
Transmission Control Protocol, Src Port: 48180, Dst Port: 80, Seq: 0, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     23 2022-11-09 20:07:18.912785    192.168.1.41          192.168.0.49          TCP      54     [TCP Dup ACK 15#1] 80 → 48180 [ACK] Seq=1 Ack=1 Win=201 Len=0

Frame 23: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 1, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     24 2022-11-09 20:07:20.913034    192.168.1.41          192.168.0.49          TCP      58     [TCP Retransmission] 80 → 48180 [SYN, ACK] Seq=0 Ack=1 Win=201 Len=0 MSS=536

Frame 24: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 0, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     25 2022-11-09 20:07:20.982588    192.168.0.49          192.168.1.41          TCP      74     [TCP Retransmission] [TCP Port numbers reused] 48180 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1352 SACK_PERM TSval=4093552289 TSecr=0 WS=128

Frame 25: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b), Dst: Teracom_00:bc:bf (5c:32:c5:00:bc:bf)
Internet Protocol Version 4, Src: 192.168.0.49, Dst: 192.168.1.41
Transmission Control Protocol, Src Port: 48180, Dst Port: 80, Seq: 0, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     26 2022-11-09 20:07:20.984574    192.168.1.41          192.168.0.49          TCP      54     [TCP Dup ACK 15#2] 80 → 48180 [ACK] Seq=1 Ack=1 Win=201 Len=0

Frame 26: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 1, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     27 2022-11-09 20:07:24.985397    192.168.1.41          192.168.0.49          TCP      54     80 → 48180 [RST, ACK] Seq=1 Ack=1 Win=201 Len=0

Frame 27: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 1, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     28 2022-11-09 20:07:25.014295    192.168.0.49          192.168.1.41          TCP      74     [TCP Retransmission] [TCP Port numbers reused] 48180 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1352 SACK_PERM TSval=4093556321 TSecr=0 WS=128

Frame 28: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b), Dst: Teracom_00:bc:bf (5c:32:c5:00:bc:bf)
Internet Protocol Version 4, Src: 192.168.0.49, Dst: 192.168.1.41
Transmission Control Protocol, Src Port: 48180, Dst Port: 80, Seq: 0, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     29 2022-11-09 20:07:25.016404    192.168.1.41          192.168.0.49          TCP      58     [TCP Previous segment not captured] [TCP Port numbers reused] 80 → 48180 [SYN, ACK] Seq=0 Ack=1 Win=201 Len=0 MSS=536

Frame 29: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 0, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     30 2022-11-09 20:07:26.016936    192.168.1.41          192.168.0.49          TCP      58     [TCP Retransmission] 80 → 48180 [SYN, ACK] Seq=0 Ack=1 Win=201 Len=0 MSS=536

Frame 30: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 0, Ack: 1, Len: 0

No.     Time                          Source                Destination           Protocol Length Info
     31 2022-11-09 20:07:28.017372    192.168.1.41          192.168.0.49          TCP      58     [TCP Retransmission] 80 → 48180 [SYN, ACK] Seq=0 Ack=1 Win=201 Len=0 MSS=536

Frame 31: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Ethernet II, Src: Teracom_00:bc:bf (5c:32:c5:00:bc:bf), Dst: AVMAudio_ae:14:7b (b0:f2:08:ae:14:7b)
Internet Protocol Version 4, Src: 192.168.1.41, Dst: 192.168.0.49
Transmission Control Protocol, Src Port: 80, Dst Port: 48180, Seq: 0, Ack: 1, Len: 0

das ist der Trace "lan" Interface der Fritzbox

 

[blurrrr]

@rednag ausgeklappt wäre es etwas lang, eingeklappt nicht unbedingt aussagekräftig

@hoitschau Sag mal... wenn ich mir die Mitschnitte so anschaue... Meinst Du nicht, dass da ordentlich was schief läuft?

Schaut mal sich den "LAN"-Mitschnitt an, ist dort die Rede von 192.168."0".0/24 und 192.168."1".0/24.
Schaut man sich den "Fritzbox"-Mitschnitt an, ist dort die Rede von 192.168.0.0/24 + 192.168.1.0/24 UND 10.0.5.0/24.

Mal gedanklich davon ausgehend, dass 10.0.5.0/24 als reines Transfernetz genutzt wird, warum gibt es da ein- und ausgehende Anfragen? Sollte so eigentlich nicht sein... Schaut man sich das Schauspiel mal etwas genauer an, fällt auch folgendes auf:



Anfrage KOMMT von 192.168.0.49 und geht AN 192.168.1.41, aber die Antwort? Völlig daneben! Wenn 192.168.1.41 gefragt wird, sollte 10.0.5.11 nicht darauf antworten, oder wie siehst Du das so?

Könntest natürlich auch mal bei der 192.168.0.49 mitschneiden und sehen, wie der Client die Pakete verwirft, weil die 10.0.5.11 wurde ja nicht angefragt. Schau Dir den Trace (fritzbox-vcc) mal genauer an, wer da mit wem spricht.

EDIT: In der Kürze liegt die Würze (oder so)...:

 

[hoitschau]

Die OpnSense scheint den Ping zum Windows Client zu routen, aber wenn ich auf dem Windows Client trace kommen sie nicht an.

No.     Time                          Source                Destination           Protocol Length Info
   4050 2022-11-09 20:33:29.554175    192.168.0.23          192.168.1.41          ICMP     74     Echo (ping) request  id=0x0001, seq=42/10752, ttl=128 (no response found!)

Frame 4050: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: AzureWav_b2:c6:9d (70:66:55:b2:c6:9d), Dst: Shuttle_ef:67:da (80:ee:73:ef:67:da)
Internet Protocol Version 4, Src: 192.168.0.23, Dst: 192.168.1.41
Internet Control Message Protocol

No.     Time                          Source                Destination           Protocol Length Info
   4063 2022-11-09 20:33:29.660666    10.0.5.11             192.168.0.23          ICMP     74     Echo (ping) reply    id=0x0001, seq=42/10752, ttl=98

Frame 4063: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: Shuttle_ef:67:da (80:ee:73:ef:67:da), Dst: AzureWav_b2:c6:9d (70:66:55:b2:c6:9d)
Internet Protocol Version 4, Src: 10.0.5.11, Dst: 192.168.0.23
Internet Control Message Protocol

 

[hoitschau]

hehe bin echt zu wenig in Foren am posten, ich bin normalerweise der stille Mitleser, da man doch zu fast allem eine Antwort findet.

 

[blurrrr]

Die "freie" Übersetzung gibt dann auch noch dazu:

41: Hallo Hans, hier Peter, reich mir doch mal die Daten rüber.
42: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
43: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
44: Hallo Hans, hier Peter, reich mir doch mal die Daten rüber.
45: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
46: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
47: Hallo Hans, hier Peter, reich mir doch mal die Daten rüber.
48: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
49: Gustav: Na dann halt nicht Peter... (RST)

 

[blurrrr]

Hoffe, das war jetzt verständlich genug... heisst für mich übrigens erstmal:

192.168.1.0/24 -> 192.168.0.0/24 = NAT (sieht zumindestens sehr stark danach aus)

Da würde ich mal zuerst nachschauen... ein bisschen komisch ist das ganze schon, vielleicht gilt das auch nur für einzelne Hosts, was weiss ich... irgendwas hängt da jedenfalls schief und das ist auch der Grund für den Reset

P.S.: Falsches Forum... pfff

 

[hoitschau]

@blurrrr Wieso das so ist, kann ich dir nicht beantworten, ist glaube ich eine Eigenheit von Wireguard.
Ich verstehe das so:

Client sendet von lokaler IP
192.168.1.21
zum Standardgateway
192.168.1.1
das leitet das Paket zum lokalen Wireguard Interface
10.0.5.11
von dort über den Tunnel zum Tunnel Interface der OpnSense
10.0.5.1
dann zum Standardgateway (Opnsense)
192.168.0.1
und das stellt das Paket dem Client zu
192.168.0.49

Es scheint als dass immer das sendende Wireguard Interface den Paketheader anpasst, so ähnlich wie NAT.

Dass es funkitoniert siehst du im Paket 50-53 SIP Register.
(ev musst du im Wireshark rechte Maustaste - Dekodieren als - Aktuell - SIP anpassen)
Im Register Paket im Message Header siehst du die ursprüngliche IP:
Contact: 192.168.1.21
Die SIP-Aushandlung läuft über 2 Anfragen und 2 Requests und funktioniert.

 

[hoitschau]

Die "freie" Übersetzung gibt dann auch noch dazu:

41: Hallo Hans, hier Peter, reich mir doch mal die Daten rüber.
42: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
43: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
44: Hallo Hans, hier Peter, reich mir doch mal die Daten rüber.
45: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
46: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
47: Hallo Hans, hier Peter, reich mir doch mal die Daten rüber.
48: Hallo Peter, hier Gustav, ich hab hier Daten für Dich (Peter: Nein Danke, ich warte auf Daten von Hans!)
49: Gustav: Na dann halt nicht Peter... (RST)

sorry da hab ich dich auf die falsche Fährte gelockt.
schau dir den LAN Trace an, auch diese Pakete kommen beim Ziel korrekt an, und die Antwort wird auch korrekt geroutet.
Aber die Antwort des Ziels ist irgend wie anders wenn es im gegenünerliegenden Netz liegt.
Hänge ich das Ziel ins lokale Netz funtioniert das und ich erhalte andere Antworten.

Meine ursprüngliche Fragestellung war also falsch.