22
Company Connect und VPN (UMTS Clients)
ADMClients (Acer Notebooks) werden via T-Mobile web 'n walk über VPN an unser Haus angebunden
Bis gestern hatten wir einen SDSL Anschluss auf den die ADMs sich via VPN in unser Haus einloggen konnten.
Gestern haben wir unseren Company Connect der T-Com in Betrieb genommen. Internetzugang des Hauses funktioniert tadellos.
Nur ab diesem Zeitpunkt ist es nicht mehr möglich sich via VPN auf der Firewall einzuloggen. Fehler auf den Clients "unbekannter Fehler".
Die Clients kommen auf der Firewall an. Ich poste mal das FW-Log. (Watchguard x700)
11/16/09 16:15 tunneld[126]: connected to 88.128.12.230:1083
11/16/09 16:15 tunneld[126]: 156 bytes received from socket 10
11/16/09 16:15 tunneld[126]: recv start-control-connection-request from 88.128.12.230
11/16/09 16:15 tunneld[126]: sent start-control-connection-reply
11/16/09 16:15 tunneld[126]: 168 bytes received from socket 10
11/16/09 16:15 tunneld[126]: recv outgoing-call-request from 88.128.12.230
11/16/09 16:15 tunneld[126]: gre rule added for 88.128.12.230
11/16/09 16:15 tunneld[126]: spawned PPTPD with process id #4289
11/16/09 16:15 tunneld[126]: sent outgoing-call-reply
11/16/09 16:15 tunneld[4289]: starting PPTPD server
11/16/09 16:15 tunneld[4289]: pptpd
11/16/09 16:15 tunneld[4289]: silent
11/16/09 16:15 tunneld[4289]: 192.168.1.7:192.168.1.195
11/16/09 16:15 tunneld[4289]: -vj
11/16/09 16:15 tunneld[4289]: remotename
11/16/09 16:15 tunneld[4289]: 88.128.12.230
11/16/09 16:15 tunneld[4289]: gre
11/16/09 16:15 tunneld[4289]: 0:0
11/16/09 16:15 tunneld[4289]: channel
11/16/09 16:15 tunneld[4289]: 0
11/16/09 16:15 tunneld[4289]: +chap
11/16/09 16:15 tunneld[4289]: dns-addr
11/16/09 16:15 tunneld[4289]: *.*:*.*
11/16/09 16:15 tunneld[4289]: dns-addr
11/16/09 16:15 tunneld[4289]: 192.168.*.*
11/16/09 16:15 tunneld[4289]: nbns-addr
11/16/09 16:15 tunneld[4289]: 192.168.0.1
11/16/09 16:15 tunneld[4289]: nbns-addr
11/16/09 16:15 tunneld[4289]: 192.168.0.2
11/16/09 16:15 tunneld[4289]: debug
11/16/09 16:15 tunneld[4289]: required_group
11/16/09 16:15 tunneld[4289]: pptp_users
11/16/09 16:15 tunneld[4289]: ccp-max-reset
11/16/09 16:15 tunneld[4289]: 257
11/16/09 16:15 tunneld[4289]: mppecomp
11/16/09 16:15 tunneld[4289]: nodrop
11/16/09 16:15 tunneld[4289]: nocomp
11/16/09 16:15 tunneld[4289]: stateless
11/16/09 16:15 tunneld[4289]: proxyarp
11/16/09 16:15 tunneld[4289]: setpptpmtu
11/16/09 16:15 tunneld[4289]: 1436
11/16/09 16:15 tunneld[126]: rcvd SIGCHLD--ignoring
11/16/09 16:15 tunneld[126]: child pid 4289 died
11/16/09 16:15 tunneld[126]: child pid 4289 died without us killing it
11/16/09 16:15 tunneld[126]: killing tunnel from 88.128.12.230
11/16/09 16:15 tunneld[126]: killing child pid 4289
11/16/09 16:15 tunneld[126]: setting channel 192.168.1.7:192.168.1.195 to be re-used
Anfangs hatten wir ähliche Einträge als auf dem UMTS Karten noch der Standard APN eingetragen war. Aber ich habe auf dem CompanyConnect Endgerät ja keine Möglichkeit etwas zu konfigurieren.
Der T-Com Techniker mit dem ich gestern sprach konnte mir glaub ich nicht folgen was ich überhaupt von ihm will und warum ich ihn vom Feierabend abhalte.
Muss man dazu irgendwelche Voraussetzungen schafen? Hat jemand Erfahrung mit diesem Produkt. Vorschläge? Wäre sehr dringend!
Danke schon mal!
Bis gestern hatten wir einen SDSL Anschluss auf den die ADMs sich via VPN in unser Haus einloggen konnten.
Gestern haben wir unseren Company Connect der T-Com in Betrieb genommen. Internetzugang des Hauses funktioniert tadellos.
Nur ab diesem Zeitpunkt ist es nicht mehr möglich sich via VPN auf der Firewall einzuloggen. Fehler auf den Clients "unbekannter Fehler".
Die Clients kommen auf der Firewall an. Ich poste mal das FW-Log. (Watchguard x700)
11/16/09 16:15 tunneld[126]: connected to 88.128.12.230:1083
11/16/09 16:15 tunneld[126]: 156 bytes received from socket 10
11/16/09 16:15 tunneld[126]: recv start-control-connection-request from 88.128.12.230
11/16/09 16:15 tunneld[126]: sent start-control-connection-reply
11/16/09 16:15 tunneld[126]: 168 bytes received from socket 10
11/16/09 16:15 tunneld[126]: recv outgoing-call-request from 88.128.12.230
11/16/09 16:15 tunneld[126]: gre rule added for 88.128.12.230
11/16/09 16:15 tunneld[126]: spawned PPTPD with process id #4289
11/16/09 16:15 tunneld[126]: sent outgoing-call-reply
11/16/09 16:15 tunneld[4289]: starting PPTPD server
11/16/09 16:15 tunneld[4289]: pptpd
11/16/09 16:15 tunneld[4289]: silent
11/16/09 16:15 tunneld[4289]: 192.168.1.7:192.168.1.195
11/16/09 16:15 tunneld[4289]: -vj
11/16/09 16:15 tunneld[4289]: remotename
11/16/09 16:15 tunneld[4289]: 88.128.12.230
11/16/09 16:15 tunneld[4289]: gre
11/16/09 16:15 tunneld[4289]: 0:0
11/16/09 16:15 tunneld[4289]: channel
11/16/09 16:15 tunneld[4289]: 0
11/16/09 16:15 tunneld[4289]: +chap
11/16/09 16:15 tunneld[4289]: dns-addr
11/16/09 16:15 tunneld[4289]: *.*:*.*
11/16/09 16:15 tunneld[4289]: dns-addr
11/16/09 16:15 tunneld[4289]: 192.168.*.*
11/16/09 16:15 tunneld[4289]: nbns-addr
11/16/09 16:15 tunneld[4289]: 192.168.0.1
11/16/09 16:15 tunneld[4289]: nbns-addr
11/16/09 16:15 tunneld[4289]: 192.168.0.2
11/16/09 16:15 tunneld[4289]: debug
11/16/09 16:15 tunneld[4289]: required_group
11/16/09 16:15 tunneld[4289]: pptp_users
11/16/09 16:15 tunneld[4289]: ccp-max-reset
11/16/09 16:15 tunneld[4289]: 257
11/16/09 16:15 tunneld[4289]: mppecomp
11/16/09 16:15 tunneld[4289]: nodrop
11/16/09 16:15 tunneld[4289]: nocomp
11/16/09 16:15 tunneld[4289]: stateless
11/16/09 16:15 tunneld[4289]: proxyarp
11/16/09 16:15 tunneld[4289]: setpptpmtu
11/16/09 16:15 tunneld[4289]: 1436
11/16/09 16:15 tunneld[126]: rcvd SIGCHLD--ignoring
11/16/09 16:15 tunneld[126]: child pid 4289 died
11/16/09 16:15 tunneld[126]: child pid 4289 died without us killing it
11/16/09 16:15 tunneld[126]: killing tunnel from 88.128.12.230
11/16/09 16:15 tunneld[126]: killing child pid 4289
11/16/09 16:15 tunneld[126]: setting channel 192.168.1.7:192.168.1.195 to be re-used
Anfangs hatten wir ähliche Einträge als auf dem UMTS Karten noch der Standard APN eingetragen war. Aber ich habe auf dem CompanyConnect Endgerät ja keine Möglichkeit etwas zu konfigurieren.
Der T-Com Techniker mit dem ich gestern sprach konnte mir glaub ich nicht folgen was ich überhaupt von ihm will und warum ich ihn vom Feierabend abhalte.
Muss man dazu irgendwelche Voraussetzungen schafen? Hat jemand Erfahrung mit diesem Produkt. Vorschläge? Wäre sehr dringend!
Danke schon mal!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 129523
Url: https://administrator.de/forum/company-connect-und-vpn-umts-clients-129523.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
22 Kommentare
Neuester Kommentar
Da DAS vermutlich nicht dein Problem ist bleibt folgendes:
Leider bist du sehr oberflächlich in der Beschreibung des VPNs und auch des Anschlussszenarios.
Nach der Fehlermeldung sieht es nach einem MTU Problem aus....das kann man aber nur raten. Das VPN Protokoll ist nach der Logmeldung PPTP.
Wenn ihr einen neuen Router für den Company Connect Anschluss bekommen habt und der NAT macht muss dort logischerweise natürlich ein Port Forwarding für PPTP (TCP 1723 und GRE) eingetragen sein auf die IP der FW !!
VPNs einrichten mit PPTP
Macht die FW weiterhin das NAT muss das nicht sein. Leider wird das aus deiner Beschreibung nicht klar.
Der PPTP Prozess stirbt nach Setzen der MTU auf 1436. Vermutlich ist dieser Wert für den PPTP Tunnel bei deiner FW noch zu groß, deshalb solltest du den mal verkleinern.... Ist aber jetzt aufgrund fehlender Details nur geraten...
Leider bist du sehr oberflächlich in der Beschreibung des VPNs und auch des Anschlussszenarios.
Nach der Fehlermeldung sieht es nach einem MTU Problem aus....das kann man aber nur raten. Das VPN Protokoll ist nach der Logmeldung PPTP.
Wenn ihr einen neuen Router für den Company Connect Anschluss bekommen habt und der NAT macht muss dort logischerweise natürlich ein Port Forwarding für PPTP (TCP 1723 und GRE) eingetragen sein auf die IP der FW !!
VPNs einrichten mit PPTP
Macht die FW weiterhin das NAT muss das nicht sein. Leider wird das aus deiner Beschreibung nicht klar.
Der PPTP Prozess stirbt nach Setzen der MTU auf 1436. Vermutlich ist dieser Wert für den PPTP Tunnel bei deiner FW noch zu groß, deshalb solltest du den mal verkleinern.... Ist aber jetzt aufgrund fehlender Details nur geraten...
Hallo und danke für die Antwort.
Wie gesagt hat sich ja seit gestern nichts an der FW-Config geändert. Lediglich der Company Connect statt des SDSL ist anders.
das protokoll ist pptp ja. sry. Die VPN Verbindungen haben bis zur Umstellung ja super funktioniert. Ich hätte angenommen dass man über zu treffende Änderungen von der Telekom unterrichtet wird wenn sich Rahmenbedingungen ändern, aber nein.
ob der Router des Company Connect jetzt das NAT übernimmt ist mir noch nicht klar. Dann würde deine Erklärung sinn machen. Das werde ich mal anbringen und prüfen lassen. Der Techniker der den Anschluss verlegt hat konnte mir so gut wie gar nichts sagen. Und die Hotline ist mal sowas von .... naja kennt man ja.
Also danke fürs erste! Hat mir sehr geholfen.
Wie gesagt hat sich ja seit gestern nichts an der FW-Config geändert. Lediglich der Company Connect statt des SDSL ist anders.
das protokoll ist pptp ja. sry. Die VPN Verbindungen haben bis zur Umstellung ja super funktioniert. Ich hätte angenommen dass man über zu treffende Änderungen von der Telekom unterrichtet wird wenn sich Rahmenbedingungen ändern, aber nein.
ob der Router des Company Connect jetzt das NAT übernimmt ist mir noch nicht klar. Dann würde deine Erklärung sinn machen. Das werde ich mal anbringen und prüfen lassen. Der Techniker der den Anschluss verlegt hat konnte mir so gut wie gar nichts sagen. Und die Hotline ist mal sowas von .... naja kennt man ja.
Also danke fürs erste! Hat mir sehr geholfen.
Zur Info.
Wir haben einen APN auf den UMTS Karten der öffentliche IPs verteilt. Auf dieses Problem sind wir auch schon gestoßen ;o)
Wie gesagt der Zugang hat zum SDSL funktioniert und hat erst seit Umstellung auf Company Connect das Problem "unbekannter Fehler".
danke nochmal
Wir haben einen APN auf den UMTS Karten der öffentliche IPs verteilt. Auf dieses Problem sind wir auch schon gestoßen ;o)
Wie gesagt der Zugang hat zum SDSL funktioniert und hat erst seit Umstellung auf Company Connect das Problem "unbekannter Fehler".
danke nochmal
Aussage T-Com.
Cisco Router gibt den gesamten TCP/IP Verkehr so weiter wie er ankommt. Mit Ausnahme von SNMP.
Jetzt bin ich wieder am Anfang und die T-Com interessiert das nicht die Bohne!
Cisco Router gibt den gesamten TCP/IP Verkehr so weiter wie er ankommt. Mit Ausnahme von SNMP.
Jetzt bin ich wieder am Anfang und die T-Com interessiert das nicht die Bohne!
hallo sandro
ich kann es dir im moment leider nicht sagen,
habe mit umts anbindungen keine erfahrungen
jedoch denke ich, das du bei aqui an der richtigen adresse bist,
wenn du ihn nochmals höflich und nett bittest
hilft er dir gerne bestimmt weiter
info:
ich würde den externen login erstmal über einen standard pc an standard DSL ausprobieren
danach würde ich weiterhin erstmal auf umts verzichten und es mit dem 02 oder ähnlichem
stick, (gibt es probeweise), versuchen.
wenn dass alles funktioniert, dann wäre ich mir sicher, es liegt an deinem umts.
wenn ja, austauschen oder zähne ausbeissen bis es funktioniert.
für mich ist ein support auf dieser ebene immer schwierig, wenn ich es
nicht vor mich liegen habe.
dennoch kann ich nachempfinden.
viel glück noch
lg
ich kann es dir im moment leider nicht sagen,
habe mit umts anbindungen keine erfahrungen
jedoch denke ich, das du bei aqui an der richtigen adresse bist,
wenn du ihn nochmals höflich und nett bittest
hilft er dir gerne bestimmt weiter
info:
ich würde den externen login erstmal über einen standard pc an standard DSL ausprobieren
danach würde ich weiterhin erstmal auf umts verzichten und es mit dem 02 oder ähnlichem
stick, (gibt es probeweise), versuchen.
wenn dass alles funktioniert, dann wäre ich mir sicher, es liegt an deinem umts.
wenn ja, austauschen oder zähne ausbeissen bis es funktioniert.
für mich ist ein support auf dieser ebene immer schwierig, wenn ich es
nicht vor mich liegen habe.
dennoch kann ich nachempfinden.
viel glück noch
lg
Hi und danke für die antwort amoretuo,
zu deinem Tip -> Habe ich natürlich gestern schon getan ;o)
Aber wie gesagt. ALLE Zugänge haben gestern mit SDSL ja noch funktioniert. Auch die stationären Zugänge sind betroffen. ALLE VPN Verbindungen.
thx
zu deinem Tip -> Habe ich natürlich gestern schon getan ;o)
Aber wie gesagt. ALLE Zugänge haben gestern mit SDSL ja noch funktioniert. Auch die stationären Zugänge sind betroffen. ALLE VPN Verbindungen.
thx
OK ob der Router NAT macht oder nicht, siehst du ja auch daran ob du an der FW eine öffentliche IP Adresse hast. Vermutlich routet der CC Router also nur ein kleines Subnetz auf euch.
Dann solltest du weiter in Richtung MTU suchen. Mach von der FW mal ein paar MTU ping Versuche was die max. MTU ist die die neue Verbindung übertragen kann. Ggf. solltest du dann die FW Konfig nochmal anpassen.
Denn du kannst ja sehen das der PPTP Daemon auf der FW stirbt mit einem SIGCHLD--ignoring wenn er den MTU Wert von 1436 setzt. Da stimmt also was an der Konfig nicht !
Ggf. ist das aber auch ein Firmware Bug in der FW. Hast du da die neueste Firmware geflasht ??
Dann solltest du weiter in Richtung MTU suchen. Mach von der FW mal ein paar MTU ping Versuche was die max. MTU ist die die neue Verbindung übertragen kann. Ggf. solltest du dann die FW Konfig nochmal anpassen.
Denn du kannst ja sehen das der PPTP Daemon auf der FW stirbt mit einem SIGCHLD--ignoring wenn er den MTU Wert von 1436 setzt. Da stimmt also was an der Konfig nicht !
Ggf. ist das aber auch ein Firmware Bug in der FW. Hast du da die neueste Firmware geflasht ??
telekom company connect MTU 1500
arcor bzw. vodafone 1492
arcor bzw. vodafone 1492
exakt aqui. an der firewall habe ich eine öffentliche adresse die uns von der Telekom vorgeschlagen wurde.
Die Konfig war doch so mit dem SDSL Anschluss ebenfalls in Betrieb.
Ping mit 1436 geht mit zeit=28 ms durch.
1500 frisst der Anschluss scheinbar nicht da er dann nach fragmentierung schreit.
noch ne andere idee?
Die Konfig war doch so mit dem SDSL Anschluss ebenfalls in Betrieb.
Ping mit 1436 geht mit zeit=28 ms durch.
1500 frisst der Anschluss scheinbar nicht da er dann nach fragmentierung schreit.
noch ne andere idee?
So so..von der Telekom vorgeschlagen d.h. ihr wart nicht in der Lage euch aus eurem zugewiesenen Subnetz selber eine korrekte IP auszusuchen.... Mmmmhhh, wenns an solchen Basics schon scheitert..
OK, variier mal die MTU Größe. Ggf. hilft das.
Ansonsten kannst du nur einen Wireshark Sniffer oder MS NetMonitor nehmen am Client und den PPTP Sessionaufbau mal mitsniffern. Da siehst du dann sofort wo der Hase im Pfeffer liegt !
OK, variier mal die MTU Größe. Ggf. hilft das.
Ansonsten kannst du nur einen Wireshark Sniffer oder MS NetMonitor nehmen am Client und den PPTP Sessionaufbau mal mitsniffern. Da siehst du dann sofort wo der Hase im Pfeffer liegt !
was heisst nicht in der Lage? lol
ich weiss ja nicht wann zu zuletzt einen company connect geordert hast aber es läuft so ab:
du kaufst das Produkt Company Connect der Telekom. Die teilen dir dann deinen IP-Kreis mit.
8 IPs von denen wir 5 zur freien Verfügung haben.
Eine dieser 8 IPs steht für den Router fest und ist voreingestellt. Die restlichen 5 kann man nutzen.
Glaub du verwechselst da was.
ich weiss ja nicht wann zu zuletzt einen company connect geordert hast aber es läuft so ab:
du kaufst das Produkt Company Connect der Telekom. Die teilen dir dann deinen IP-Kreis mit.
8 IPs von denen wir 5 zur freien Verfügung haben.
Eine dieser 8 IPs steht für den Router fest und ist voreingestellt. Die restlichen 5 kann man nutzen.
Glaub du verwechselst da was.
Nein, denn vermutlich verstehst du nichts von IP Subnetting...sorry. Ist ja logisch das das so abgeht.
Beispiel:
Angenommen du bekommst die 85.10.1.0 als öffentliches CC Netzwerk mit einer 29 Bit Maske (255.255.255.248), was dann genau deiner Beschreibung entspricht.
Theoretisch hätte man dann die Host IP Adressen von .0 bis .7 allerdings fallen die .0 und auch die .7 weg denn die dürfen nicht vergeben werden da Netz selber bzw. Broadcast Adresse dieses Netzes. (Alle Hostbits 0 bzw. 1)
Bleibt also die 85.10.1.1 bis 85.10.1.6 übrig (6 Adressen) !
Tunlichst legt die Telekom die Router IP selber entweder ganz ans unterste Ende oder ganz nach oben also entweder .1 oder .6 im Beispiel.
Den Rest der 5 IP Adressen darf man sich dann selbst vergeben nach Gusto.
Selber wählt man bei einem sauberen IP Design dann das andere (freie) Ende für seinen Router und den Rest der Adressen für Server oder was auch immer.
Dafür muss man die Telekom nicht fragen und sich auch nix zuweisen lassen !
So, und nicht anders ist das bei einem Company Connect. Wenn doch, hast du dich als Netzwerk Dummie von der T-Com gängeln lassen !!
Letztlich aber völlig egal, denn DAS hat mit deinem PPTP Problem rein gar nix zu tun !
Beispiel:
Angenommen du bekommst die 85.10.1.0 als öffentliches CC Netzwerk mit einer 29 Bit Maske (255.255.255.248), was dann genau deiner Beschreibung entspricht.
Theoretisch hätte man dann die Host IP Adressen von .0 bis .7 allerdings fallen die .0 und auch die .7 weg denn die dürfen nicht vergeben werden da Netz selber bzw. Broadcast Adresse dieses Netzes. (Alle Hostbits 0 bzw. 1)
Bleibt also die 85.10.1.1 bis 85.10.1.6 übrig (6 Adressen) !
Tunlichst legt die Telekom die Router IP selber entweder ganz ans unterste Ende oder ganz nach oben also entweder .1 oder .6 im Beispiel.
Den Rest der 5 IP Adressen darf man sich dann selbst vergeben nach Gusto.
Selber wählt man bei einem sauberen IP Design dann das andere (freie) Ende für seinen Router und den Rest der Adressen für Server oder was auch immer.
Dafür muss man die Telekom nicht fragen und sich auch nix zuweisen lassen !
So, und nicht anders ist das bei einem Company Connect. Wenn doch, hast du dich als Netzwerk Dummie von der T-Com gängeln lassen !!
Letztlich aber völlig egal, denn DAS hat mit deinem PPTP Problem rein gar nix zu tun !
Jesus, sag mal hast du noch andere Probleme.
Man bezahlt für eine Dienstleistung oder einen Service wie einen Internetzugang.
(Achtung jetzt kommt es kaufmännisch. Schwierig für nen nerd wie dich)
Dann muss die bezahlte Leistung auch mit den übergebenen Randbedingungen funktionieren. Punkt. Und ob ich jetzt die erste oder letzte IP verwende muss aus kaufmännischer Sicher ### egal sein. Und das ist MEIN Ansatz.
Es geht darum für eine Anforderung schnellstmöglich eine Lösung zu finden.
Wenn du in daraus ein Netzdesign aufziehen willst dann mach das ruhig. Ich will das ding wie besprochen anstecken und es muss dann laufen. Weil für den Rest hab ich keine Zeit!
Du musst ja Zeit haben, was man an deinen knapp 14000 Beiträgen ja sieht.
Aber fang nicht an Leute zu beleidigen weil sie sich nicht in dem Maße mit einer Thematik befassen können wie du. Denn diese Leute haben evtl. noch ein paar andere Themen die sie in der gleichen Zeit abdecken müssen.
Das imho zeigt nur deine Arroganz und deinen niedrigen EQ.
Also halt dich doch einfach aus dem Thread raus Freund ;o)
Man bezahlt für eine Dienstleistung oder einen Service wie einen Internetzugang.
(Achtung jetzt kommt es kaufmännisch. Schwierig für nen nerd wie dich)
Dann muss die bezahlte Leistung auch mit den übergebenen Randbedingungen funktionieren. Punkt. Und ob ich jetzt die erste oder letzte IP verwende muss aus kaufmännischer Sicher ### egal sein. Und das ist MEIN Ansatz.
Es geht darum für eine Anforderung schnellstmöglich eine Lösung zu finden.
Wenn du in daraus ein Netzdesign aufziehen willst dann mach das ruhig. Ich will das ding wie besprochen anstecken und es muss dann laufen. Weil für den Rest hab ich keine Zeit!
Du musst ja Zeit haben, was man an deinen knapp 14000 Beiträgen ja sieht.
Aber fang nicht an Leute zu beleidigen weil sie sich nicht in dem Maße mit einer Thematik befassen können wie du. Denn diese Leute haben evtl. noch ein paar andere Themen die sie in der gleichen Zeit abdecken müssen.
Das imho zeigt nur deine Arroganz und deinen niedrigen EQ.
Also halt dich doch einfach aus dem Thread raus Freund ;o)
hallo sandro
bei der company connect ist es wichtig die ip adressen einzuhalten.
1.) = Match
2.) = Gateway
3.) = Broadcast
4.-5.) = frei verfügbar
es ist auch möglich, das du die gateway nicht eingetragen hast
ansonsten schreibst du bitte
rafiki
oder
dani
an. die wissen eigentlich alles.
und immer höflich bleiben, cool bleiben.
bei der company connect ist es wichtig die ip adressen einzuhalten.
1.) = Match
2.) = Gateway
3.) = Broadcast
4.-5.) = frei verfügbar
es ist auch möglich, das du die gateway nicht eingetragen hast
ansonsten schreibst du bitte
rafiki
oder
dani
an. die wissen eigentlich alles.
und immer höflich bleiben, cool bleiben.
Ich hab vielleicht ein Denkanstoß.
X700 ist vschon eine recht alte Version ?
mal x750 probieren
X700 ist vschon eine recht alte Version ?
mal x750 probieren
Hallo amoretuo
auf unserem Anschluß ist es so konfiguriert
Adressen .0 - .7 Subnet 255.255.255.248
0.) = Netz selbst nicht benutzbar
1.) = Gateway
2-6.) = frei verfügbar
7.) = Broadcast
Gruß
palmiii
auf unserem Anschluß ist es so konfiguriert
Adressen .0 - .7 Subnet 255.255.255.248
0.) = Netz selbst nicht benutzbar
1.) = Gateway
2-6.) = frei verfügbar
7.) = Broadcast
Gruß
palmiii
Hallo Leute und thx für den Anstoss.
bei uns ist es auch genau so wie bei palmii.
ja die x700 ist schon etwas betagt aber ich kann ja nicht mal ne neue firewall kaufen nur weil der CC nicht läuft.
Die Telekom bemängelt jetzt dass ein TOS-Bit mitgeschickt wird mit dem die Vermittlungsstelle nichts anfangen kann.
Das könnte wohl angeblich das Problem sein.
Allerdings habe ich keine Möglichkeit das über die Watchguardsoftware zu konfigurieren.
Ich werde mich mal mit dem Systemhaus in Verbindung setzen dass uns die Firebox verkauft hat.
thx einstweilen. ich meld mich nochmal...
und @amoretuo
keine sorge ;o)
bei uns ist es auch genau so wie bei palmii.
ja die x700 ist schon etwas betagt aber ich kann ja nicht mal ne neue firewall kaufen nur weil der CC nicht läuft.
Die Telekom bemängelt jetzt dass ein TOS-Bit mitgeschickt wird mit dem die Vermittlungsstelle nichts anfangen kann.
Das könnte wohl angeblich das Problem sein.
Allerdings habe ich keine Möglichkeit das über die Watchguardsoftware zu konfigurieren.
Ich werde mich mal mit dem Systemhaus in Verbindung setzen dass uns die Firebox verkauft hat.
thx einstweilen. ich meld mich nochmal...
und @amoretuo
keine sorge ;o)
Hallo Stay,
TOS-Bit mitgeschickt wird mit dem die Vermittlungsstelle nichts anfangen kann.
das kann so wohl nicht sein. Es gibt TOS 2 Low Delay und TOS 7->für Low Loss . 7 benutzen wir für abgehende Verbindungen.
es wird so lange gesendet bis alle Pakete angekommen sind und der Empfänger quittiert hat.
damit wird das TOS Bit bis zum Empfänger übertragen. Es kann demnach wohl nicht bei der Vermittlungsstelle verloren gehen.
palmiii
TOS-Bit mitgeschickt wird mit dem die Vermittlungsstelle nichts anfangen kann.
das kann so wohl nicht sein. Es gibt TOS 2 Low Delay und TOS 7->für Low Loss . 7 benutzen wir für abgehende Verbindungen.
es wird so lange gesendet bis alle Pakete angekommen sind und der Empfänger quittiert hat.
damit wird das TOS Bit bis zum Empfänger übertragen. Es kann demnach wohl nicht bei der Vermittlungsstelle verloren gehen.
palmiii
Hallo Palmii,
danke für den sehr interessanten Einwand.
Habe gerade mit dem Syshaus gesprochen. Der Techniker bescheinigt wohl einige Probleme mit der verwendeten Firmware.
Ich werde jetzt mal einen Upgrade auf die empfohlene Fireware machen und dann geb ich nochmal laut ;o)
@ Palmii
hast du ne doku über die TOS Werte. Weil in KB Artikel 1303 unter watchguard.de ist 7 = network control.
Bis dann
danke für den sehr interessanten Einwand.
Habe gerade mit dem Syshaus gesprochen. Der Techniker bescheinigt wohl einige Probleme mit der verwendeten Firmware.
Ich werde jetzt mal einen Upgrade auf die empfohlene Fireware machen und dann geb ich nochmal laut ;o)
@ Palmii
hast du ne doku über die TOS Werte. Weil in KB Artikel 1303 unter watchguard.de ist 7 = network control.
Bis dann
Hallo. Upgrade an der Firewall durchgeführt und trotzdem fuktioniert es nicht. Das Log hat sich allerdings verändert!
EDIT: Log habe ich entfernt weil es nicht mit dem Problem zutun hatte. Macht den Thread nur unübersichtlicher.
jemand ne idee dazu?
EDIT: Log habe ich entfernt weil es nicht mit dem Problem zutun hatte. Macht den Thread nur unübersichtlicher.
jemand ne idee dazu?
So kleines Update.
Lt. Aussage des Systemhauses ist unsere Firewall in dem Stand gar nicht in der Lage QoS zu machen. Also wird als TOS nichts bzw. 0 gesendet. Also kann das Problem ja nicht von unserer FW kommen, oder?
Was mich zu dem Punkt bringt dass zwischen unserem Haus und er Vermittlungsstelle der Telekom ja nur noch 1 Komponente steckt. Und zwar der Ciscorouter der Telekom. Also wenn das jetzt so ist wie es scheint... dann weiss ich auch nicht mehr.
LG
Lt. Aussage des Systemhauses ist unsere Firewall in dem Stand gar nicht in der Lage QoS zu machen. Also wird als TOS nichts bzw. 0 gesendet. Also kann das Problem ja nicht von unserer FW kommen, oder?
Was mich zu dem Punkt bringt dass zwischen unserem Haus und er Vermittlungsstelle der Telekom ja nur noch 1 Komponente steckt. Und zwar der Ciscorouter der Telekom. Also wenn das jetzt so ist wie es scheint... dann weiss ich auch nicht mehr.
LG
So Leute,
das Drama hat ein Ende und die Lösung ist absolut lächerlich. Kann nicht glauben dass sowas nicht durch die Telekomtechniker probiert wurde.
Habe über persönliche Kontakte einen anderen Techniker an der Leitung der über den Tellerrand hinausgeschaut hat und sich nicht nur auf seine "grünen Lämpchen" verlassen hat.
Er hat auf dem Cisco Router einfach nur den ARP Cache gelöscht und schon ging alles. Lächerlich wirklich!
Danke an alle die hier mitgeholfen haben und ich hoffe euch bleiben solche Situationen erspart!
PS:
An den Telekom-Techniker der diesen Thread verfolgt! Namen lassen wir hier mal weg, nicht wahr?!
So kann man Kunden helfen wenn man sich kurz einmal wirklich mit dem Problem auseinander setzt und nicht sofort jegliche Schuld beim zahlenden Kunden ablädt!
das Drama hat ein Ende und die Lösung ist absolut lächerlich. Kann nicht glauben dass sowas nicht durch die Telekomtechniker probiert wurde.
Habe über persönliche Kontakte einen anderen Techniker an der Leitung der über den Tellerrand hinausgeschaut hat und sich nicht nur auf seine "grünen Lämpchen" verlassen hat.
Er hat auf dem Cisco Router einfach nur den ARP Cache gelöscht und schon ging alles. Lächerlich wirklich!
Danke an alle die hier mitgeholfen haben und ich hoffe euch bleiben solche Situationen erspart!
PS:
An den Telekom-Techniker der diesen Thread verfolgt! Namen lassen wir hier mal weg, nicht wahr?!
So kann man Kunden helfen wenn man sich kurz einmal wirklich mit dem Problem auseinander setzt und nicht sofort jegliche Schuld beim zahlenden Kunden ablädt!
