GRE routing fester IP ins Heimnetz!

  • Hey zusammen,


    ich brauche mal eure Hilfe..


    Vorhandene Netcup VPS:


    VPS Karnevall mit 2 IPs (1 durch vps + 1 zusätzliche)


    Zuhause:

    Telekom S.Vec mit 250Down / 42 up (sync mit 51up) - reicht für meine UNPRODUKTIVEN sachen völlig aus.

    A300 mit Ryzen 3600g + 32gb ram

    Proxmox als host (192.168.178.200)

    darunter eine PFSENSE (ip192.168.178.201) mit vmbr0 (wan) und vmbr1 (VIRTUELLES lan für die VMs)


    Das ganze hinter einer Fritzbox 7590(192.168.178.0/24) mit routing zum Pfsense LAN (10.0.0.0/24) gateway 192.168.178.201

    Das Routing bei einer normalen VM klappt auch soweit, komme aus der VM übers eigene Subnet ins netz auch die kommunikation im Netz selbst, funktioniert.


    Nun möchte ich aber folgendes erreichen:


    Die VMs am LAN der Pfsense über die zusätzliche IP des Netcup VPS erreichbar machen.


    Das ganze über ein GRE interface was ich aktuell wiefolgt aufgebaut habe:


    HOST (VPS) (DEBIAN BUSTER)

    modprobe ip_gre

    echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

    sysctl -p
    ip addr del (zusätzlicheipvonnetcup) dev eth0 #da netcup die beim image automatisch schaltet

    ip tunnel add gre1 mode gre local (ip vom NetcupVPS) remote (IP vom WAN der Fritzbox - öffentliche IP vom ISP) ttl 255

    ip addr add 172.20.1.1/30 dev gre1 #subnet zur kommunikation der beiden GRE endstellen 1 ist vps 2 ist die pfsense#<br> ip link set gre1 up


    ip route add 172.20.1.2 dev gre1

    ip route add (zusätzlicheipvonnetcup) dev gre1


    da das ganze über die MAC vom eth0 laufen muss noch

    ip neigh add proxy (zusätzlicheipvonnetcup) dev eth0


    ZUHAUSE (PFSENSE)

    GRE tunnel angelegt mit interface WAN(vmbr0)

    GRE tunnel local address ist die 172.20.1.2
    GRE tunnel Remote address ist die 172.20.1.1

    GRE tunnel subnet 30


    Dem ganzen dann noch dem GRE interface zugeordnet.



    Dann habe ich zwei Floating rules angelegt für in und out

    im out als Gateway das GRE interface


    ein 1:1 nat eingerichtet mit dem Interface GRE, external subnet ip ist die zusätzlichenetcupip und als internal ip die IP der Proxmox VM (10.0.0.6)


    SOOO

    nun das problem:


    in der PFSENSE selbst, kann ich 172.20.1.1 und 172.20.1.2 pingen.

    vom NETCUP vps aber NICHT! da erreiche ich nur mich selbst aber die PFSENSE nicht.


    Ich sitze an dem problem schon mehrere stunden, mich fuchst das ganze und ich würde es schon gerne hinbekommen :D


    Über sinnhaftigkeit lässt sich streiten.


    Ich darf den Strom vom Nachbar mitbenutzen, daher betreibe ich nen kleinen server bei mir zuhause, welcher über die IP erreichbar werden soll^^ und da mich das ganze mit knappen 5 euro günstiger kommt + viel mehr an leistung , möchte ich das ganze zuhause betreiben.



    In der Fritzbox selbst, habe ich 10.0.0.6 ports freigeschaltet + a uch schon exposed probiert. , brachte kein erfolg.


    wo liegt mein fehler...

    vl hat jemand ein ähnliches setup und kann mir weiterhelfen :/


    WICHTIG! der A300 hat nur 1!! nic , ich arbeite mit nem virtuellen switch in proxmox , das müsste auch so bleiben


    lg


    edit: gerne kann ich auch screenshots der konfigurationen machen :/

  • 1. GRE ist ein eigenes IP-Protokoll mit der Protokollnummer 47, d.h.

    a) im Server muss das entsprechende Modul geladen werden (Linux: ip_gre) und in der Firewall auch aufgemacht werden iptables / -p gre

    b) auf der Fritzbox muss eine entsprechende Regel eingerichtet werden (Forwarding von Protokoll 47):

    pasted-from-clipboard.png

    Natürlich stellst Du die 10.0.0.x Deiner pfSense dort ein.


    Aufpassen musst Du freilich auch auf die MTU - diese wird hinter der FB wohl unter 1500 liegen.

  • die PFsense WAN läuft auf vmbr0 (proxmox host 192.168.178.200) , pfsense wurde fürs WAN die ip 192.168.178.201 zugeteilt (erscheint auch unter "netzwerk" der fritte)

    als LAN interface wurde das subnet 10.0.0.0/24 zugeteilt.


    hinter dieser IP 10.0.0.6 steckt die CENTOS vm mit dem webserver.


    in der fritte kann ich die 10.0.0.6 nicht gesondert freigeben, da diese von der fritte als "bereits verwendet" angezeigt wird (wegen dem routing in der fritte und vermutlich da die ip von pfsense zugewiesenw urde?)


    Das Modul ist sowohl auf dem VPS als auch auf der pfsense geladen


    ich habe es jetzt auch geschafft, dass dass GRE netzwerk connectet ich kann vom VPS zum lokalen pingen und umgekehrt.

    auch kann ich jetzt die 2te dedizierte IP pingen.


    Wenn ich jetzt aber versuche über SSH auf die VM zu connecten (WAN>Fritzbox>Proxmox>Pfsense>DIESE VM

    krieg ich angezeigt: "connection to SSH2 server 45.***** (meine zweite ip halt)

    dann auch "Connection established" etc, dann beim first key exchange etc bleibt er hängen, vermutlich habert es iwo noch mti den ports :/


    auch kann ich unter der zweiten dedicated ip nicht auf die website zugreifen (80 oder 443) wenn ich im lokalen netz 10.0.0.6 eintippe, allerdings schon..


    wir kommen der sache schon nhäer, aber iwo haberts :D


    MTU vom GRE interface in der PFSENSE ist auf 1476 gesetzt.


    root@v220200264269109717:~# iptables -L

    Chain INPUT (policy ACCEPT)

    target prot opt source destination

    ACCEPT gre -- anywhere anywhere


    ist ebenso gesetzt

  • Wenn die TCP-Verbindung z.B. für SSH prinzipiell aufgebaut wird (Handshake erfolgreich), es aber danach hängen bleibt, klingt das verdächtig nach einem MTU-Problem. Darauf hat eripek vorhin schon kurz hingewiesen.

    dumme frage, wird der MTU dem LAN, WAN oder GRE netzwerk in der Pfsense zugeordnet.. hab ihn aktuell auf dem GRE und würde den jetzt mal auf 1476 oder 1468 setzen


    komme mit der berechnung nicht so ganz klar,


    die fritte nutzt ja ppoe mtu 1492.. wie berechnet ich jetzt den mtu, welchen ich verwenden muss? :/


    habe testweite mal unwissentlich auf 1400 gestellt.. ohne erfolg


    falls es weiterhilft "The SS2 Session has terminated with error, reason: FlowsocketReader: Error receiving bytes. Windows error 10060 ein Verbindungsversuch ist fehlgeschlagen da die gegenstelle nach einer bestimmten ....."

  • Bin jetzt viele MTUs durch, ohne erfolg :/ kann die zweite ip pingen in beide richtungen, ssh handshake erfolgt, weiter gehts aber nicht.


    auf den auf einer VM angelegten apache, komme ich weiterhin nicht drauf, die seite"lädt" ewig.

    Übers lokale netzwerk, komm ich drauf..


    jmd noch ideen?:(

  • kann die zweite ip pingen in beide richtungen […]

    Mit welcher Paketgröße? Mit Don't-Fragment-Bit oder ohne?

    jmd noch ideen?:(

    Das ist zwar keine optimale Lösung, aber oftmals ein Weg, um es einzugrenzen: https://www.tldp.org/HOWTO/Adv…rtc.cookbook.mtu-mss.html


    Wenn es mit deutlich reduzierter MSS auch nicht klappt, hat es vielleicht doch nichts mit der MTU zu tun. Bevor Du davon ausgehst, aber bitte auf beiden Seiten mal mit tcpdump kontrollieren, ob die angepasste MSS wirklich ankommt! Nicht, dass da irgendein System dazwischen den Wert wieder überschreibt.

  • Also MTU:1

    {Internet 1500} --- [FB PPPoE 1492] --- [pfSense WAN 1492] --- [GRE 1468]


    Ping: 1468 - 28 (IP-Header + UDP Header) = 1440 Nutzlast


    MSS IPv4 / pf WAN 1452; IPv6 1432

    MSS GRE IPv4 1428; IPv6 1408


    Auf die Schnelle, wenn ich mich nicht verrechnet habe.

  • probiere es heute mittag mal aus,. vielen dank!


    wäre es vl einfacher, meine zwecke auch über eine openvpn zu erreichen?


    mittels des Openvpn access manager images z.b.?

  • OpenVPN ist keine Hexerei, es erfordert nur etwas Manual lesen und Geduld. Ich gestehe, ich habe Wireguard dafür noch nicht vollständig durchschaut.

    Ich rate Dir wegen Deiner verringerten MTU aber zu den Parametern tun-mtu 1500 und fragment mit dem Wert, der bei einem Ping gerade noch möglich ist. Wenn Kompression eingesetzt wird, verringerst Du fragment um weitere 4 Byte. Diese Werte sollten auf beiden Enden richtig und gleichlautend konfiguriert sein, denn per Push bekommt man die nicht auf den Client. Detto im Peer Mode.


    Noch eine Frage am Rande: Deine Fritzbox unterstützt auch PPPoE-Passthrough? Wenn da keine Telefoniefunktionen daran hängen, könnte man auch die pfSense über PPPoE „einwählen“ lassen. Wenn der Provider es unterstützt, und auch die FB mitspielt, sind Baby Jumbo Frames nach RFC 4638 denkbar. Der pfSense kann man so eine ppp-MTU von 1508 (acht Byte für PPPoE statt abzuziehen, einfach aufschlagen), denkbar.

  • Hab die MTUs der gegenstellen auch wie wild angepasst, mit den MTUs etc, bin ich ehrlich - kenne ich micht so aus.. verbringe schon ganzen tage lange damit zu lesen und zu "lernen"..

    Ich weiß das es quasi die "Paketgröße/Framegröße" ist und bei nem oversize es zur fragmentierung kommt = schlecht


    Langsam frage ich mich, ob vl das doppelte NAT einfach iwie probleme macht..


    Ich möchte die feste ip ausschließlich in Proxmox verwenden, es wird kein "physikalischer, externer computer" mit dieser IP im LAN bestückt.

    Quasi eine KVM in Proxmox, die über die feste ip erreichbar ist ^^


    Mein neuer gedanke war, mir ne digibox basic zu kaufen, die in bridge mode zu versetzen, nen zusätzlichen nic für den Proxmox host und das so aufzubauen:


    Digibox Basic als Bridge-> Proxmox Host-> (WAN)PPoE Einwahl mittels PFsense->LAN->zur fritzbox als reiner Router fürs "Heimnetz" (Konsole, handy, tv usw usw.)

    Neben dem LAN wird dann noch eine Virtuelles Interface (vmbr ohne gateway anlegen?) erstellt auf die ich dann IRGENDWIE die eine KVM hin hänge und den GRE tunnel mit diesem Interface verbinde...


    wäre das rein theoretisch gesehen die bessere lösung? oder unnötig da das ganze auch wie ichs vor hatte (1 nic da das "lan" an der pfsense kein Physikalischen Nutzen hat (da hängt nix dran ..außer halt aktuell die VM ) aber das klappt ja nicht wirklich :(


    Was würdest du / ihr tun?


    Vielleicht möchte das jemand privat mal experimentell nachbauen und kann das ganze in der vorgehensweise ggfls. sogar bebildert dokumentieren?


    ich gehe mal SEHR stark davon aus, dass da viele interesse dran hätten ^^


    Zum Thema sicherheit des VPS (ssh wird deaktiviert, verwaltung erfolgt über die VNC konsole von netcup dann), außer dem GRE läuft auf dem kein weiterer Dienst.

    Updates werden über CRON eingespielt


    Mein ziel nochmal erwähnt:


    Die zusätzliche IP vom VPS per GRE oder VPN oder sonst was, nachhause routen in die pfsense rein und dort dann einer KVM zuweisen...

    Das ganze auch ohne jeden einzelnen Port im VPS von Netcup einzeln weiterleiten zu müssen (geht das? - quasi ein 1:1 weiterleiten / nat)


    Muss schon sagen, sitze da jetzt schon echt tage dran ohne großen erfolg.. aber mich Fuchst es einfach!

    Ich würde demjenigen der eine zufriedenstellende Lösung + den ausschlaggebenden hinweis gibt, nen döner per paypal ausgeben.. zwar nicht viel aber für die mühe..^^

  • Wenn Dein Anschluss daheim eine dynamische IP-Adresse hast, wird OpenVPN oder Wireguard sinnvoll sein.

    Dass Du Probleme mit der MTU hast, kann an dem CGN liegen. Durch das NAT ist die Quelladresse einer ICMP Antwort ECHO REP auf ein ECHO REQ unter Umständen nicht routebar. Damit ist Path MTU Discovery außer Funktion. Da hilft nur manuelles setzen der MTU auf dem Interface oder als per Route MTU. OpenVPN kann die Pakete umpacken, und eine volle MTU transportieren, zur Vermeidung von allzu vielen Fragmenten muss man das mit das Fragment und tun-mtu austarieren. Alle anderen Lösungen „erben“ die MTU des Parent-Interfaces und verringern sie durch Verkapselung noch weiter.


    Wie geschrieben: PPPoE beherrscht Baby Jumbo Frames, sodass man durch ein Aufschlagen des Overheads nach Außen, „innen“ im PPPoE-Tunnel die volle MTU von 1500 erhalten kann. Der Provider muss das unterstützen.

  • Die Telekom beherrscht an Privatkundenanschlüssen/pseudo-Geschäftskundenanschlüssen (DeutschlandLAN Data/Voice Tarife) keine Baby Jumbo Frames, die Option fällt daher raus.

    CGN setzt die Telekom ebenfalls nicht ein.


    Ich würde mir auch nicht die Mühe machen hier mit GRE etwas hinzubasteln, für dein Vorhaben eignet sich Wireguard gut. Einziges Problem: pfSense kann von Haus aus noch kein Wireguard.

    Wenn du es aus den FreeBSD Repos nachinstallierst, oder zum 'Konkurenten' OPNSense greifst, hast du trotzdem nur die Userland Variante, die von der Performance bei weitem nicht mit der Kernel Variante in Linux mithalten kann.

    Wenn du keine großen Bandbreiten durchschieben willst, dürftest du es aber ohne Probleme einsetzen können.

    Alternativ erschlägst du die pfSense VM mit CPU Power :)

  • ICH HABS GESCHAFFT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! MIT DEM GRE.


    Es lag an einer Mischung aus der MTU + den Proxmox einstellungen..


    ich hab in Proxmox lediglich


    eingetragen gehabt.


    Nachdem ich nun 2x vlans an den NIC gehangen hab mittels bridge dann in die vm gebunden hab und die MTU auf 1436 auf dem GRE angepasst habe und das WAN MTU auch runtergesetzt hab.


    meine Proxmox einstellung sieht jetzt so aus:


    Da ich kein "physikalisches" lan habe, habe ich gaaaanz einfach eine zweite vm aufgesetzt, die an die vmbr1 gehangen, dort dann auf das in pfsense zugewiese lan subnet (10.0.0.0/24 - fest zugewiesene ip 10.0.0.1/24 - pfsense dhcp für das lan aktiviert gehabt) , somit konnte ich auf die einstellungsseite.

    Dort habe ich das "Block Private Networks" feature ausgeschaltet + unter system-advanced - network das hardware checksum offload ausgeschaltet.


    Dann habe ich eine zweite vm erstellt, diese an vmbr2 gehangen (ebenso per dhcp von pfsense dann zugewiesen, diesmal aber im 192.168.1.0/24 netz.)


    durch passendes routingeinstellung per anleitung von : KLICK MICH (administrator.de) + 1:1 nat habe ich nun eine VM mit der ÖFFENTLICHEN IP von netcup (die zusätzliche)


    von meiner 250mbit leitung kommen laut speedtest in der VM 194Mbit im down und 42 im up an - im richtigen LAN kommen 255 - 44 an ... das reicht für meine zwecke!


    hurraaaaaaaa


    lustig ist, habe mir bevor es geklappt hat eine digibox basic für bridge mode + nen zweiten nic bestellt...war jetzt für meine zwecke unnötig ... die digibox is privat gekauft und der nic, mhm .. vl brauch ich den noch iwie anders..



    falls interesse besteht, kann ich gerne ne anleitung schreiben die bebildert + detailierter ist :)

  • Ich stehe jetzt nur vor dem problem, dass ich aus dem Lokalen LAN der Fritte etc. nicht auf die externe ip komme zb 123.456.789.0:2031


    Vom Smartphone oder Tablet über LTE geht es allerdings ohne Probleme, lieg ich mit Hairpin richtig?

    Wenn ja wie kann ich das ambesten lösen so dass ich auch aus dem lokalen netz drauf zugreifen kann

  • auch dieses problem wurde gelöst...


    da ich pihole als dns resolver nutzte, hab ich dort noch nen custom dns eintrag veranlasst, der zb. srv1.meinedomain.tld auf die interne ip des servers (192.168.1.2) weiterleiten lässt.


    ein zugriff aus dem WAN heraus, klappt wunderbar (kein nat loopback).

    somit klappt jetzt alles zu 100% wie ichs mir vorgestellt habe =)


    möchte mich bei allen nochmal bedanken für den tipp mit der MTU und dem GRE port freigeben in der fritte! *happy*

  • Von mir ein Danke für die „coole“ Anleitung!


    Ich wäre nie auf die Idee gekommen so was mit einem GRE-Tunnel umzusetzen. Ich habe auch so ein Konstrukt für privat, aber hier macht ein Apache einen Reverse-Proxy via https.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Sobald ich die zeit hab, mach ichs nochmal bisjen detailierter :)


    https://administrator.de/wisse…fsense-tunnel-567618.html


    hat mir sehr viel geholfen, dabei wurde aber auf richtige nics ausgegangen.


    ich habe es mit reinen virtuellen nics gemacht, da gabs paar fallstricke die man beachten muss X)


    nen ganz kleinen vps + ne zusätzliche ip, so hat man für kleines geld ne funktionierende feste ip im heimnetz :D


    angenehmer als 70euro + bei telekom für nen dlan voice/data..


    auch reversedns alles klappt wunderbar!

    mit lfd/csf noch den vps "abgesichert", alle dienste bis auf den linux tunnel deaktiviert, ssh deaktiviert (komme auch über die netcup shell rein), so kann das ganze auch relativ problemlos dauerhaft laufen, firewall wird in der VM in proxmox dann gemacht x)


    mitlerweilee erreiche ich auch im speedtest von meinen 250mbits down und 42 up den kompletten anschlag :D

    keine verringerung der bandbreite bei mir feststellbar.

    lediglich pingzeiten is durch die paar hops mehr im route bisjen höher. aber 31ms halte ich für akzeptabel gegenüber dem preisersparnis hehe


    wichtig ist halt, die IP des WANs zuhause im GRE host zu ändern, falls man zuhause ne neue ip zugeteilt bekommt, das lässt sich mittels Script wie im link beschrieben bewerkstelligen, habs nur noch nicht hinbekommen, vl hat da jmd ne anleitung für mich zum umsetzen haha


    tu es aktuell manuell anpassen bei nem reset. über nen gre update

    ps:

    bin ich froh, wenn sich ipv6 wirklich durchgesetzt hat und auch rpivatleute nen ipv6 netz bekommen..

    dann wäre nat usw. endlich geschichte.. und solche bastellösungen gehören der vergangenheit an