Horror-Release 10.12: VPN mit "Rückschlagventil"

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Horror-Release 10.12: Jetzt n o c h schlimmer ...

Beitrag von Jirka »

Hallo Koppelfeld,
Koppelfeld hat geschrieben:"Mein" Problem ist kein unmittelbares mit dem VCM - denn bereits ein Ping, wie im Beispiel gezeigt, funktioniert nicht mit der Adresse des Routers selbst.
dann müsste man das weiter analysieren. Aber ich kann da jetzt nichts zu sagen, kenne die Konfig nicht (genau genug).
Dass ein Ping nicht mit der IP-Adresse des Routers selbst funktioniert, ist nicht grundsätzlich ein Fehler. Zunächst gibt es nicht die Adresse des Routers, sondern im Normalfall ja immer mehrere Adressen. Und da verschiedene Adressen auch zu unterschiedlichen Netzen gehören und die wiederum unterschiedliche Routing-Tags haben können, muss ein Ping mit falschem Tag letztlich nicht funktionieren, ja soll sogar nicht funktionieren. Letztlich gilt auch hier: Das Routing-Tag muss passen. Ohne die Option "-a" wird standardmäßig das Tag 0 verwendet. Und wenn es jetzt keine Route mit Routing-Tag 0 zum Ziel gibt, ist Schluss. Ist also die Route zum VPN mit einem Routing-Tag versehen, so muss dieses Routing-Tag auch vom Ping her mitkommen. Ob man die ganze Sache so als glücklich gelöst ansieht oder nicht, steht auf einem anderen Blatt Papier. Dass der LANCOM-Router zwar ohne Verwendung der Option "-a" durchaus die richtige Quell-IP hat, aber eben nicht das passende Schnittstellen-Tag, das verstehe ich persönlich nicht.
Koppelfeld hat geschrieben:Sobald man mit der '-a' - Option eine falsche Absenderadresse angibt (aus dem lokalen Intranet), geht der Ping durch.
Oh je, ich verstehe jetzt erst, was Du hier geschrieben hast... Du könntest aber auch die richtige Adresse mit der "-a"-Option angeben und es würde auch funktionieren, oder etwa nicht? Denn wie oben schon geschrieben, wird mit der Option dann eben auch das passende Routing-Tag mitgegeben.
Koppelfeld hat geschrieben:Es wäre aber tatsächlich schon schön, wenn die 10.12 so gefixt werden würde, daß die originierende IP-Adresse a) richtig ist
Falls Du das bezogen auf den VCM meinst: Dazu müsste den Fehler mit der falschen Quell-IP bei über VPN angemeldeten SIP-Benutzern erst mal jemand melden. Ich mache es nicht, ich habe mein Guthaben jetzt mit dem T.38-Bug verschossen und habe es da noch nicht mal geschafft, die versprochenen Traces zu liefern (was jetzt aber auch verschiedene Gründe hat).
Falls Du das bezogen auf den Ping-Befehl auf der Konsole meinst: Die Option "-a" musste man auch bisher schon verwenden, das ist mit der 10.12 jetzt nicht neu. Was hingegen neu ist, ist die Situation, dass die Reihenfolge der lokalen Netze (zu sehen mit 'show bind') anscheinend anders sortiert ist. Wonach und wieso ist mir auch noch unklar. Aber ich hatte mal einen Standort umgestellt auf die 10.12, da war die Reihenfolge der Netze anders, musste dann wieder auf die 9.24 zurück, weil VoIP ja nicht lief, und nun ist wieder alles normal (das Intranet steht oben). [Noch eine Anmerkung: Ich rede hier immer von der Reihenfolge von lokalen Netzen an einem logischen Interface (z. B. mit VLAN-Tags getrennt). Es sind nicht mehrere lokale Netze an unterschiedlichen Interfaces gemeint.]
Koppelfeld hat geschrieben:und b) auch nicht, von welcher Instanz auch immer, geblockt wird.
Also dass eine VPN-Verbindung nur Pakete akzeptiert, die mit Quelle und Ziel Teil der SA sind, darüber sind wir uns doch einig, oder?
Zu der Sache, dass das passende Routing-Tag fehlt, hatte ich oben schon was geschrieben. Man kann sich auch ganz von den ganzen Tags verabschieden, ich habe da schon mal drüber nachgedacht. Dann macht man halt alles (nur) mit der Firewall. Hat wie immer Vor- und Nachteile. Was mich mal interessieren würde wäre, ob das eine oder andere effizienter ist. Ich bilde mir nämlich ein, dass das Taggen effizienter und sicherer ist (sicherer gegenüber z. B. Konfigurations-Fehlern).

Viele Grüße,
Jirka
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: Horror-Release 10.12: Jetzt n o c h schlimmer ...

Beitrag von Koppelfeld »

Hi Jirka,
Jirka hat geschrieben:
Koppelfeld hat geschrieben:Sobald man mit der '-a' - Option eine falsche Absenderadresse angibt (aus dem lokalen Intranet), geht der Ping durch.
Oh je, ich verstehe jetzt erst, was Du hier geschrieben hast... Du könntest aber auch die richtige Adresse mit der "-a"-Option angeben und es würde auch funktionieren, oder etwa nicht?
Moment 'mal ...

Code: Alles auswählen

bo@osho:~$ telnet 192.168.116.1
Trying 192.168.116.1...
Connected to 192.168.116.1.
Escape character is '^]'.


#
| LANCOM 1781VA-4G (over ISDN)
| Ver. 10.12.0243RU5 / 08.02.2018
| SN.  4003672532100055
| Copyright (c) LANCOM Systems

MACH, Connection No.: 002 (WAN)

Password: 

root@MACH:/
> ping 192.168.115.212


 ---192.168.115.212 ping statistic---
 56 Bytes Data, 4 Packets transmitted, 0 Packets received, 100% loss 

root@MACH:/
> ping -a 192.168.116.1 192.168.115.212

    56 Byte Packet from 192.168.115.212 seq.no=0 time=27.333 ms 
    56 Byte Packet from 192.168.115.212 seq.no=1 time=27.734 ms 
    56 Byte Packet from 192.168.115.212 seq.no=2 time=27.426 ms 
    56 Byte Packet from 192.168.115.212 seq.no=3 time=27.802 ms 
    56 Byte Packet from 192.168.115.212 seq.no=4 time=27.701 ms 
    56 Byte Packet from 192.168.115.212 seq.no=5 time=27.839 ms 

 ---192.168.115.212 ping statistic---
 56 Bytes Data, 6 Packets transmitted, 6 Packets received, 0% loss
Mich laust der Affe !
Denn wie oben schon geschrieben, wird mit der Option dann eben auch das passende Routing-Tag mitgegeben.
Alle Routing-Tags sind in diesem Spezialfall 0, sollte also passen.
Koppelfeld hat geschrieben:Es wäre aber tatsächlich schon schön, wenn die 10.12 so gefixt werden würde, daß die originierende IP-Adresse a) richtig ist
Falls Du das bezogen auf den VCM meinst: Dazu müsste den Fehler mit der falschen Quell-IP bei über VPN angemeldeten SIP-Benutzern erst mal jemand melden. Ich mache es nicht, ich habe mein Guthaben jetzt mit dem T.38-Bug verschossen
Nein, Du hast da etwas nicht verstanden: Dies ist ein privates Forum, in dem u.a. engagierte Mitarbeiter der Firma LANCOM in ihrer Privatzeit schreiben. Wenn Du da schreibst, "Ich erwarte, daß Problem X bis zum Stichtag Y gefixt ist", dann gefriert einem das Blut in den Adern.
Als ob man als Entwickler nicht genug Äffchen hätte, die an einem herumzerren.
Falls Du das bezogen auf den Ping-Befehl auf der Konsole meinst: Die Option "-a" musste man auch bisher schon verwenden, das ist mit der 10.12 jetzt nicht neu. Was hingegen neu ist, ist die Situation, dass die Reihenfolge der lokalen Netze (zu sehen mit 'show bind') anscheinend anders sortiert ist.
Mo-ment 'mal. Dann müßten ja auch die Telnet-, ssh- und sonstigen Clients ebenso einen Flag haben zur Definition der originierenden Adresse. Dem LCOS liegt doch die effektive Routing-Tabelle vor und es kann, wie jedes schedderige Windows auch, das passende Interface heraussuchen.
Wonach und wieso ist mir auch noch unklar. Aber ich hatte mal einen Standort umgestellt auf die 10.12, da war die Reihenfolge der Netze anders, musste dann wieder auf die 9.24 zurück, weil VoIP ja nicht lief, und nun ist wieder alles normal
Und wie immer hast Du recht: Nachdem ich im konkreten Fall das (eh' nicht genutzte) Gastnetz deaktiviert habe, klappt jetzt wieder die "Entführung aus dem Telekom-Serail" so, wie sie soll.


So geht das aber nicht weiter.
Wenn also nur noch Deppen von Firmen wie Schlechtle ordentlichen Support erhalten, wird das nie etwas. Denn gerade diese "großen" Beratungshäuser beherbergen so viele peinliche Totalversager (ich erlebe das täglich im IBM-Umfeld), da hilft nur ein Hohlmantelgeschoß. Die Support-Leute sollen nicht Netz-Analphabeten hinterherräumen, sondern vor allen Dingen Fehler im Produkt identifizieren, damit das Problem nicht woanders erneut auftritt.

Es braucht eine Annahmestelle, wo qualifizierte Netzwerkingenieure wahrscheinliche Fehler im LCOS melden. Und wenn diese Meldungen so gut vorgearbeitet sind wie Deine, dann sollte eine Einreichung auch angemessen vergütet werden. Das schreibe ich jetzt 'mal an den Herrn Koenzen.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: Horror-Release 10.12: VPN mit "Rückschlagventil"

Beitrag von alf29 »

Dann müßten ja auch die Telnet-, ssh- und sonstigen Clients ebenso einen Flag haben zur Definition der originierenden Adresse.
Haben sie ja in LCOS, zumindest Telnet & SSH. Die braucht man natürlich nur, wenn es mehrere Wege zum Zielserver gibt und man einen bestimmten haben möchte.
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: Horror-Release 10.12: Jetzt n o c h schlimmer ...

Beitrag von beki »

Koppelfeld hat geschrieben:Dem LCOS liegt doch die effektive Routing-Tabelle vor und es kann, wie jedes schedderige Windows auch, das passende Interface heraussuchen.
Ein klares Jain! Das kommt, insbesondere auch auf Linux, darauf an, welchen Socket du nimmst, welche Optionen der hat, etc. Insbesondere auch, ob "ip route show" die "src" Option im jeweiligen Zielnetz gesetzt hat. Und selbst wenn man das passende Interface findet, kann dies immer noch mehrere IP-Adresse haben.

Ich stimme dir zu: Es wäre bequem, wenn das LCOS "ping" sich mehr Mühe gäbe, die passende Quelladresse zu wählen. Aber einen Vorwurf an LANCOM/LCOS zu richten, halte ich für etwas überzogen.
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: Horror-Release 10.12: Jetzt n o c h schlimmer ...

Beitrag von Koppelfeld »

beki hat geschrieben:
Koppelfeld hat geschrieben:Dem LCOS liegt doch die effektive Routing-Tabelle vor und es kann, wie jedes schedderige Windows auch, das passende Interface heraussuchen.
Ein klares Jain! Das kommt, insbesondere auch auf Linux, darauf an, welchen Socket du nimmst, welche Optionen der hat, etc. Insbesondere auch, ob "ip route show" die "src" Option im jeweiligen Zielnetz gesetzt hat. Und selbst wenn man das passende Interface findet, kann dies immer noch mehrere IP-Adresse haben.
Also, ich weiß ja nicht, wie LCOS das POSIX-IF implementiert hat, aber: Egal ob HP-UX, AIX, Solaris, MWS, OS/400, Windows NT, Ultrix:
Wenn Du ein socket mit (AF_INET,SOCK_STREAM) erzeugst, OHNE es zu binden, dann wird ein 'connect()' immer die passende Quell-ID finden. Einziges Problem: Mehrere IPs auf einem Interface.

Wenn Du ein neuerstelltes Socket "einmal reihum" bindest, ich kopiere 'mal aus einem gut 20 Jahre alten AIX-Source,

Code: Alles auswählen

   /* SOCKET, BIND, LISTEN */
   for(ap=servinfo; ap!=NULL; ap=ap->ai_next) {
      svr_fd=socket(ap->ai_family,ap->ai_socktype,ap->ai_protocol);
      if (svr_fd==-1) {
         syserr("server: socket");
         continue;
      }
      if (setsockopt(svr_fd,
                     SOL_SOCKET,SO_REUSEADDR,
                     &yes,sizeof(int)
                    )                          ==-1) {
         syserr("setsockopt");
         abend();
      }
      if (bind(svr_fd,ap->ai_addr,ap->ai_addrlen)==-1) {
         close(svr_fd);
         syserr("server: bind");
         continue;
      }
      break;
   }

   freeaddrinfo(servinfo);
   if (ap==NULL) {
      err("server: failed to bind()\nIs an instance already running ?");
      abend();
   }

   if (listen(svr_fd,NID_BACKLOG)==-1) {
      syserr("listen");
      abend();
   }
-- also, wenn Du das in dieser Weise machst, lauscht Dein Socket natürlich auf jedem Interface.

Es müßten also BEIDE Richtungen funktionieren.

Ich stimme dir zu: Es wäre bequem, wenn das LCOS "ping" sich mehr Mühe gäbe, die passende Quelladresse zu wählen.
Ich finde nicht, daß das die Aufgabe eines Anwendungsprogrammes ist.
Aber einen Vorwurf an LANCOM/LCOS zu richten, halte ich für etwas überzogen.
Vorwurf, das ist so ein Problemwort.
Ich komme nur so langsam in die Situation, daß ich mich kompromittiere. Mittlerweile hat nämlich die Besitzerin des Routers gemerkt, daß dieser seit gut zwei Wochen kaputt ist.

Es war so:
Sie hat ein traumhaft abgelegenes Häuschen im weltbekannten Verneis, der Ennepetaler Schweiz.
Mit Mobilfunk ist da nix. Deswegen steht in ihrer Firma ein kleines GSM-Gateway mit ihrer "Twin-Handy-Karte" drin, eingehende Rufe werden qua VPN an den VCM in der Einöde weitergereicht.
Einfach, praktisch, effektiv -- Madame sind auch zuhause unter ihrer Mobilnummer erreichbar.
Nun hatten Madame Geburtstag und erwarteten viele, viele Glückwünsche und beste Wünsche.
Leider aber blieb das Telephon stumm.
Ich weiß gar nicht, was mir dieses Mal den Kopf gerettet hat, aber Madame waren dennoch sehr angefressen.

Was soll ich ihr jetzt eigentlich sagen ?
"Wissen Sie, Ihr VPN klappt doch prima, es ist bloß ein gaaaaanz kleines Problem, wenn eine UDP-Verbindung lokal auf dem Router originiert wird, dann kann es sein, daß die Anwendung mit einer Quelladresse herausgeht, die von der VPN Gegenstelle invalidiert wird".
Die hetzt ihre Köter auf mich!

Und sie hat recht. Denn sie hat, für jeden Router, 1.500,-- für die Konfiguration bezahlt -- und dafür sollte sie davon ausgehen können, vor solchen Katastrophen verschont zu bleiben. Deswegen hat sie übrigens auch die teuren LANCOM - Router gekauft. Die übrigens seit etlichen Jahren störungsfrei ihren Dienst tun.

Nun magst Du sagen, "Geh' doch zurück nach 9.24". Schon passiert.
Aber das chaotische Verhalten ist immer noch vorhanden. Ich weiß jetzt wirklich nicht mehr, was ich tun soll.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: Horror-Release 10.12: Jetzt n o c h schlimmer ...

Beitrag von Jirka »

Hallo,
Jirka hat geschrieben:Falls Du das bezogen auf den VCM meinst: Dazu müsste den Fehler mit der falschen Quell-IP bei über VPN angemeldeten SIP-Benutzern erst mal jemand melden. Ich mache es nicht, ich habe mein Guthaben jetzt mit dem T.38-Bug verschossen und habe es da noch nicht mal geschafft, die versprochenen Traces zu liefern (was jetzt aber auch verschiedene Gründe hat).
Falls Du das bezogen auf den Ping-Befehl auf der Konsole meinst: Die Option "-a" musste man auch bisher schon verwenden, das ist mit der 10.12 jetzt nicht neu. Was hingegen neu ist, ist die Situation, dass die Reihenfolge der lokalen Netze (zu sehen mit 'show bind') anscheinend anders sortiert ist. Wonach und wieso ist mir auch noch unklar. Aber ich hatte mal einen Standort umgestellt auf die 10.12, da war die Reihenfolge der Netze anders, musste dann wieder auf die 9.24 zurück, weil VoIP ja nicht lief, und nun ist wieder alles normal (das Intranet steht oben). [Noch eine Anmerkung: Ich rede hier immer von der Reihenfolge von lokalen Netzen an einem logischen Interface (z. B. mit VLAN-Tags getrennt). Es sind nicht mehrere lokale Netze an unterschiedlichen Interfaces gemeint.]
so, ich kann nicht auf die 10.12 umsteigen, wenn die Telefonie nur einseitig funktioniert. Daher melde ich jetzt und hiermit, da es ansonsten ja anscheinend niemand macht, den hier beschriebenen Bug und bitte um einen Fix in der 10.12.
Gegeben sind zwei LANCOM-Router. Zwischen diesen besteht eine VPN. Die VPN verbindet das lokale Intranet auf meiner Seite mit dem lokalen Intranet auf der anderen Seite. Bei mir gibt es neben dem lokalen Intranet noch Gastnetze. Auf der anderen Seite gibt es im VCM eine SIP-PBX-Leitung, die für die übergeordnete Registrierung der SIP-Benutzer an meinem LANCOM-Router sorgt. Die Registrierung klappt einwandfrei. Der SIP-Benutzer ist bei mir mit der IP-Adresse des anderen LANCOM-Routers im lokalen Intranet, die Teil der VPN-Netzbeziehung ist, registriert. Kommt es jetzt zu einem Anruf hört mich die andere Seite nicht. Grund ist, dass mein LANCOM-Router die Sprachpakete, die von meinem SIP-Telefon im lokalen Intranet kommen (am VCM registriert), über die IP-Adresse des Gastnetzes abschickt (Quell-IP-Adresse ist also die lokale IP-Adresse meines LANCOM-Routers im Gastnetz). Warum der LANCOM-Router das macht, weiß ich nicht. Eigentlich steht doch die IP-Adresse fest, wo sich der Client (über die übergeordnete Registrierung also der LANCOM) registriert hat, nämlich die lokale IP-Adresse im Intranet, die Teil der VPN ist. Was auffällig ist ist, wie damals ja schon geschrieben, dass ein 'show bind' die Netze in einer anderen Reihenfolge auflistet als bisher und dass sich der LANCOM-Router bei mir offenbar den obersten Eintrag, und damit das Gastnetz, nimmt und darüber absendet. Warum weiß ich nicht. Es ist für mich nicht nachvollziehbar. Und ich kann es auch nicht mal eben ändern.

Code: Alles auswählen

[IP-Router] 2018/04/23 21:21:41,103
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.10.7.1, SrcIP: 172.20.20.1, Len: 200, DSCP: EF (0x2e), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 9548, SrcPort: 11572
Route: WAN Tx (VPN-VERB-GEGENSE)

root@Mein-Router:/
> show bind
Ifc.: LAN-1
  GASTNETZ         172.20.20.1      255.255.255.0    2
  GASTNETZ_CF      172.20.21.1      255.255.255.0    3
  HOT_SPOT         172.20.22.1      255.255.255.0    4
  INTRANET         10.10.10.1       255.255.255.0    0

Ifc.: BRG-1
  (none)

root@Mein-Router:/
> ls st/tcp/netw

Network-name IP-Address  IP-Netmask    VLAN-ID Interface Src-check Type     Rtg-tag
=============----------------------------------------------------------------------
GASTNETZ     172.20.20.1 255.255.255.0 2       LAN-1     loose     Intranet 2
GASTNETZ_CF  172.20.21.1 255.255.255.0 3       LAN-1     loose     Intranet 3
HOT_SPOT     172.20.22.1 255.255.255.0 4       LAN-1     loose     Intranet 4
INTRANET     10.10.10.1  255.255.255.0 0       LAN-1     loose     Intranet 1
Weil der LANCOM-Router zusätzlich statt Routing-Tag 1 das Routing-Tag 0 verwendet (siehe Trace und eigentlich auch falsch), gibt es eine (zusätzliche) Route mit Routing-Tag 0 und Ziel-IP-Adresse des anderen LANCOM-Routers im Intranet (und der VPN-Verbindung dorthin), diese Route geht nicht in die automatische Regelerzeugung der VPN-Verbindung ein, funktioniert aber für den VCM.
Firmware ist 10.12.0355, das Problem tritt aber schon seit mind. einem halben Jahr auf.

Vielen Dank und viele Grüße,
Jirka
Antworten