Packete gehen nicht durch den exit tunnel sondern fallen bei der Host Maschine raus

[lodrich]

Server Version 1.3.0
TCPdump zeit auf der host Maschine für die ip packete:

Proxmox-VE ~ # tcpdump host 10.64.106.247 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:41:21.044180 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 10:41:21.044250 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 10:41:21.044319 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 10:41:21.044348 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 10:41:21.044382 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 10:41:21.044391 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 10:41:21.045158 IP 10.64.106.247.48262 > d90-130-70-73.cust.tele2.se.http: Flags [R], seq 1372333260, win 0, length 0 ^C 7 packets captured

mit vpn7 ist es genau so. bei den anderen hatte ich auf die schnelle nicht geschaut.

Hetzner hat mir daraufhin eine IP gesperrt weil ich packete für private ips versucht habe da drüber zu schicken.

[cremesk]

sieht eher nach einem issue auf deiner Hostmaschine aus!
Hier kann ich auf meinen Hostmaschinen gleiches Problem nicht sehen.

[ddmesh]

kann aber evtl trotzdem am Freifunk Server liegen, da auf der Host Seite kein NAT gemacht wird, sondern alles Container Interfaces inklusive des Interfaces vom Host in der selben Bridge liegen. die Interfaces innerhalb, erhalten von hetzner die öffentliche ip direkt via Mac zugeordnet. wenn beim Speedtest zwar die richte Absender ip (10.64.x.y) gewählt wird, aber durch das Routing die Pakete trotzdem auf dem Container Interfaces rausgehen, wäre das falsch. evt ist da noch eine Lücke in den Routing Rules und noch nie aufgefallen?

On 1 July 2020 18:50:05 CEST, Sven ***@***.***> wrote: sieht eher nach einem issue auf deiner Hostmaschine aus! Hier kann ich auf meinen Hostmaschinen gleiches Problem nicht sehen. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #19 (comment)

Freifunk Dresden

[ddmesh]

Problem ist folgendes:

• auf dem ffdd-server ist ein vpn0 (internet).
• über freifunk wird zu facebook video gestreamt.
• tbb_fastd2 mtu ist 1200
  Facebook sendet UDP packete manchmal mit 1285 bytes:
  src: facebook IP 157.... -> dest: vpn0-tunnel ip 10.64...... (das ist richtig)
  Daraufhin generiert ffdd server icmp-fragmentation needed.
  src: vpn0-tunnel ip 10.64..... -> dest: facebook IP 157..... (richtig)

Problem ist, dass diese pakete local erzeugt werden. via routing rules werden aber lokale pakete über das
hetzer interface rausgeleitet (welche aber als absender eine private ip haben von vpn0).
Das führt dann zum sperren.

da die anderen ffdd-server installationen immer irgendwie in container mit NAT laufen, fällt das nicht auf.

Wenn ich folgende Rule hinzufüge:
ip rul add iif lo ipproto icmp table public_gateway prio 399

geht das erstmal. aber leider ist nicht sicher, ob es nachteile hat. sollte aber nicht, da diese immer mit der maximalen
mtu 1500 reinkommen könnten und nicht weiter geroutet werden.

Seiteneffekt: Wenn es ein public_gateway gibt (was normalerweise der fall ist), werden alle localen pings über
dieses geschickt. Der gateway-check sollte keine probleme haben, da die routing tabellen vor dieser liegen.

ich mache da mal einen CR dafür.

[cremesk]

tested and fixed in #20 !