@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.
