Fritz 6360 vor EISFAIR gehängt: Großes Chaos...

[bommelkopp]

Moinsen,
leider muß ich etwas ausholen, um die Probleme zu schildern:

Vor meinem Wechsel von DSL (Versatel) zu Unitymedia (3-play) hatte ich folgende Situation:
Hinter dem DSL-Modem stand ein EISFAIR-PC, der die Einwahl ins Internet übernahm.
Der hat zwei NICs, eth0, eth1, das lokale Netz hatte 192.168.0.0, alle Kisten im LAN feste 192.168.0.x-IPs, der EISRouter die 192.168.0.9 am eth0
Das war auch gleichzeitig das Gateway, sowie der DNS-Server (der sich dann von DNS-Servern vom Provider den Rest holte). Innerhalb des LAN übernahm dann der EIS noch andere Services, neben Filediensten lief da ein Mini-WebServer, Virenscan etc.

Also alles gut.

Jetzt habe ich eine Fritz 6360 vor den EIS gehängt, und dachte, daß der EIS so weiterlaufen könne.
Die Fritz hat jetzt die 192.168.178.1, und das eth1 vom EIS (was vorher am DSL-Modem steckte) die 192.168.178.2

Vom lokalen Netz kann ich die Fritz anpingen, ich kann aufs Internet zugreifen, soweit ok.
Vom LAN aus kann ich alle bekannten IPs anpingen.

Zur Fritz habe ich einen dyndns-Zugang eingerichtet, ich komme von außerhalb auf die Adminoberfläche der Fritz. Auch ok.

Aber jetzt kommen die Probleme:


Erstes Problem: Portforwarding
Möchte den HTTP-Server des EIS von außen erreichen. Also Portweiterleitung mit Eingangsport 4567 auf den Eisfair-Server mit Port 80 gelegt. Geht nicht.
Als Exposed Hort probiert - geht nicht. Routing des EIS abgeschaltet - geht immer noch nicht. Andere Dienste werden scheinbar auch nicht an den EIS durchgereicht (ssh, telnet, ping).

Zweites Problem: VPN
Habe mit der Anleitung fürs IPhone und den entsprechenden Änderungen fürs Android-Smartphone die Konfigurationsdatei erstellt, mir der ich dir Fritz beglückt habe.
Mit VPNC kann ich mich via GPRS connecten, wird mir in der Fritz auch angezeigt. Kann über die Androidshell als root einen Ping auf die 192.168.178.2 ausführen, das wars aber auch.
Die 192.168.178.1 kann ich genausowenig anpingen wie die irgendwen im 192.168.0.0-er Netz. Grrr.

Drittes Problem: FritzAppFon
Habe sowohl die Labor-Version als auch die Stable(?) ausprobiert.
Über WLAN aus dem lokalen Netz (da hängt noch ein DLINK TP 14irgendwas rum, funktioniert auch bestens, mit dem wird sich zuhause mit dem Smartphone verknüpft) kann ich die Fritz zwar sehen, aber der Connect klappt nicht.
Hier die Frage: MUSS ich mich dafür mit dem WLAN der Fritz verbinden, oder geht das auch über das LAN?

Die weiteren Probleme sind kleinerer Natur, ich denke auch, das reicht fürs Erste.

Falls irgendjemand eine Idee hat, wo der Denkfehler ist - ich bin für jeden Ansatzpunkt dankbar.

Gruß
Bommel

 

[Telefonmännchen]

Ich würde das Routing des EIS abschalten und mit eth0 an die FritzBox hängen. Die soll das Routing übernehmen. Mit den zwei NIC handelst Du Dir durch die getrennten Netze nur zusätzliche Probleme ein. Die wären sicherlich zu lösen, aber verkomplizieren das Handling.

Alternativ könntest Du erst mal der FritzBox über die statischen Routen sagen, daß sie das 192.168.0.0-Netz über die 192.168.78.2 ansprechen soll (wenn der EIS weiterhin routen soll). Übrigens funktioniert das Portforwarding zuverlässig nur bei gleichen Ports. Sollte zwar nicht so sein, zumal das Webinterface anderes suggeriert, aber probiere es mal aus (also Port 80 auf 80 forwarden).

Zu Deinem VPN-Problem: Kann es sein, daß Du als Netzwerk nur die ...178.2 und nicht die ...0 angegeben hast. Das beschriebene Verhalten lässt darauf schließen. Die entsprechenden cfg-Dateien lassen sich auch manuell editieren.

Zur App-Problematik kann ich nichts sagen, nutze ich nicht.

Gruß Telefonmännchen

 

[bommelkopp]

Ich würde das Routing des EIS abschalten und mit eth0 an die FritzBox hängen.

Also nur noch 192.168.178-er Adressen??

Alternativ könntest Du erst mal der FritzBox über die statischen Routen sagen, daß sie das 192.168.0.0-Netz über die 192.168.78.2 ansprechen soll (wenn der EIS weiterhin routen soll).

Das steht auch so in der Benutzeroberfläche...

Übrigens funktioniert das Portforwarding zuverlässig nur bei gleichen Ports.

Kein Witz??

Zu Deinem VPN-Problem: Kann es sein, daß Du als Netzwerk nur die ...178.2 und nicht die ...0 angegeben hast.

Hm. die Serverconfig sieht so aus:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "blauser";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.178.201;
                remoteid {
                        user_fqdn = "blauser";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "xxxxxxxxxxxxxxxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.201;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.178.0 255.255.255.0 192.168.178.201 255.255.255.255";
        }
        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";

Die Clientige:

version {
        revision = "$Revision: 1.30 $";
        creatversion = "1.1";
}


pwcheck {
}


datapipecfg {
        security = dpsec_quiet;
        icmp {
                ignore_echo_requests = no;
                destunreach_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
                timeexceeded_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
                echoreply_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
        }
        masqtimeouts {
                tcp = 15m;
                tcp_fin = 2m;
                tcp_rst = 3s;
                udp = 5m;
                icmp = 30s;
                got_icmp_error = 15s;
                any = 5m;
                tcp_connect = 6m;
                tcp_listen = 2m;
        }
        ipfwlow {
                input {
                }
                output {
                }
        }
        ipfwhigh {
                input {
                }
                output {
                }
        }
        NAT_T_keepalive_interval = 20;
}


targets {
        policies {
                name = "bladyn.dyndns.info";
                connect_on_channelup = no;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                virtualip = 192.168.178.201;
                remoteip = 0.0.0.0;
                remotehostname = "bladyn.dyndns.info";
                localid {
                        user_fqdn = "blauser";
                }
                mode = mode_aggressive;
                phase1ss = "all/all/all";
                keytype = keytype_pre_shared;
                key = "xxxxxxxxxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipaddr = 192.168.178.201;
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.178.0 255.255.255.0";
                wakeupremote = no;
        }
}


policybindings {
}

Ich bin davon ausgegangen, daß ich das 192.168.0.x-er Netz sehen und bearbeiten kann, wenn ich im 192.168.178-er bin.

 

[Telefonmännchen]

Also nur noch 192.168.178-er Adressen??

Das wäre die Konsequenz daraus. Oder eben ein anderer Bereich, aber eben alle im gleichen.

Kein Witz??

Nö, leider nicht. Bin ich auch schon mal drüber gestolpert. Da ich es aus Konsequenz daraus geändert eingerichtet habe und eben den SSH-Server dahinter auf dem passenden Port lauschen lasse, habe ich das über die verschiedenen Firmwarversionen nicht mehr verfolgt. Scheint aber immer noch so zu sein. Ich habe so den SSH-Server durch den hohen Port aus der Schusslinie der Script-Kiddies gebracht.

Die cfg-Dateien sehen eigentlich unauffällig auf, bis auf...

Ich bin davon ausgegangen, daß ich das 192.168.0.x-er Netz sehen und bearbeiten kann, wenn ich im 192.168.178-er bin.

Eben nicht, das verhindert die 255.255.255.0-er Netzmaske. Sie lässt Dir nur den Zugriff auf den Adressbereich des ...178.0-er Netz zu (256 Adressen). Diese müsstest Du ggf. auf 255.255.0.0 erweitern. Die Daten gehen schon auf der Client-Seite nicht mehr über den Tunnel, weil dieser schon mit 255.255.255.0-er Netzmaske läuft.

Gruß Telefonmännchen