This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM Fritz okay, aber wie auf weitere Subnetze?

Hallo,

die Basis:
SG430 Cluster fullguard
Fritz!Box 7330
Site to Site VPN

UTM lokal 192.168.3.x /24
Layer3 Switch 192.168.3.253
LAN Servernetz 10.101.0.0 / 16
statische Route auf UTM eingetragen, 10.101. Netze sind erreichbar
Fritz lokal 192.168.132.0/24

Ich habe erfolgreich nach https://community.sophos.com/products/unified-threat-management/astaroorg/f/68/t/61792 eine Fritz 7330 an die UTM angebunden. Die UTM hängt in folgendem Subnetz:
192.168.3.0 / 24

Über einen Layer 3 Switch sind noch mehrere Class C Netze angebunden, die ich in 10.101.0.0 /16 zusammenfasse. Die UTM kann diese Netze erreichen, umgekehrt auch.

Von und nach dem neuen Fritz Tunnel ist aber keine Verbindung aus den 10.101er Netzen möglich. Was muss ich noch tun? Routing? NAT?

Kann mir jemand hier helfen?

Danke
Uwe

This thread was automatically locked due to age.

0 ULeuckert over 10 years ago in reply to scorpionking

Ja, so gesehen [;)]

Wer lesen kann ist mal wieder klar im Vorteil.

Okay, zwei Abschnitte angelegt. alles fünfmal kontrolliert. In der FB gibt es jetzt mit dieser vpn.cfg zwei VPN Verbindungen:
LGST-3
LGST-101
Die erste wird aufgebaut, die zweite nicht. In der FB bleibt das Teil grau, in der UTM gibt es:

SA: 	10.101.0.0/16=meine.öfftl..IP.Adresse 		79.210.67.165=192.168.132.0/24

VPN ID:meine.öfftl..IP.Adresse

Error: No connection

	

SA: 	192.168.3.0/24=meine.öfftl..IP.Adresse 		79.210.67.165=192.168.132.0/24

VPN ID: meine.öfftl..IP.Adresse

IKE: Auth PSK / Enc 3DES_CBC / Hash HMAC_SHA1 / Lifetime 3600s / PFS MODP_1024 / DPD

ESP: Enc 3DES_CBC / Hash HMAC_SHA1 / Lifetime 3600s

So sah das gestern auch schon aus.
Kommen wir also zum Kapitel "blöde Fragen":
Muss ich in der UTM jetzt auch was zweites anlegen?

Zum Abschluss nochmal meine jetzige vpn.cfg:


vpncfg {

     connections {

             enabled = yes;

             conn_type = conntype_lan;

             name = "LGST-3";

             always_renew = no;

             reject_not_encrypted = no;

             dont_filter_netbios = yes;

             localip = 0.0.0.0;

             local_virtualip = 0.0.0.0;

             remoteip = meine.öfftl.IP.Adresse;

             remote_virtualip = 0.0.0.0;

             localid {

                     ipaddr =  169.254.1.100;

             }

             remoteid {

                     ipaddr = meine.öfftl.IP.Adresse;

             }

             mode = phase1_mode_idp;

             phase1ss = "alt/all-no-aes/all";

             keytype = connkeytype_pre_shared;

             key = "Wahnsinnsschluessel";

             cert_do_server_auth = no;

             use_nat_t = no;

             use_xauth = no;

             use_cfgmode = no;

             phase2localid {

                     ipnet {

                             ipaddr = 192.168.132.0;

                             mask = 255.255.255.0;

                     }

             }

             phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";

             accesslist = "permit ip any 192.168.3.0 255.255.255.0";

}{

             enabled = yes;

             conn_type = conntype_lan;

             name = "LGST-101";

             always_renew = no;

             reject_not_encrypted = no;

             dont_filter_netbios = yes;

             localip = 0.0.0.0;

             local_virtualip = 0.0.0.0;

             remoteip = meine.öfftl.IP.Adresse;

             remote_virtualip = 0.0.0.0;

             localid {

                     ipaddr =  169.254.1.100;

             }

             remoteid {

                     ipaddr = meine.öfftl.IP.Adresse;

             }

             mode = phase1_mode_idp;

             phase1ss = "alt/all-no-aes/all";

             keytype = connkeytype_pre_shared;

             key = "der gleiche Wahnsinnsschlüssel wie oben";

             cert_do_server_auth = no;

             use_nat_t = no;

             use_xauth = no;

             use_cfgmode = no;

             phase2localid {

                     ipnet {

                             ipaddr = 192.168.132.0;

                             mask = 255.255.255.0;

                     }

             }

             phase2remoteid {

                     ipnet {

                             ipaddr = 10.101.0.0;

                             mask = 255.255.0.0;

                     }

             }            

             phase2ss = "esp-3des-sha/ah-no/comp-no/pfs";

             accesslist = "permit ip any 10.101.0.0 255.255.0.0";

     }

     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";

}

Resultat:
nach Abschaltung meiner SNAT Trixerei ist der Zustand wieder der, dass ich aus dem direkt an der UTM hängenden Netz pingen kann, aus dem Servernetz nicht. Also wie gestern schon. Trace aus 10.101.x.x nach FB (192.168.132.254) geht wieder auf den T-Com Router.

Hab ich schon Danke gesagt?
Und ja, wäre schön wenns noch weiter geht [[[:)]]] [[[:)]]] [[[:)]]]

0 ULeuckert over 10 years ago in reply to ULeuckert

Ich habe mal zum probieren die Verbindung in der UTM geclont (Name Fritz S101), in der ersten nur das eigene LAN 192.168.3.0/24 drin (UTM hat 192.168.3.222) und in der zweiten das angelegte Servernetz eingetragen, welches die UTM über den vorn beschriebenen Layer3 Switch erreicht. Die UTM gibt nun aus:

2015:04:01-16:29:32 LGST-FW-02-1 pluto[6633]: "S_Fritz S101" #1214: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2015:04:01-16:29:32 LGST-FW-02-1 pluto[6633]: "S_Fritz S101" #1214: starting keying attempt 7 of an unlimited number
2015:04:01-16:29:32 LGST-FW-02-1 pluto[6633]: "S_Fritz S101" #1215: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #1214 {using isakmp#1208}

Ich kann damit leider wieder nichts anfangen. Der zweite angezeigte Tunnel in der FB bleibt grau, ping geht nicht.

Gibts noch Leute die Zeit übrig haben hier? [;)]
Cancel
Vote Up 0 Vote Down

Cancel
0 oxident over 8 years ago in reply to ULeuckert

Konnte das Problem eigentlich gelöst werden? Stehe nämlich vor exakt dem gleich Dilemma ;-)
Cancel
Vote Up 0 Vote Down

Cancel
0 x.cr3w over 8 years ago in reply to oxident

Ganz blöde frage. Betreut ihr die Standorte der Fritzboxen? Warum dann nicht das ganze mit RED's oder kleinen UTMs lösen? Die Fritzbox-Leistung wird ja ne kleine SG auch bringen ....

Oder reden wir von privat/use/at/home? bei den dimensionen wohl nicht :D

Ich würd mir sowas nämlich nicht einfangen wollen (mehr probieren als produktives arbeiten :D)

Sophos Platinum Partner
Sophos Certified Architect
(Ceritfied UTM Architect / Certified XG Architect)
Cancel
Vote Up 0 Vote Down

Cancel
0 oxident over 8 years ago in reply to x.cr3w

Nee, ist nur privat auch in der Tat nur zum Probieren.

Ich dachte auch, mit der RED-Lösung könnte man es elegant klären und habe es auch mal per "Software-RED" (also XG's, die als RED fungieren) probiert. Ulkigerweise sah es erst ganz gut aus, scheiterte dann aber daran, dass komischerweise diverse Dienste über diese Art der Verbindung total unzuverlässig wurden. In erster Linie alles, was irgendwie mit RPC oder auch SSL zu tun hatte ... obschon entsprechende Firewall-Regeln für die Zone der REDs okay waren.

Das Ende vom Lied ist für mich jetzt, dass ich SSL-VPN der XG's als Site-To-Site VPN verwende. Das klappt recht stressfrei, obwohl es immer mal wieder Probleme beim morgendlichen DSL-Reconnect gibt (VPN denkt, es wäre noch verbunden ... ist es aber nicht).
Cancel
Vote Up 0 Vote Down

Cancel