In dem Trace-Tool standen diese Einträge bei mir nicht drin. Wo genau hast du die her?
Trace-Tool. Debug-Level einstellen, die drei Logs mit "Open Log" starten und Verbindung aufbauen. Irgendwann stehen die Daten dann in den konfigurierten Verzeichnissen/Dateien ("Options" im Trace-Tool).
Die Access Lists verstehe ich immer noch nicht wirklich. Eigentlich sollten die doch nur für den einen VPN Tunnel relevant sein, in dem sie konfiguriert sind, oder nicht?
Nein, definitiv nicht. Die "accesslist" jeder aktivierten (nicht nur jeder aufgebauten) Verbindung wird sofort als Filter wirksam, nur so ist ja auch der Aufbau einer "on demand"-Verbindung möglich, wenn einer der Filter matched.
Wenn ich die Zeile "permit udp any any eq 53" in die VPN Access List einfüge, funktioniert aus meinem LAN keine DNS auflösung mehr. Ping ins Internet geht.
Was passiert jetzt? Der UDP-Verkehr jedes lokalen Hosts (das erste "any") an jede beliebige Adresse (das zweite "any"), der von oder an Port 53 gerichtet ist und - das ist das Entscheidende - am "dev dsl" vorbeikommt (nur da greifen die Transformationen), wird in den Tunnel gestopft, für den diese "accesslist" aktiviert ist. Solange also aus dem Tunnel keine Antworten auf diese Pakete kommen, ist es nur folgerichtig, wenn DNS nicht mehr geht ... erst recht dann, wenn der Tunnel vielleicht gar nicht aufgebaut ist; dann verschwinden UDP-Pakete einfach im Nirwana.
1. ein permit Statement nichts droppen sollte und
Macht es ja auch nicht, s.o. ... es leitet den Verkehr eben um - das Konzept ist z.B. beim Shrewsoft-Client mit den "Policies" und bei Linux-Kernel mit den "Transformations" (ip xfrm) dasselbe (wahrscheinlich nutzt AVM sogar diesen Mechanismus im Kernel, zumindest zum Teil).
2. eine VPN Access List keinen Impact auf meinen LAN-to-WAN Traffic haben sollte
Das ist nun mal keine "Firewall" oder etwas ähnliches ... es ist ein "Selektor". Was paßt, wird in den Tunnel geschubst, der Rest wandert weiter im Stack auf "dev dsl" und landet dann irgendwann mal am (wirklich) externen Interface.
Damit ist aber sicherlich auch klar, wieso "permit ip any any" (also wirklich aller Verkehr durch den Tunnel, u.U. sogar den, der ja wenigstens zum IPSec-Gateway auf der Gegenseite direkt passieren muß) nicht funktioniert. Ob das theoretisch machbar wäre (also ob die gekapselten Pakete erst "hinter" der Selektion wieder injiziert werden), wollte ich schon lange mal testen ... aber so wichtig ist mir das Thema auch nicht und "reject_not_encrypted=yes;" ist an der Stelle ohnehin besser, weil der erst wirksam wird (so jedenfalls meine Kenntnisse), wenn die Verbindung erfolgreich aufgebaut wurde.