Das gilt ohnehin nur, solange man die Verbindung ausschließlich übers GUI konfiguriert. Die Lua-Files "kennen" an der Stelle nur LAN2 bis LAN4 ... man kann aber über die Shell (mittels
Code:
# ctlmgr_ctl w vpn settings/<connection_n>/ipsecbr_interfaces eth0,eth1
z.B. für "LAN1" und "LAN2") auch das LAN1-Interface (also "eth0") in eine "ipsecbrX"-Bridge einbinden. Vermutlich klappt das auch über die "ar7.cfg" und den Import ... habe ich aber selbst nie probiert, weil mir der Shell-Zugang reicht(e).
Theoretisch könnte man wohl auch die Lua-Seiten entsprechend anpassen und dort den Support für "LAN1" ergänzen ... während bei den älteren Modellen ohne WAN-Port die "Reservierung" von LAN1 noch halbwegs nachvollziehbar war, ist das bei den GRX-Boxen ja auch nicht mehr unbedingt der Fall - ich würde hier nicht unbedingt "Vorsatz" von AVM vermuten, wenn bei den Boxen mit zusätzlichem WAN-Port (der ja auch in der LAN-Bridge ist, solange man ihn nicht als WAN-Zugang verwendet) der LAN1-Port in der IPSec-Konfiguration fehlt ... eher tippe ich auf "nicht so wichtig".
Wer die wirklich als IP-Client oder reinen Ethernet-Router betreiben will, der verwendet i.d.R. wahrscheinlich ohnehin den WAN-Port. Wobei der tatsächlich noch den Vorteil hat (zumindest bei meiner 7580), daß der nicht im Bootloader (also in EVA) erreichbar ist ... damit kann auch ein kabelgebundener "Angreifer" auf diesem Port nicht in den FTP-Server und eigene Firmware ins RAM laden.
Leider gilt das (immer noch) nicht für den vierten LAN-Port (also "eth3" aus Interface-Sicht) ... wer den für die Anbindung eines Gastnetzwerks verwendet und dort "unsichere" Geräte unterbringt, der muß auch damit rechnen, daß ihn von dort aus im geeigneten Moment (bei den GRX-Boxen halt nur nach einem PowerOn-Reset) irgendeine Malware in den Hintern beißen kann.
Ähnliches gilt - per se - natürlich auch für die anderen Ports ... wer also einen dieser Ports irgendwohin per VPN "delegieren" will und damit dann davon ausgeht, das dort bei ihm lokal angeschlossene Gerät könne damit das LAN nicht mehr erreichen (aka "gefährden"), der liegt auch nur solange richtig, bis die FRITZ!Box beim PowerOn-Reset ihre Achillesferse entblößt und auf JEDEM der (üblicherweise gelben) Ethernet-Ports auf FTP-Sessions reagiert.
Alle anderen Restriktionen (Gastnetz oder IPSec-Bridge) greifen erst dann, wenn das System bereits läuft ... ja, eigentlich erst dann, wenn der "dsld" die Interfaces anhand der "ar7.cfg" konfiguriert hat (während Teile schon vorher initialisiert werden bzw. zumindest initialisiert werden
könnten).
Da die Aufteilung der Ports bei den FRITZ!Boxen nur "in Software" erfolgt, sind die also keinesweg "sicher voneinander getrennt", solange die Software das nicht entsprechend konfiguriert hat.