FritzBox 7490 VPN Problem ab FritzOS 6.5
Hallo,
ich habe auf einer Fritzbox 7490 nach dem FritzOS Update folgendes Problem mit eingehenden und ausgehenden VPN Verbindungen:
Die FritzBox stellt die Internetverbindung an einem Telekom Business VDSL mit fester IP her an der Box sind zwei VPN Router Cisco 1841 angeschlossen.
Cisco Router 1 terminiert eine IPSEC VPN per Site2Site zu einem anderen Standort wegen Backups
Cisco Router 2 ist aus dem WAN per Port Forwarding UDP 500/4500/10000 für IPSEC über den Cisco VPN-Client erreichbar
Diese Konfiguration funktionierte bis FritzOS 6.3 problemlos. Nach dem Update auf 6.50 kann jeweils nur eine VPN Verbindung genutzt werden.
Ist das Port Forwarding UDP 4500 aktiv kann die VPN von Router 1 nicht zum Standort terminierten, jedoch VPN aus dem WAN zu Router 2 ist möglich.
Deaktiviere ich den Forwarding Eintrag UDP4500 terminiert die VPN von Router 1 zum Standort aber der VPN-Client kann nicht mehr die VPN zu Router 2 aufbauen.
Im Prinzip nutzen beide UDP4500 aber in OS 6.30 wurden die Pakete der von innen terminierten VPN anders behandelt, so dass hier für die established Verbindung
das Port Forwarding nicht greift.
Hat jemand eine Idee außer wieder auf OS 6.30 zurück?
Gruß
Thomas
ich habe auf einer Fritzbox 7490 nach dem FritzOS Update folgendes Problem mit eingehenden und ausgehenden VPN Verbindungen:
Die FritzBox stellt die Internetverbindung an einem Telekom Business VDSL mit fester IP her an der Box sind zwei VPN Router Cisco 1841 angeschlossen.
Cisco Router 1 terminiert eine IPSEC VPN per Site2Site zu einem anderen Standort wegen Backups
Cisco Router 2 ist aus dem WAN per Port Forwarding UDP 500/4500/10000 für IPSEC über den Cisco VPN-Client erreichbar
Diese Konfiguration funktionierte bis FritzOS 6.3 problemlos. Nach dem Update auf 6.50 kann jeweils nur eine VPN Verbindung genutzt werden.
Ist das Port Forwarding UDP 4500 aktiv kann die VPN von Router 1 nicht zum Standort terminierten, jedoch VPN aus dem WAN zu Router 2 ist möglich.
Deaktiviere ich den Forwarding Eintrag UDP4500 terminiert die VPN von Router 1 zum Standort aber der VPN-Client kann nicht mehr die VPN zu Router 2 aufbauen.
Im Prinzip nutzen beide UDP4500 aber in OS 6.30 wurden die Pakete der von innen terminierten VPN anders behandelt, so dass hier für die established Verbindung
das Port Forwarding nicht greift.
Hat jemand eine Idee außer wieder auf OS 6.30 zurück?
Gruß
Thomas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 314277
Url: https://administrator.de/contentid/314277
Ausgedruckt am: 05.11.2024 um 23:11 Uhr
6 Kommentare
Neuester Kommentar
Cisco Router 2 ist aus dem WAN per Port Forwarding UDP 500/4500/10000 f
Wozu soll Port UDP 10000 gut sein ?? Der wird bei IPsec VPNs gar nicht genutzt und stellt eher ein Sicherheitsrisiko dar.Eine laufende Praxis Installation FB / Cisco mit IPsec findest du im hiesigen IPsec Praxis Tutorial:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Alle Router sollten generell NAT Traversal bei IPsec aktiviert haben, was dann ein Port Forwarding von UDP 4500 in den NAT Firewalls erzwingt.
Irgendwo ist also deine Konfig faul auf einem der Endgeräte. Das Tutorial oben sollte dir helfen.
Hallo,
für eingehende Verbindungen (Clients) gibt es ein Portforwarding (UDP 500/4500) auf R2; R1 stellt eine Verbindung zu einem anderen Standort her. Ist das so richtig?
Falls ja, dann war es bisher offenbar so, dass die FB bei ausgehenden NAT (R1) einen anderen Port als udp/4500 gewählt hat. In der neuen FB-Firmware scheint das nicht mehr der Fall zu sein, sodass die Antwortpakete bei R2 ankommen (eingehende NAT-Regel).
Ist Shrew als Ersatz für den Cisco VPN Client eine Option? In Shrew kann man die verwendeten Ziel-Ports einstellen und könnte diese dann auf UDP 500/4500 an R2 weiterleiten.
BB
für eingehende Verbindungen (Clients) gibt es ein Portforwarding (UDP 500/4500) auf R2; R1 stellt eine Verbindung zu einem anderen Standort her. Ist das so richtig?
Falls ja, dann war es bisher offenbar so, dass die FB bei ausgehenden NAT (R1) einen anderen Port als udp/4500 gewählt hat. In der neuen FB-Firmware scheint das nicht mehr der Fall zu sein, sodass die Antwortpakete bei R2 ankommen (eingehende NAT-Regel).
Ist Shrew als Ersatz für den Cisco VPN Client eine Option? In Shrew kann man die verwendeten Ziel-Ports einstellen und könnte diese dann auf UDP 500/4500 an R2 weiterleiten.
BB