Mini-Howto: Kompletten Internetverkehr über AVM VPN routen

[PeterPawn]

192.168.179.0/24 ist schon mal keine gute Wahl für ein LAN-Segment einer beliebigen FRITZ!Box - praktisch jedes andere Netz (vielleicht noch außer 192.168.180.0/24) würde besser funktionieren. Wenn irgendwo in der Box auch bei deaktiviertem Gastnetz eine der Vorkehrungen für die Isolation zwischen dem Gastnetz und dem LAN aktiviert sein sollte (und die "guest"-Bridge ist m.W. immer aktiviert und konfiguriert, auch wenn keine Interfaces dort eingebunden sind) und die verwendet das (standardmäßig genutzte) LAN-Segment bei 192.168.179.0/24 (oder 192.168.189.0/24, wenn die Box als LAN1-Router arbeitet), dann sucht man sich dumm und dusslig. Zumal gerade auch beim VPN besondere Vorkehrungen zur Isolation getroffen werden, wie man anhand der Zeile "Forbidden Clients" in der Support-Datei bei den VPN-Verbindungen sehen kann. Das muß nicht zwangsläufig zu Problemen führen, aber man darf/sollte sich auch nicht wundern, wenn irgendwelche LAN-Clients (jenseits der Box selbst, bei der das natürlich "direkt" ankommt und nicht noch einmal ins Routing muß, wo dann solche Restriktionen wohl erst greifen) in so einer Konfiguration nicht richtig erreichbar sind.

Ansonsten muß man eben bei der "ausgehenden" Verbindung (das wäre die mit "conntype_out", wobei das auch keine "richtige" LAN-LAN-Kopplung ist, was hier konfiguriert wurde) die "accesslist" passend erweitern, daß alle Pakete von solchen Hosts, die ihren eigenen Standort "maskieren" sollen, über den Tunnel gehen - das machen sie genau dann, wenn sie in einer "permit"-Regel ausgewählt werden. Wie allgemein oder wie speziell die jetzt zu formulieren wäre, hängt von den konkreten Erfordernissen ab - die "Grundlagen" dafür, sind im IPPF mehrfach beschrieben.

Wobei es vermutlich tatsächlich schlauer wäre, eine LAN-LAN-Verbindung beim VPN zu konfigurieren - es geht zwar auch mit dem NAT, was hier dann automatisch verwendet wird, aber gerade beim Versuch, aus dem LAN auf der "Serverseite" auf andere Geräte an der "Client-Box" zuzugreifen, steht einem die Firewall der "Client-Box" schon mal im Weg ... das braucht dann entweder eine aktive ausgehende Verbindung oder irgendwelche Portweiterleitungen und ob die für eine VPN-Verbindung überhaupt richtig funktionieren, müßte man wohl auch erst einmal testen.

Um die "handgemachte" Konfiguration (die Templates sind ja nun vorhanden bzw. es ist klar, wie man an sie herankommt, wenn man die Box zur Konfiguration verwendet) kommt man jedenfalls ohnehin nicht herum, wenn man ein komplettes Netz (oder auch nur einzelne Clients) über ein anderes LAN ins Internet bringen will.

 

[Fry111]

Mittlerweile hat AVM ja selbst eine art Lösung für die Sat-Receiver usw.
https://avm.de/service/fritzbox/fri...xen-fuer-einzelne-LAN-Anschluesse-einrichten/
Nur dann ist der Receiver halt im ´eigenen´ LAN (also an FB2) nicht mehr erreichbar.

Wie müsste denn die acceslist aussehen, wenn ich bei der lan-lan-koplung den internetzugang über die entfernte box nur für ein bestimmtes gerät/ip realisieren wollte?
Also nicht den gesamten ´Internet-Traffic´ von FB2(..172.0) über FB1(..171.0) laufen lassen.
Sondern eben NUR von Gerät mit fester IP(z.Bsp im WLAN) 192.168.172.111 -> gesamten Internet-Traffic über FB1 (192.168.171.1) leiten, bei bestehender lan-lan-vpn zwischen FB2..172.0 und FB1 ..171.0
Der Rest der angeschlossenen Geräte soll sich ganz normal verhalten und je über die eigene FB weitersurfen..
Und eben wenn möglich das Gerät ...172.111 im 172er-lan weiter erreichbar sein... ( )

 

[d_kms]

Hallo,

ich versuche schon seit ein paar Tagen auch zwei FritzBoxen via VPN zu verbinden, sodass die Box 2 nur über die Box 1 ins Netz geht und vor allem die IP Abfrage von einem Gerät an Box 2 über die Box 1 geschickt wird.

Wenn ich die VPN.CFG Dateien in die jeweilige Box hochlade, sind diese 1:1 in den Konfigurationsdaten hinterlegt, dieses kann ich beim Einsehen der Sicherungsdatei nachvollziehen.
Es wird jedoch hier dann keine VPN Verbindung aufgebaut, in der Liste System/ Ereignisse sind keine Fehlermeldungen zu erkennen bzw. der Versuch eines Verbindungsaufbaus zu erkennen.
Dieses klappt erst, wenn ich den Pre Shared Key bei beiden Boxen erneut setze, jedoch überschreibt dieses dann die Anpassungen in der Accesslist.

Folgende Detailinformationen bzgl. des Setups

Box 1 : FritzBox 6590 (nicht von einem Kabelanbieter gemietet)
Firmware: 6.87
Provider: Unitymedia / IPv4 Anschluss
Heimnetzwerk IP: 192.168.118.0

Box 2 : FritzBox 4020
Firmware: 6.83
Provider: o2 (via Mobil HotSpot WLAN verbunden)
Heimnetzwerk IP: 192.168.128.0

Es soll eine evtl. IP Abfrage eines Gerätes an der Box 2 (FB 4020) über den Internetanschluss der Box 1 (FB6590) geschickt werden.

Ich finde keinen Fehler in den Config Dateien und würde mich freuen wenn hier jemand mal eine sachkundigen Blick drauf wirft.

Anbei beide Config Dateien.


Viele Grüße

 

[PeterPawn]

Warum sollte die 4020 denn alle Pakete von einer Adresse aus 192.168.188.0/24 durch den Tunnel schicken?

Die "accesslist" in der 4020 paßt in keinster Weise zur Beschreibung.

 

[d_kms]

Da hast Du recht ... hatte mehrere Access List Beispiele aus dem Thread ausprobiert, abgeändert auf meine lokale IP 192.168.128.0 und dann für den Post ausversehen eine ursprüngliche,kopierte übernommen

Die Access List in der Box 2 lautet korrekt:

accesslist = "reject udp any any eq 53", "reject udp any any eq 500", "reject udp any any eq 4500", "permit ip 192.168.128.0 255.255.255.0 any"

Sorry für die Verwirrung.

 

[PeterPawn]

Damit sollte dann aber auch tatsächlich wenigstens ein Tunnel aufgebaut werden ... wobei da ein "permit ip any 192.168.118.0 255.255.255.0" für einen Test, ob der Tunnel überhaupt funktioniert, noch die sinnvollere Einstellung ist.

Solange tatsächlich nur ein einzelner Host den gesamten Internet-Verkehr über die andere Box abwickeln soll, sind die ganzen "reject"s auch Grütze - die braucht es nur dann, wenn tatsächlich alle Clients (inkl. der FRIT!ZBox selbst, mit Ausnahme des VPN-Verkehrs (das sind die Ports 500 und 4500) und von DNS-Abfragen (das ist Port 53), was erst mal benötigt wird, um den Tunnel überhaupt einzurichten) den gesamten Verkehr über die VPN-Verbindung senden sollen.

Aber das steht ja schon in Deinem ersten Beitrag nicht so ganz eindeutig ... wenn Du Dich dann entschieden hast, muß das "permit"-Statement (oder ggf. auch mehrere) einfach nur festlegen, welcher lokale Traffic für den Tunnel "ausgewählt" und damit durch diesen transportiert werden soll.

Da die Konfiguration der 4020 ja jetzt wieder verschwunden ist, muß ich "raten", ob der "keepalive_ip"-Eintrag dort richtig war oder nicht ... der wird benötigt, damit der Tunnel überhaupt automatisch aufgebaut wird. In der 6590 ist die Angabe von "remotehostname" mit ziemlicher Sicherheit sinnlos - außer die 4020 hat über o2 tatsächlich ihre eigene öffentliche IPv4-Adresse, was ich mal stark bezweifeln möchte. Sollte das aber doch der Fall sein, würde ich das noch dazuschreiben ... das ist dann nämlich wichtig. Ohne diese Adresse muß immer die 4020 die Verbindung aufbauen und da ist die Angabe von "remotehostname" in der 6590 dann höchst hinderlich.

 

[Shirocco88]

Box 1 : FritzBox 6590 (nicht von einem Kabelanbieter gemietet)
Firmware: 6.87
Provider: Unitymedia / IPv4 Anschluss
Heimnetzwerk IP: 192.168.118.0

LAN2LAN-VPN mit Fritzbox am Unitymedia-Anschluß <UPDATE am DS-Lite-Anschluß /UPDATE> geht nicht, hierzu gibt es ich Postings mit Problemen im Forum, oder anders ausgedrückt das hat bisher IMHO noch niemand im Forum zum laufen bekommen.

UPDATE:
es ist so wie PeterPawn in #471 schreibt, bei "native IPv4" sollte es funktionieren, da hier das MTU1460-Problem nicht auftritt.

 

[PeterPawn]

Moment ... wieso sollte das an einem Anschluß mit nativem IPv4 nicht funktionieren? Dabei spielt die kleinere MTU eines Tunnels zu einem AFTR ja keine Rolle und soweit ich mich erinnere, war das bisher das einzige bekannte Problem mit AVM-Boxen und VPN am UM-Anschluß.

Wo liegt denn das Problem in so einem Falle? Warum habe ich bisher alles in dieser Richtung verpaßt? (Ja, ich weiß schon, daß Du die letzte Frage nicht wirklich beantworten kannst, aber vielleicht kannst Du mir ja einen Tipp geben, wann das war und ich leite daraus dann ab, was ich in dieser Zeit getan habe.)

Außerdem ist hier ja der Kabelanschluß der "eingehende" ... wäre das nur DS-Lite, wäre die ganze Konstruktion wohl nicht machbar.

 

[Shirocco88]

UPDATE in #470 gemäß Hinweis von PeterPawn eingepflegt, bei "native IPv4" sollte LAN2LAN-VPN funktionieren, da hier das MTU1460-Problem nicht auftritt.

das Problem von @d_kms kann somit weiter "troubleshooted" werden.

 

[d_kms]

Nachdem ich die Config nur mit "permit ip any 192.168.118.0 255.255.255.0" erstellt habe, wurde auch direkt nach dem Import der Config eine VPN Verbindung aufgebaut, siehe Anlage.
Danach habe ich mit dieser Datei noch mal mehrere Access List Einträge probiert und war mit
accesslist = "reject udp any any eq 53", "reject udp any any eq 500", "reject udp any any eq 4500", "permit ip any any";
erfolgreich. Der VPN wird aufgebaut und bei der IP Abfrage erscheint die IP der Box .

Anscheinend blockierte der Eintrag
accesslist = "reject udp any any eq 53", "reject udp any any eq 500", "reject udp any any eq 4500", "permit ip 192.168.128.0 255.255.255.0 any"
den Aufbau des VPN Tunnels oder ich habe vorher einen Fehler gemacht, welchen ich bis jetzt nicht entdeckt habe.

Stellt sich nun die Frage, wie ich bei Import einer Config Datei den VPN nur auf den LAN Port 4 oder auf einen bestimmten Client beschränken kann.

 

[PeterPawn]

Das geht beim Import gar nicht ... es läßt sich nur über das GUI konfigurieren, da dann parallel noch eine "ipsecbrX" als (Bridge-)Interface eingerichtet werden muß (in der "ar7.cfg"), in der nur dieser eine "delegierte" Ethernet-Port versammelt ist.

Was den "einzelnen Client" angeht, ist das mit etwas Überlegung sicherlich leicht beantwortet ... daß dann ein "permit ip any any" eher nutzlos ist, erschließt sich ebenfalls, wenn man die Wirkungsweise verstanden hat.

Aber da Du Dir ja offenbar immer noch nicht final im Klaren bist, was Du nun wirklich willst (inzwischen sind wir jetzt schon bei drei verschiedenen Optionen:

• alle Clients über die andere Box
• nur einen einzelnen Client über die andere Box
• nur einen einzelnen Port über die andere Box

), harren wir mal der Dinge, die da noch kommen.

 

[d_kms]

Im Grunde ist mir schon klar was ich möchte, nämlich dass ein bestimmtes Gerät, welches an Box 2 angeschlossen ist, seinen kompletten Datenverkehr inkl. IP Abfrage nur über die Box 1 ins WWW kommuniziert.
Dafür würde ich in kauf nehmen, wenn

- alle Clients über die andere Box (sprich es hängt nur ein Client an der Box)
- nur ein einzelner Client über die andere Box ( wahrscheinlich über eindeutige Zuweisung der IP in der Config Datei - dabei bräuchte ich noch Hilfe)
- nur einen einzelnen Port über die andere Box ( ergo hängt hier nur der eine Client an der Box)

kommuniziert.

Variante 1 habe ich bereits erreicht, ist aber nicht die non plus ultra Lösung
Variante 2 kann ich mit meinem aktuell vorhandenen Wissen nicht, würde mich über Hilfe freuen
Variante 3 wird wohl nicht klappen, da ich die Erfahrung gemacht habe, dass durch Eingriffe in der Config über das GUI die manuellen Accesslist Einträge überschrieben werden

Wenn Du oder jemand anders mir helfen möchte, GERNE und ich wäre dankbar dafür, wenn Du sarkastisch werden möchtest -auch gut - hilft mir nur leider nicht.

 

[PeterPawn]

Mein Sarkasmus ist aber eher die Folge Deiner bisherigen "Verschwiegenheit" ... nachdem ich Dich auf den Fehler in der Konfigurationsdatei der 4020 aufmerksam gemacht habe, ist bei Dir offenbar der Eindruck entstanden, es würde von jetzt an ausreichend sein, wenn Du nur bröckchenweise Informationen lieferst und das dann auch noch "in Prosa".

Die Frage, was Du eigentlich willst, habe ich nämlich schon in #469 gestellt ... wenn das für Deine Wahrnehmung zu subtil war, entschuldige ich mich für meine Ungeduld.

Vielleicht gelingt es Dir ja auch noch zu beschreiben, was Du nun an den Inhalten der "accesslist" tatsächlich verstanden hast und was nicht ... man kann nämlich aus dem zweiten Satz in #473 auch wieder alles herauslesen, was man möchte - von unbekümmertem "Probieren" mit irgendwelchen nicht verstandenen Einstellungen bis zum systematischen Test mit Einstellungen, die man absichtlich und mit Vorbedacht so gewählt hat.

Aber was Du da alles gemacht hast, kann man eben nur raten ... und auch die Frage, was Du vorher gelesen hast, welche "Konfiguration" denn die verwendeten FRITZ!Boxen nun haben (wenigstens die Frage, ob tatsächlich beide eine öffentliche IPv4-Adresse haben) und was konkret Du denn nun getestet und Deinerseits für "untauglich" befunden hast, ist hier nicht mal im Ansatz beantwortet.

Was bleibt einem da noch anderes übrig als mit Sarkasmus zu reagieren, wenn Du (a) Aufforderungen/Ermunterungen zur Preisgabe von (durchaus relevanten) Details tapfer ignorierst und (b) parallel dazu mit durchaus halbgaren (und vermutlich auch falschen) Vermutungen aufläufst, deren Ursprung Du gar nicht ordentlich erläuterst und die daher durchaus auch auf Deinen eigenen Fehlern beim Testen beruhen können - was Du aber offenbar gar nicht erst in Erwägung ziehst oder es zumindest genauso wenig zeigst wie den Umstand, ob Du von bestimmten Punkten, die man hier - nur für Dich - niedergeschrieben hat, überhaupt Kenntnis genommen hast und wenn nicht, ob das einer eher selektiven Wahrnehmung oder bewußtem Ignorieren geschuldet war.

Als Beispiel sei nur folgendes genannt:

Variante 3 wird wohl nicht klappen, da ich die Erfahrung gemacht habe, dass durch Eingriffe in der Config über das GUI die manuellen Accesslist Einträge überschrieben werden

... hier ziehst Du aus der Notwendigkeit, das GUI für das Einrichten des zusätzlichen Bridge-Interfaces zu verwenden, ganz einfach Deine eigene Schlußfolgerung, daß man die automatisch vom GUI erzeugte VPN-Konfiguration im Nachhinein nicht mehr manuell ändern könne. Dabei hast Du hier offensichtlich nur die falsche Reihenfolge im Sinn ... wenn die IPSec-Bridge erst einmal eingerichtet ist, kann man auch deren Einstellungen (in Grenzen, sprich: mit den Parametern, die auch in der VPN-Konfiguration und nicht in der "ar7.cfg" eingestellt werden) ersetzen - VPN-Konfigurationen werden über den Namen "adressiert" und wenn man eine Konfiguration mit dem Namen einer vorhandenen importiert, wird diese ersetzt. Das ist also durchaus auch eine gangbare Option ... ob sie notwendig und sinnvoll ist, hängt halt davon ab, um was für ein Gerät es sich handelt.

Wenn das tatsächlich irgendein TV-Receiver ist und die VPN-Verbindung zum Umgehen einer Regionalsperre dient, muß man sich halt auch über die Konsequenzen klar werden (noch besser klar sein, aber das geht nur mit Recherche) und akzeptieren, daß dann keine Steuerung über Smartphone, Tablet, Rechner aus dem LAN der lokalen FRITZ!Box möglich ist - jede Kommunikation zwischen lokalen Geräten und allem, was an einem solchermaßen delegierten Port angeschlossen ist, wird nicht funktionieren.

Um die Funktionsweise der "accesslist"-Einträge zu verstehen, reicht es vermutlich schon, wenn Du nur diese eine letzte Seite in diesem Thread liest (daß Du das bereits getan hast, hättest Du ebenfalls vergessen zu erwähnen, wenn das tatsächlich so sein sollte) ... auch hier ist "beschrieben", welche Funktion diese "accesslist" tatsächlich hat - teilweise sogar direkt in #469 im zweiten Absatz und nur für Dich (auch wenn spätere Leser das ebenfalls sehen können).

Wenn Du also zusätzliche Hilfe brauchst, müßtest Du das schon noch etwas genauer erklären, wobei ... und was Du an den bisherigen Erläuterungen (auch an denen, die schon vor Deiner Frage hier in diesem Thread stehen) nicht verstanden hast. Wenn Dein Ziel am Ende ist, daß Du hier eine "fertige" VPN-Konfigurationsdatei kriegst, bin ich definitiv der Falsche ... dann mische ich mich umgehend hier raus und überlasse das Feld anderen.

 

[Overloader]

Hallo,

ich habe eine Site 2 Site IPSec Verbindung von meiner Fritz Box (Netz 192.168.177.0) zu einer entfernten pfsense (Netz 192.168.1.0) mit folgender Konfigurationsdatei erfolgreich hergestellt und kann auch die pfsense IP 192.168.1.1 pingen. Nun möchte ich gern den gesamten Internetverkehr der Fritz Box über die VPN Tunnel schicken. Ich finde aber irgendwie nicht die richtige Einstellung der accesslist.

Ist es möglich das der Internetverkehr aller Geräte hinter der Fritz Box über den VPN Tunnel geroutet werden können mittels accesslist?

/*
* vpn.cfg
*/
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "[vpn name]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = [pfsense externe ip];
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "[DynDns Fritz Box]";
                }
                remoteid {
                        ipaddr = [pfsense externe ip];
                }
                mode = phase1_mode_idp;
                phase1ss = "dh14/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "[super secret key]";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
                accesslist = "permit ip 0.0.0.0 0.0.0.0 192.168.1.1 255.255.255.255";

      }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

// EOF

 

[PeterPawn]

Ist es möglich das der Internetverkehr aller Geräte hinter der Fritz Box über den VPN Tunnel geroutet werden können mittels accesslist?

Ja.

 

[Overloader]

Ja.

Ausgezeichnet und wo ist dann der Fehler bei meiner accesslist Konfiguration? Wie sieht eine aceesslist aus, wo alles hinter der Fritz Box durch den VPN Tunnel geschickt wird?

 

[PeterPawn]

Wie sieht eine aceesslist aus, wo alles hinter der Fritz Box durch den VPN Tunnel geschickt wird?

Was soll man darauf jetzt antworten?

Wenn ich schreibe:

So, wie es hier

( ) in diesem Thread
( ) in diesem (Unter-)Forum
( ) in diesem Board
( ) im Internet

[ gewünschte Fundstelle bitte ankreuzen ]

nachzulesen ist, würde Dich das wirklich weiterbringen oder kommst Du da ohnehin in Kürze von alleine drauf, einfach mal die anderen Beiträge zu lesen?

 

[Overloader]

Ich glaube ich habe jetzt mehr oder weniger die accesslist verstanden.

Um den DNS der Fritz Box weiterhin zu nutzen, aber den gesamten Traffic durch den VPN zu schicken geht folgendes.

                accesslist = "reject udp any any eq 53",
                             "reject udp any any eq 500",
                             "reject udp any any eq 4500",
                             "permit ip any any";

Wenn man nur accesslist = "permit ip any any"; definiert, wird alles, auch die DNS Anfragen, durch den VPN geschickt. Die Daten kommen in beiden Fällen an der pfsense an.

Und damit die VOIP Rufnummern z.B. für Telekom DSL weiterhin funktionieren, müssen die entspr. Ports noch definiert werden. Das sieht dann so aus.

                accesslist = "reject udp any any eq 53",
                             "reject udp any any eq 500",
                             "reject udp any any eq 4500",
                             "reject udp any any eq 5060",
                             "reject udp any any eq 3478",
                             "reject udp any any eq 3479",
                             "reject udp any any range 30000 31000",
                             "reject udp any any range 40000 41000",
                             "permit ip any any";

 

[PeterPawn]

@spätere Leser:
Das ist hier aber ein Sonderfall, daß der Port 53 (also DNS-Abfragen) auch über die VPN-Verbindung gehen könnte ... denn hier hat der Peer eine statische IPv4-Adresse (zumindest sieht die FRITZ!Box-Konfiguration auf der vorherigen Seite so aus).

Wenn der Peer auch erst noch über DNS aufgelöst werden muß, braucht man schon für den Aufbau des Tunnels noch die DNS-Abfrage und darf den DNS-Traffic nicht über den Tunnel senden ... das FRITZ!OS leitet den nicht etwa unverschlüsselt weiter, nur weil der Tunnel noch nicht steht.

Für eine Konstellation, wo die DNS-Abfragen auch durch eine VPN-Verbindung gehen und der Peer trotzdem eine dynamische Adresse mit entsprechendem dynamischen DNS-Namen hat, ist die FRITZ!Box ab Werk nicht geeignet ... so etwas wie die spätere Modifikation der Filter aus der "accesslist" kennt das FRITZ!OS nicht und es sind immer die Filter aus allen aktivierten Verbindungen aktiv (nicht mit "aktiven Verbindungen" zu verwechseln, die dann tatsächlich aufgebaut sind).

Eine Konfiguration ohne die "Sperren" für die IPSec-Ports (500 und 4500) habe ich noch nie probiert (zumindest keine, wo dann ein "permit ip any any" die Liste beschließt) ... Auslöser ist sicherlich auch die Feststellung, daß AVM bei der Verwendung des Windows-Programms für die Konfiguration einer VPN-Verbindung diese beiden Regeln auch setzt, wenn man "alles über die VPN-Verbindung" auswählt (zumindest war das mal so).

Es mag unterschiedliche Implementierungen des WAN-Stacks bei AVM geben und damit auch unterschiedliche Stellen, wo der verschlüsselte Traffic dann wieder "eingeleitet" wird in das normale Routing ... aber es gibt eben auch unterschiedliche Szenarien, bei denen unterschiedliche Protokolle verwendet werden. Es mag ohne die Filter für UDP 500 und 4500 manchmal gut gehen (so wie es sich in #481 ja anhört in dem Satz:

Wenn man nur accesslist = "permit ip any any"; definiert, wird alles, auch die DNS Anfragen, durch den VPN geschickt. Die Daten kommen in beiden Fällen an der pfsense an.

), aber darauf würde ich mich nicht blind verlassen.

Es kann schon ein entscheidender Unterschied sein, ob IKE über UDP 500 und der Rest über ESP (das ist ein Protokoll auf derselben Ebene wie TCP und UDP - es verwendet die IP-Protokollnummer 50) abgewickelt wird oder ob alles - bei Erkennung eines NAT-Devices im Verbindungsweg - über NAT-Traversal (da kommt dann nur noch UDP 4500 zum Einsatz mit einer zusätzlichen Kapselung der Pakete, an denen auch ein NAT-Router "herumspielen" darf) arbeitet.

Sollten die verschlüsselten Pakete an einer Stelle in den WAN-Stack eingespeist werden, wo sie noch einmal an dem Filter aus der "accesslist" vorbeikommen, dann sollte dieser auch dafür sorgen, daß die bereits verschlüsselten Pakete jetzt nicht erneut "selektiert" werden ... genau das machen ja die "reject"-Einträge für die Ports 500 und 4500. Kommen sie da nicht noch einmal vorbei, braucht man sicherlich diese "rejects" nicht wirklich.

Man weiß ja nicht so richtig, um welches Modell einer FRITZ!Box mit welcher FRITZ!OS-Version es sich hier handelt(e) ... es wäre aber auch tatsächlich denkbar, daß AVM die Arbeitsweise des VPN in verschiedenen Versionen unterschiedlich implementiert hat. Aber schaden können diese Regeln für Port 500 und 4500 eigentlich auch nicht (nur in extremen Situationen, wo tatsächlich noch Traffic für diese Ports durch den Tunnel gehen soll) und damit sollte man sie lieber eingetragen lassen bzw. selbst eintragen ... ebenso wie die erwähnte Port 53-Regel, wenn der Peer einen DNS-Namen hat - ansonsten wird der Tunnel niemals aufgebaut werden und im Ergebnis hat man hinter der FRITZ!Box gar kein Internet mehr, weil die Pakete von "any" für "any" einfach verworfen werden.

 

[Shirocco88]

Und damit die VOIP Rufnummern z.B. für Telekom DSL weiterhin funktionieren, müssen die entspr. Ports noch definiert werden.

accesslist =SNIP
"reject udp any any eq 5060",
"reject udp any any eq 3478",
"reject udp any any eq 3479",
"reject udp any any range 30000 31000",
"reject udp any any range 40000 41000",
SNIP

erlaubt die Telekom keine "nomadische" Nutzung von SIP/VOIP am DSL-Anschluß ?
ist nur die eigene WAN-IP erlaubt ?
kann man das ggf im KC anpassen ?