# Fernwartung über das Internet



## rostiger Nagel (28 Juli 2009)

Hallo Liebe Forumgemeinde,
ich habe einen Kunden in den Niederlande, der möchte gerne eine
Fernwartung über das Internet durchführen. Dieses einzustellen,
bekomme ich einfach nicht hin. 


Der Kunde hat mir folgende Daten zur verfügung gestellt:

IP Kunde (ich denke damit meint er den Router...?
IP Maschine
Port
Mit den Adressen könnte ich direkt bis zur Maschine ohne Firewall oder
ähnlichen lt. Kunde. Jetzt habe ich versucht diese Adressen einzustellen
komme aber irgendwie nicht weiter.
Dann habe ich Service Request bei Siemens aufgemacht und habe folgenden
Link bekommen: http://support.automation.siemens.com/WW/view/de/26662448
Wenn ich dann die PDF's durchlese wird es nicht besser, das ist einfach
nicht meine Welt. Kann mir da jemand auf die Sprünge helfen...?

gruß helmut


----------



## marlob (28 Juli 2009)

Kannst du den Router denn anpingen? Hat der Kunde selber denn schon mal eine Verbindung darüber hinbekommen? Sonst kannst du ja lange probieren


----------



## DELTALOGIC Support (28 Juli 2009)

Guten Morgen,

Mit diesen wenigen Informationen ist es schwierig einen Tipp zu geben.

- Auf was für ein Gerät soll denn beim Kunden zugegriffen werden?
- Wie lauten die ersten zwei Blöcke der vom Kunden genannten IP-Adressen?
- Welche Portnummer hat der Kunde angegeben?
- Mit welcher Software soll bei Ihnen gearbeitet werden?
- Haben Sie sonst noch Informationen vom Kunden bekommen?

Bernhard Götz


----------



## rostiger Nagel (28 Juli 2009)

marlob schrieb:


> Kannst du den Router denn anpingen? Hat der Kunde selber denn schon mal eine Verbindung darüber hinbekommen? Sonst kannst du ja lange probieren


 
Nein habe ich noch nicht hinbekommen, da fängt es ja schon an.
Teilnehmer anpingen die bei uns im Haus am Netz hängen ist ja kein
Problemm. Aber was muss ich eingeben bei externen...?


----------



## rostiger Nagel (28 Juli 2009)

DELTALOGIC Support schrieb:


> Guten Morgen,
> 
> Mit diesen wenigen Informationen ist es schwierig einen Tipp zu geben.
> 
> ...


 
Hallo Herr Götz,
es soll auf ein MP277 mit Soft SPS zugegriffen werden.
Die ersten zwei Blöcke sind 82.176.xxx.xxx.
Portnummer ist 801.
Bei mir natürlich Step 7, Tele-Service von Siemens
ist auch vorhanden.
Und sonst habe ich keine zusätzliche Info bekommen.

gruß helmut


----------



## maweri (28 Juli 2009)

Hallo Helmut,

so einfach wie sich das in der Theorie anhört, ist es in der Praxis nach meinen Erfahrungen leider nicht.

Wie bist Du mit dem Internet verbunden?
Direkt (ohne Proxy usw.) oder über einen Firmenserver (evtl. sogar mit Firewall) ?

Bei meiner alten Firma sollte ich eine Verbindung genau wie von Dir beschrieben aufbauen. Klappte natürlich auch nicht auf Anhieb. Zum Glück hatten wir eine IT-Spezialisten im Haus. Der hat dann 2 Tage mit Kunden an den Einstellungen gebastelt bis es klappte.

Voran ich mich noch erinnern kann, ist daß auf jeden Fall der *Port 102* freigegeben werden muß. Sonst läuft's m.W. nach gar nicht.

Gruß
Markus


----------



## rostiger Nagel (28 Juli 2009)

Hallo Markus,
ich glaube was du da beschreibst trifft alles auf uns zu. 
Proxy Server mit Firewall ist vorhanden. So ein EDV-Spezi
wie du ihn gehabt hast, haben wir nicht.
Wenn mann da wirklich bis zu zwei Tage brauchen kann, fahre
ich besser gleich zum Kunden .

gruß helmut


----------



## marlob (28 Juli 2009)

Wer administriert denn dann euer Netz? Wenn ihr öfter Fernwartung betreiben wollt, könntest du dir ja mal einen Spezialisten ins Haus holen, der euch das entsprechend einstellt


----------



## DELTALOGIC Support (28 Juli 2009)

Soo...

In Step7 kann der Port nicht geändert werden, das bedeutet, der Kunde muß Ihnen Port 102 anstelle von 801 zur Verfügung stellen.

Also, der einfachste Weg ist:

Kunde macht ein Portforwarding (mit dem Begriff sollte der ITler etwas anfangen können) von seinem Internet Gateway Port 102 auf die interne IP-Adresse des MP277 ebenfalls Port 102.

ACHTUNG! In dieser Konstellation ist keinerlei Sicherheit mehr gewährleistet. Um hier auf die Anlage zugreifen zu können, braucht man keinen Benutzer/Passwort, keinen Schlüssel - nur die IP-Adresse und den Port - und die kann man heraus bekommen.

Als nächste Voraussetzung muß Ihr PC Verbindungen ins Internet auf Port 102 aufbauen können. Fragen Sie am besten bei Ihrem Administrator nach, ob das geht bzw. was Sie tun müssen, damit es geht. Wenn das nicht geht, können Sie nur noch einen anderen Internetzugang (z.B. zu Hause) verwenden.

Ping nach Extern geht wie ein Ping nach Intern - ping 82.176.X.X

Es kann natürlich sein, daß ein Ping nach Extern von der Firewall nicht zugelassen wird (Admin fragen).

In Step7 tragen Sie in der Hardware Konfiguration der SPS (bzw. des MP) bei Ihnen im Projekt die IP-Adresse des Kunden ein (jetzt wohl 82.176.X.X) und versuchen anschließend die Verbindung aufzubauen als wäre das Gerät lokal im Netzwerk angeschlossen.

ACHTUNG! Die Hardware Parametrierung mit der geänderten IP-Adresse KEINENFALLS in die SPS (bzw. auf das MP) laden, ansonsten ist es nicht mehr ansprechbar und sie müssen es vor Ort wieder umparametrieren.

Ich glaube ich hab alles wichtige beschrieben.

Bernhard Götz


----------



## rostiger Nagel (28 Juli 2009)

Wir haben eine eigene EDV-Abteilung, da 
sitzen dann Kaufleute die auf de´m dritten
Bildungsweg zu EDV-Spezialisten wurden.
Kannst du dir vorstellen was da los ist :twisted:

Fernwartung habe ich sonst eigendlich mit
TS-Adaptern durchgeführt.
Ich schick den kunden das Adapter, sage zu
ihn schließe das mal an und sende mir deine
Telefon-Nr., klappt alles wunderbar.

Schön wenn es wenn das über das Ethernet
auch so einfach möglich wäre.


----------



## rostiger Nagel (28 Juli 2009)

DELTALOGIC Support schrieb:


> Soo...
> 
> In Step7 kann der Port nicht geändert werden, das bedeutet, der Kunde muß Ihnen Port 102 anstelle von 801 zur Verfügung stellen.
> 
> ...


 
Hallo Herr Götz,
das ist doch mal eine Info mit der ich etwas anfangen kann,
werde mich sofort auf die Arbeit stürzen, Rückmeldungen
können etwas dauern da Kunde z.Z. im Urlaub.

Habe ich eigenlich heute schon das DELTALOGIC-Team gelobt...?
Dann hole ich das hiermit nach, "Großes Lob" und "Danke".

gruß helmut


----------



## DELTALOGIC Support (28 Juli 2009)

Helmut_von_der_Reparatur schrieb:


> Habe ich eigenlich heute schon das DELTALOGIC-Team gelobt...?
> Dann hole ich das hiermit nach, "Großes Lob" und "Danke".





Bernhard Götz


----------



## PN/DP (3 August 2009)

*Fernwartungs-Varianten*



DELTALOGIC Support schrieb:


> Also, der einfachste Weg ist:
> 
> Kunde macht ein Portforwarding (mit dem Begriff sollte der ITler etwas anfangen können) von seinem Internet Gateway Port 102 auf die interne IP-Adresse des MP277 ebenfalls Port 102.
> 
> ACHTUNG! In dieser Konstellation ist keinerlei Sicherheit mehr gewährleistet. Um hier auf die Anlage zugreifen zu können, braucht man keinen Benutzer/Passwort, keinen Schlüssel - nur die IP-Adresse und den Port - und die kann man heraus bekommen.


Diesen Tip möchte ich hier nicht so unkommentiert stehenlassen, da in diesem Forum viele absolute SPS-Anfänger mitlesen.

Hier eine Aufstellungen von Fernwartungs-Varianten, die ich nutze:

*A) "klassische" Telefon-Einwahl über TS-Adapter mit Simatic TeleService*
   - keine Anpassungen im Step7-Projekt nötig
   - Nachteile: geringe Baudrate, Verbindungskosten, evtl. feste Rückrufnummer

*B) Mitglied des fernen Firmennetzwerkes werden über (SSL-)VPN-Zugang*
   - keine Anpassungen im Step7-Projekt nötig
   - Zugangs-Berechtigung durch Kunde-Administrator einfach und voll administrierbar
   - Vorteile: hohe Baudrate und keine Verbindungskosten bei DSL-Flatrate
   - Nachteil: kostenintensiv, wenn der Kunde noch keine VPN-Zugangslösung hat

*C) RemoteDesktop-Verbindung zu einem vor-Ort-PC, der Step7 (...) installiert hat*
-- Zugang zum vor-Ort-PC in der Regel über (SSL-)VPN-Verbindung
   - keine Anpassungen im Step7-Projekt nötig
   - Vorteil: Zugriff auf alle vor Ort vernetzten SPS und Panels einfach möglich
   - Vorteil: je nach SPS-Anbindung des vor-Ort-PC ggf. direkte Profibus-Diagnose möglich
   - Vorteil: die Step7-Projekte vor Ort sind (immer) aktuell
   - Vorteil: der Fernwarte-PC benötigt kein Step7 und kein Step7-Projekt, also quasi jeder PC weltweit nutzbar
   - Nachteil: Step7(...)-Lizenz(en) vor Ort nötig
   - Nachteil: Programm beobachten in der Regel nicht effektiv (Kommunikation meist zu langsam)
   - Nachteil: aufwendige Synchronisation der Step7-Projekte auf vor-Ort-PC und Fernwarte-PC

*D) (festes) Port-Forwarding Port 102 in der Kunden-Firewall*
   - einen "Router" im Step7-Projekt hinzufügen, um Step7 die öffentliche IP-Adresse des Kundenzugangs mitzuteilen
   - Vorteile: hohe Baudrate und keine Verbindungskosten bei DSL-Flatrate
   - Nachteil: in der Regel keinerlei wirksamer Schutz gegen Fremd-Zugriffe!
   - Nachteil: ohne zusätzlichen Aufwand nur eine SPS erreichbar
   - Hinweis: ein Ping auf die SPS funktioniert nicht, es antwortet immer die Firewall
   - die Ziel-SPS sollte nur während einer vorher verabredeten Fernwartungs-Sitzung mit dem Kunde-Netzwerk verbunden sein
- (Netzwerkkabel die übrige Zeit von der SPS abziehen)

Ich habe zu betreuen
A) 4 Anlagen - Zugang über ISDN und Rückruffunktion
B) ca. 80 Anlagen - Zugang über F5 Networks FirePass
-- 3 Anlagen - Zugang über SonicWALL SSL-VPN 200
C) 2 Anlagen - Zugang über andere SSL-VPN-Verbindungen
D) 6 Anlagen - die Anlagen werden nur für die Dauer der Fernwarte-Sitzung mit dem Kunde-Netzwerk verbunden


Die einfachste Variante *D) Port-Forwarding* sollte nur eingesetzt werden, wenn es die Gefährdungsanalyse zuläßt und die anderen Varianten nicht wirtschaftlich sind.


Die von mir immer empfohlene Fernwartungs-Variante ist der Fall *B) SSL-VPN Zugang*
Das kostet zwar einigen Aufwand beim Kunden, ist dann aber die bequemste und sicherste Lösung.

Meine Empfehlung einer VPN-Lösung für größere Firmen
F5 Networks FirePass

kostengünstige VPN-Lösung für kleine Firmen bzw. Einzel-Anlagen
SonicWALL SSL-VPN

z.B. SonicWALL SSL-VPN 200
ca. EUR 900,00 netto inkl. 3 Jahre Garantie + Firmwareupdates + Telefonsupport


Ein paar Aspekte, die bei Fernzugriffen auf SPS-Anlagen unbedingt zu beachten sind:

- Sicherheitsempfehlungen vom "Bundesamt für Sicherheit in der Informationstechnik" (BSI)
IT-Grundschutz-Kataloge (früher: IT-Grundschutzhandbuch)

- Fernwartung/Fernzugriff auf SPS-Anlagen/Maschinen gehört generell in die Gefährdungsanalyse/Risikobewertung der betreffenden Anlage!

- Siemens-Hinweis in den Handbüchern der IE-CPs:
"EG-Hinweis: Die Inbetriebnahme ist so lange untersagt, bis festgestellt wurde, dass die Maschine, in die diese Komponente eingebaut werden soll, den Bestimmungen der Richtlinie 89/392/EWG entspricht."

- Siemens-Hinweis zu "Mögliche Sicherheitslücken bei Standard-IT-Schnittstellen / Unerlaubte Zugriffe unterbinden"
"In verschiedenen SIMATIC-NET Komponenten (...) werden über offene Protokolle und Schnittstellen (...) Funktionen (..) zur Verfügung gestellt. Es kann nicht ausgeschlossen werden, dass diese offenen Protokolle und Schnittstellen durch Dritte unbefugt missbraucht werden können, z.B. für Manipulationen.
Bei Benutzung oben genannter Funktionen und Verwendung dieser offenen Schnittstellen und Protokolle (...) sind daher geeignete Sicherheitsvorkehrungen zu treffen, die den unerlaubten Zugriff auf die Komponenten bzw. das Netzwerk insbesondere aus dem WAN/Internet unterbinden.

*Achtung*
Wir weisen daher ausdrücklich darauf hin, dass Automatisierungsnetze durch geeignete Netzübergänge (z.B. die bewährten Firewall-Systeme) vom restlichen Firmennetz getrennt werden müssen. Wir übernehmen keine Haftung für Schäden, gleich aus welchem Rechtsgrund, die sich aus der Nichtbeachtung dieses Hinweises ergeben."

- weitere Hinweise siehe Siemens Systemhandbuch Kommunikation mit SIMATIC
  Kapitel "2.4 Informationssicherheit in der Automatisierung" -> Schutzmaßnahmen

- *Das Zielsystem ist vor Eingriffen unbedingt eindeutig zu identifizieren!*
- (durch Bausteinvergleich, ggf. zusätzlich CPU-Passwort, Zielsystem -> Baugruppenzustand, ...)

Die Anlage, die ferngewartet werden soll, ist nicht nur vor unerlaubten Fremdzugriffen zu schützen, sondern der Programmierer, der einen "erlaubten" Fernzugriff vornimmt, muß sich auch selber schützen vor versehentlichem Zugriff auf falsche/fremde SPS-Anlagen.
Der (versehentliche) Zugriff auf falsche/fremde SPS-Anlagen kann verheerende Auswirkungen haben, *die bis zum Tod von Menschen führen können!*

Es ist also alles zu unternehmen, was die Chance für einen versehentlichen Falschzugriff verringert.
z.B. sind die Zugangsadressen möglichst im Step7-Projekt oder in TeleService fest zu hinterlegen, um Tippfehler beim Verbindungsaufbau zu vermeiden.
Die Ziel-SPS sollten ein CPU-Passwort haben, jede CPU ein anderes Passwort!
(Das CPU-Passwort soll nicht unbedingt den Kunden von der SPS fernhalten, es dient hier mehr der Identifizierung.)


----------



## rostiger Nagel (3 August 2009)

Hallo PN/DP,
vielen DANK für diese ausführliche Erläuterung,
darüber muss Mann ersteinmal schlafen.
Aber nicht ohne dir ein Lob auszusprechen,
ein toller Beitrag!

Gruß Helmut


----------



## PN/DP (3 August 2009)

*Fernzugriff projektieren bei Variante D) Port-Forwarding in der Kunden-Firewall*



DELTALOGIC Support schrieb:


> In Step7 tragen Sie in der Hardware Konfiguration der SPS (bzw. des MP) bei Ihnen im Projekt die IP-Adresse des Kunden ein (jetzt wohl 82.176.X.X) und versuchen anschließend die Verbindung aufzubauen als wäre das Gerät lokal im Netzwerk angeschlossen.
> 
> ACHTUNG! Die Hardware Parametrierung mit der geänderten IP-Adresse KEINENFALLS in die SPS (bzw. auf das MP) laden, ansonsten ist es nicht mehr ansprechbar und sie müssen es vor Ort wieder umparametrieren.


Dieser Tip ist sachlich nicht ganz richtig (auch wenn er vielleicht funktionieren mag). Außerdem muß die IP-Adresse im Step7-Hardware-Konfig jedesmal angepaßt werden, wenn man abwechselnd mal von fern und mal direkt an der Anlage ist. Hier sind Tippfehler vorprogrammiert.

Um im Step7-Projekt die öffentliche IP-Adresse des Kundenzugangs korrekt und fest zu hinterlegen, muß einfach nur ein Ethernet-Router eingefügt werden (also eine Station, von der Step7 "weiß", daß sie die Pakete zwischen WAN und LAN routen wird).

Ein "Ethernet-Router" ist in Step7/NetPro einfach eine SIMATIC-Station mit 2 Ethernet-Anschlüssen und Routing-Fähigkeit (hier im Beispiel: SIMATIC 300-Station).







Man nehme eine routing-fähige CPU (z.B. CPU 314-1AG13) und 2 Ethernet-CPs (z.B. CP343-1EX11).
(die CPU sollte eine ganz einfache CPU sein, damit Step7 nicht womöglich spezielle Fähigkeiten des Routers interpretiert und nutzen will).
Der eine CP wird mit dem WAN (= Internet) verbunden und erhält die öffentliche IP-Adresse (hier 82.176.x.x), 
der andere CP wird mit dem LAN (= Kunde-Firmen-Netzwerk) verbunden und erhält die lokale IP-Adresse des Kunden-Routers 
(des Standard-Gateways in deren Firmen-LAN, hier 192.168.10.254).

Die Konfiguration muß und kann natürlich nicht in den realen Router geladen werden, die Station steht hier nur als Stellvertreter für den Firmenrouter/Firewall, um Step7 mitzuteilen, daß da ein Router ist und welche IP-Adressen der hat.

In der Hardware-Konfiguration der SPSen und des MP277 wird in der Regel eingestellt: 
(x) Router verwenden, Adresse: 192.168.10.254 (hier im Beispiel)

Hinweis: Am MP277 muß die Konfiguration der Netzwerk-Schnittstelle manuell im Control-Panel vorgenommen werden, sie wird nicht von WinCCflexible eingestellt.

Die PG/PC-Schnittstelle im Programmierer-PC wird für Step7 und WinCCflexible so eingestellt:
*S7ONLINE (STEP7) --> TCP/IP -> <name_netzwerkkarte_programmier-pc>*

Wenn man nun mal von fern und mal direkt an der Anlage ist und Step7 nicht automatisch den richtigen Weg zur SPS erkennen sollte, dann empfiehlt es sich, noch ein "PG/PC" in NetPro einzufügen und dieses "PG/PC" dem jeweiligen Netzwerk "zuzuordnen", an dem der Programmierer-PC gerade angeschlossen ist (die dicke gelbe Linie im Bild).

Nun sollte es kein Problem sein, auf alle in NetPro dargestellten SPS und Panels zuzugreifen.

Hinweis: WinCCflexible unterstützt erst ab der Ausgabe 2008 einen gerouteten Zugriff auf ein Panel, wenn die erste Strecke vom PG/PC zum Panel vom Typ Ethernet ist (bei den älteren WinCCflexible-Versionen muß die erste Strecke MPI oder Profibus sein, oder ein "PC-Adapter" gauckelt WCf vor, es wäre direkt an MPI oder Profibus angeschlossen).

Nachtrag: Step7-Beispielprojekt zu diesem Beitrag


----------



## JesperMP (3 August 2009)

*Es gibt noch eine Variante*

*E) VPN durch Internet-Mittlerwebsite.
*- Vorteil: Kein bedarf für Zugangs-Berechtigung durch Kunde-Administrator.
- Vorteil: hohe Baudrate (*) und keine Verbindungskosten.
- Vorteil: Alle LAN Stationen (SPS, HMI, PC's) können erreicht werden
- Nachteil: Relativ kostenintensiv (~1000 €).
Ich glaube dass nur 1 lieferant hat diese Lösung (http://www.ewon.biz/Pres2005CD.htm).
Der kunde muss nur ein LAN Verbindung mit www Zugang zur Verfügung stellen.
Ewon Router muss in STEP7 Project eingetragen werden.
*: 'pro' version von talk2m stellt ein gewisse Bandbreite zur Verfügung.


----------



## Gerhard Bäurle (3 August 2009)

JesperMP schrieb:


> Ich glaube dass nur 1 lieferant hat diese Lösung



Hallo,

es gibt Anbieter wie z. B. *mdex*, die solche Dienste unabhängig 
von Hardware-Herstellern anbieten.

Und MB Connect Line hat eine Dienst names mymbnet.biz am Start,
der das auch bietet, siehe *mbNET* bei "aktueller Firmware".


----------



## JesperMP (3 August 2009)

Gerhard Bäurle schrieb:


> es gibt Anbieter wie z. B. *mdex*, die solche Dienste unabhängig von Hardware-Herstellern anbieten.


Das wäre das Produkt "mdexmanaged.VPN", oder ?



Gerhard Bäurle schrieb:


> Und MB Connect Line hat eine Dienst names mymbnet.biz am Start, der das auch bietet, siehe *mbNET* bei "aktueller Firmware".


Ich finde nichts darüber, ausser dies:
"Der DynDNS Dienst von MB Connect Line wurde um mymbnet.biz erweitert. Dieser Service wird derzeit kostenlos von MB Connect Line zur Verfügung gestellt. Es ist keine Anmeldung dafür notwendig".

Ich finde es höchst interessant. Es wäre gut wenn wir Erfahrungen austauschen können. Ich bin nur am anfang mit der Ewon/Talk2m.


----------



## jan820813 (3 August 2009)

*Fernwartung*

Hallo Helmut,
ein "recht" sichere und einfache Sache wäre ein VPN-Tunnel über Provider, die die Verbindung verwalten, sich einzuwählen.
Ein Beispiel wäre über DynDNS.org. Da kann man eine sog. static route eintragen.
Im Router des Kunden gibst Du ein, dass der Router zu DynDNS.org eine fetse Verbindung aufbauen soll (mit Benuter und Passwort; Router braucht dann WAN-Anschluss).
Auf deinem PC (der braucht einen offenen Internet-Anschluss) musst Du dann einen VPN-Tunnel einrichten (über Start-> Netzwerk -> Neue Verbindung einrichten -> Verbindung am Arbeitsplatz / VPN).
Dann kast Du Dich in das Netzwerk von dem Router einwählern. Das ist dann so als würdest Du mit deinem PC am Router vom Kunden angeschlossen sein.


----------



## DELTALOGIC Support (3 August 2009)

Hallo PN/DP,

vielen Dank für die umfangreiche Auflistung. Da steckt relativ viel Zeit drin. :TOOL:

Eine Geschichte ist mir noch nicht klar:



PN/DP schrieb:


> Um im Step7-Projekt die öffentliche IP-Adresse des Kundenzugangs korrekt und fest zu hinterlegen, muß einfach nur ein Ethernet-Router eingefügt werden (also eine Station, von der Step7 "weiß", daß sie die Pakete zwischen WAN und LAN routen wird).



Können Sie mir da bitte ein Beispielprojekt schicken? Ich bekomme es nicht hin.

Realer Hardware Aufbau ist bei mir momentan ganz einfach:

SPS(192.168.1.100)<--->Router(192.168.1.1__192.168.0.1)<-->PC(192.168.0.2)

Der Router macht ein Portforwarding (102 TCP) von 192.168.0.1 auf 192.168.1.100.

Ganz logisch erscheint mir Ihre Darstellung allerdings nicht. Warum sollte Step7 in der gezeigten Konstellation die IP Adresse der SPS auf die tatsächlich zugegriffen wird durch die öffentliche IP Adresse der projektierten Router SPS ersetzen?

Die Router Parametrierung passt, und mit "meiner" Methode (IP Adresse in der Hardware Konfiguration ändern) klappt es.

Meine Fragen sind erst gemeint. Ich lerne gerne dazu.

@JesperMP:
Entweder Managed.IP oder fixed.IP. Managed.IP routet ganze Netzwerke (und kostet auch entsprechend), fixed.IP routet nur ein Gerät (den Rest kann man dann meistens per Portforwarding - oder bei geeigneten Geräten mit einem zweiten VPN Tunel - erledigen.

 Danke
Bernhard Götz


----------



## DELTALOGIC Support (3 August 2009)

*Klappt doch*

Hallo PN/DP,

hoffentlich hatten Sie noch keine weitere Arbeit  hab es jetzt doch hin bekommen. Keine Ahnung wiso das vorher nicht ging. Warum es überhaupt funktioniert ist mir noch nicht ganz klar. Vermutlich macht Siemens selber in SIMATIC beim Routing an der Stelle intern in Wirklichkeit ein Portforwarding.

Danke für den Tipp!

Bernhard Götz


----------



## PN/DP (7 August 2009)

*Step7-Beispielprojekt mit Router-Stellvertreter*

Hier das Step7-Beispielprojekt zum Beitrag #15 *Fernzugriff projektieren bei Variante D) Port-Forwarding in der Kunden-Firewall*
(ohne das MP277 - schon ein leeres WinCCflexible-Projekt ist bekanntlich reichlich 1MB groß ;-) )

*Wie kann ich den Router aus dem Beispielprojekt in mein Projekt übernehmen?*

1. die Objekte "Router/Firewall [Fa.xyz]" + "Ethernet(LAN)" + "Ethernet(WAN)" ( + "PG/PC") markieren
2. Bearbeiten -> Kopieren (wichtig: alle auf einmal, damit die Verknüpfungen erhalten bleiben)
3. ins eigene Projekt wechseln (in die oberste Ebene vom Projektbaum)
4. Bearbeiten -> Einfügen
5. Nun noch mit *HW Konfig* die projektspezifischen Einstellungen anpassen:
* "Router/Firewall [Fa.xyz]"
--- den Stationsname "Router/Firewall [Fa.xyz]" in was projektspezifisch-sinnvolles umbenennen
--- CP IE (WAN): die öffentliche IP-Adresse des Kunden eintragen
--- CP IE (LAN): die IP-Adresse des lokalen Standard-Gateway des Kunden eintragen
* "eigene" SPS-Station
--- IE-CP (oder PN-IO-Schnittstelle bei PN/DP-CPUs) mit "Ethernet(LAN)" vernetzen
--- gewünschte IP-Adresse eintragen in IE-CP oder PN-IO-Schnittstelle
--- (x) Router verwenden + IP-Adresse des für die SPS-Station gültigen Standard-Gateway eintragen
* "Ethernet(LAN)" und "Ethernet(WAN)"
--- falls nötig, die S7-Subnetz-IDs ändern mit *NetPro*
* in *NetPro* "Alles übersetzen" und die Konfiguration mit *NetPro* (!) in die "eigene" SPS-Station laden
* bei Bedarf im "PG/PC" die Schnittstellen konfigurieren und parametrieren und das "PG/PC" einem Netz zuordnen

Hinweis 1: HW Konfig lädt die Routing-Tabellen (SDB999) NICHT mit in die SPS-Station, das macht nur NetPro vollständig.
Bei mehreren SPS-Stationen und ggf. mehreren Netzwerken im Projekt sind die Routing-Tabellen aber wichtig.

Hinweis 2: Man sollte sich frühzeitig Gedanken über sinnvolle Stationsnamen machen, weil die Stationsnamen (je nach CPU)
mit in die Station geladen werden. Ändert man später den Stationsname, dann hat man unterschiedliche Systemdaten 
(CPU-Konfigurationen) Online<->Projekt.

Hinweis 3: An Panels muß die Konfiguration der Netzwerk-Schnittstelle manuell im Control-Panel vorgenommen werden, 
sie wird nicht von WinCCflexible eingestellt.

Hinweis 4: Die tatsächliche Netzwerk-Konfiguration beim Kunden wird sich von diesem Beispiel unterscheiden.
Die zu verwendenden IP-Adressen mit dem Kunden-IT-Administrator absprechen!

Hinweis 5: In der "eigenen" SPS-Station "(x) Router verwenden" bzw. im Panel "Default Gateway":
Wenn keine Gateway-Adresse eingetragen wird, dann können die SPS-Stationen nur im gleichen Netzwerk-Segment miteinander 
kommunizieren, die SPS-Stationen bzw. Panele sind aus anderen Netzwerk-Segmenten oder von fern normal nicht erreichbar.
Auf dem Step7-PC kann zwar hilfsweise eine statische Route mit "route add ..." eingerichtet werden, das geht aber nicht über das 
Internet.

Hinweis 6: Solange man nur von fern auf die SPS-Station oder Panels beim Kunden zugreifen will, ist es egal, welche IP-Adresse 
man bei "CP IE (LAN)" einträgt. Es sieht aber in der Dokumentation besser aus, wenn man da was sinniges einträgt. 
Zumindest ist diese Stelle ein guter Merkzettel.


----------



## PN/DP (7 August 2009)

*Step7 RFC1006*

Hallo DELTALOGIC Support,

leider konnte ich nicht eher auf Ihre Fragen antworten. Ich hoffe, meine späte Antwort ist noch von Interesse.



DELTALOGIC Support schrieb:


> Können Sie mir da bitte ein Beispielprojekt schicken?


siehe Posting #22



DELTALOGIC Support schrieb:


> Warum sollte Step7 in der gezeigten Konstellation die IP Adresse der SPS auf die tatsächlich zugegriffen wird durch die öffentliche IP Adresse der projektierten Router SPS ersetzen?



Kurz:
Step7 verwendet das Routing-Protokoll RFC1006 auf dem ISO-tsap Port 102 (also kein Portforwarding)
Step7 versucht den Verbindungsaufbau auf allen dem aktuell eingestellten PG/PC-Schnittstellen-Typ entsprechenden Netzen


*Fall A) im Step7-Projekt ist kein "zugeordnetes" PG/PC vorhanden:*

Abhängig von der Einstellung der PG/PC-Schnittstelle sucht Step7 selbständig einen passenden Weg zur Ziel-SPS.
Solange im Projekt nur 1 Netzwerk vom passenden Typ zur PG/PC-Schnittstelle vorhanden ist, ist Step7 klar an welchem Netzwerk es 
angeschlossen sein müsste und über welche routingfähigen Stationen die Route zur Ziel-SPS führt.

Wenn mehrere vom Typ her passende Netzwerke im Projekt vorhanden sind, versucht Step7 (zumindest bei Ethernet) nacheinander über 
jedes passende Netzwerk mit möglichst wenigen Zwischenstationen eine Verbindung zur Ziel-SPS aufzubauen. Ob vorher eventuell anhand 
der Netzwerkmasks und der Subnetz-Anteile der IP-Adresse der im Step7-PC vorhandenen Netzwerkadapter sowie der IP-Adresse der 
Ziel-SPS eine Vorauswahl stattfindet, weiß ich nicht, ist aber denkbar.

In meinem Beispiel wird Step7 zuerst versuchen, die kurze direkte Verbindung über das IE-Netzwerk Ethernet(LAN) zur Ziel-SPS IP-Adresse 192.168.10.1 aufzubauen. Das wird natürlich nicht klappen (Step7 wird höchstens eine andere SPS finden, falls sich im lokalen Netzwerk des Step7-PC zufällig eine SPS mit der gleichen IP wie die der Ziel-SPS befindet!). :-(
Wenn der Step7-PC zufällig auf einem seiner aktiven Netzwerkadapter eine IP-Adresse mit dem gleichen Netzwerksegment wie die lokale IP-Adresse der Ziel-SPS hat (192.168.10.x), dann scheint Step7 davon auszugehen, es wäre an Ethernet(LAN) angeschlossen und versucht den Verbindungsaufbau nur über diesen direkten Weg.
Meistens wird der Step7-PC auf keiner seiner Netzwerkadapter eine zum fernen Ethernet(LAN) passende IP-Adresse haben.

Da der Verbindungsaufbau zur Adresse 192.168.10.1 am Ethernet(LAN) nicht geklappt hat, versucht Step7 als nächstes eine Verbindung über das IE-Netzwerk Ethernet(WAN). Hier sieht Step7, daß da eine routingfähige SPS-Station mit Verbindung zum Zielnetzwerk Ethernet(LAN) vorhanden ist, welche über die IP 82.176.x.x erreichbar ist. Also schickt Step7 seinen Verbindungswunsch an diese Station. Der reale Router mit der IP 82.176.x.x "forwardet" die Pakte zur Ziel-SPS (das ist ja vom Kunden-IT-Administrator so eingerichtet worden, und das hat Step7 von der "SIMATIC"-Station auch so erwartet). Die Ziel-SPS erkennt anhand der im RFC1006-Paketrahmen enthaltenen Subnet-ID und Ziel-Adresse, daß/ob das Paket für sie selber bestimmt ist.
(Es kann sein, das der RFC1006-Rahmen in Wirklichkeit nur ein erweiterter Header ist. So genau kenne ich das RFC1006-Protokoll nicht.)

Übrigens: Falls keine Verbindung zur Ziel-SPS zustande kommt, versucht Step7 den Verbindungsaufbau (zumindest bei TCP/IP) nicht nur über den ausdrücklich bei der PG/PC-Schnittstelle zugeordneten Netzwerkadapter, sondern davon abweichend über alle gerade aktiven Netzwerkadapter (z.B. WLAN oder DFÜ-Adapter).
(Vielleicht überläßt Step7 die Adapterauswahl auch einfach Windows? eher unwahrscheinlich)


*Fall B) im Step7-Projekt ist ein dem Ethernet(WAN) "zugeordnetes" PG/PC vorhanden:*

Weil Step7 durch das "zugeordnete" PG/PC eindeutig bekannt ist, daß es am Ethernet(WAN) angeschlossen ist, versucht es den Verbindungsaufbau sofort und nur über die Station mit der IP 82.176.x.x

Ich habe mir angewöhnt, immer ein PG/PC ins Step7-Projekt einzufügen, wenn es mehrere Netzwerke vom selben Typ im Projekt gibt.
Dies ist die einzige mir bekannte Möglichkeit, Step7 explizit vorzuschreiben, welchen Weg es zur Ziel-SPS nehmen soll.


*IP-Adressen-Wahl für Automatisierungsnetze*

Wegen der geforderten Trennung von Automatisierungsnetzen vom restlichen Firmennetz verwende ich niemals die IP-Adressen 192.168.0.x ... 192.168.9.x für meine PLC-Netze. Diese IP-Adressen sind oft schon (oder werden irgendwann einmal) für das Büro-Netzwerk des Kunden verwendet. Ich verwende fast immer IP-Adressen aus dem Bereich 192.168.192.x ... 192.168.199.x für meine PLC-Netze. 
Erstens halte ich damit den zeitweise exorbitanten PC-Netzwerktraffik und die öfter vorkommenden Broadcast-Stürme von meinen PLC fern, zweitens ist es dann relativ einfach zu administrieren, wenn Verbindungen zwischen den Netzen benötigt werden, weil z.B. Daten zwischen PLCs und Kunden-PCs (MES, QMS, Archiv-Server, ...) ausgetauscht werden sollen. Für Firewalls sind nur wenige Regeln auf Netzwerk-Adressen-Basis nötig (Zone: Netzwerk 192.168.192.0, Mask 255.255.248.0). 
In dieser Zone habe ich ca. 2000 IP-Adressen für PLCs, Panels und andere Automatisierungskomponenten zur Verfügung!


*Spezialproblem MP277 / WinCCflexible:*

Ich glaube nicht, daß der Projekt-Transfer WinCCflexible -> MP277 funktioniert, wenn man einfach nur im Projekt die öffentliche IP 82.176.x.x direkt in die Hardware-Konfiguration des MP277 einträgt. Normalerweise findet der Transfer über den Port 2308 statt (alternativ Port 50523). Nur wenn WinCCflexible weiß, daß es nicht am selben Netz wie das MP277 angeschlossen ist, dann wird der Transfer über das Protokoll RFC1006 mit Port 102 "getunnelt". 
Eventuell geht das:
Im Transfer-Dialog von WinCCflexible gibt es die Option "(x) Routing aktivieren, nächste Station: xxxxxxx" (oder so ähnlich). 
Ich weiß aber nicht, ob diese Option bei WCF2008 auch für Ethernet verfügbar ist und ob man da die IP 82.176.x.x direkt eintippen kann. Alternativ könnte/müßte in der Kunden-Firewall zusätzlich zum Port 102 auch noch ein Portforwarding für Port 2308 eingerichtet werden. Der Kunde-Administrator wird sich über die bevorstehende Port-"Inflation" freuen ;-)


*Fazit, Credits*, etwas Eigenlob ;-)

Also, ich finde meinen Router-Stellvertreter ziemlich elegant. Er dokumentiert gut die reale Vernetzung und ich kann auf diese Weise jederzeit von fern die Hardware-Konfiguration aus Step7 in die Ziel-SPS laden. Ich habe den Router-Stellvertreter in knapp 10 Projekten eingesetzt. Es funktioniert einfach.

In mehreren Projekten habe ich PLC ohne eigene Ethernet-Schnittstelle mit Ethernet-zu-MPI-Programmieradaptern an Ethernet angeschlossen. Hier füge ich für den Zugriff über Ethernet bzw. Internet eine modifizierte Variante des Router-Stellvertreters in das Step7-Projekt ein (der "CP IE (LAN)" entfällt, die CPU314-MPI-Schnittstelle ist dann mit dem "PLC Network(MPI)" verbunden). Und schon mault Step7 nicht mehr rum: "Die Station ist über Ethernet garnicht erreichbar!".

Obwohl, einen kleinen Schönheitsfehler hat "mein" Router: er sieht aus wie eine SPS und die Schnittstellen werden von NetPro nicht mit den selbst vergebenen Baugruppen-Namen beschriftet ("CP IE (WAN)"), sondern mit den Step7-Kurzbezeichnungen ("CP 343-1").

Ob Siemens eigentlich weiß, wie universell das Objekt-Konzept von Step7 nutzbar ist? ;-) Jedenfalls habe ich diese Konstellation (SIMATIC-Station als Router-Stellvertreter) im Siemens-Support oder in Siemens-Handüchern noch nicht gesehen.

In diesem Forum findet man eine Menge gute Beiträge und Anleitungen zu Netzwerk-spezifischen Problemen:
www.administrator.de - Bereich: Netzwerke und Protokolle


Gute Nacht.
PN/DP


----------



## rostiger Nagel (7 August 2009)

Hallo PN/DP,
noch einmal *VIELEN DANK* und noch einmal ein *DICKES LOB*, 
für deine Ausführungen. 

gruß Helmut


----------



## DELTALOGIC Support (10 August 2009)

Guten Morgen,



Helmut_von_der_Reparatur schrieb:


> Hallo PN/DP,
> noch einmal *VIELEN DANK* und noch einmal ein *DICKES LOB*,
> für deine Ausführungen.



dem kann ich mich nur anschließen.

Bernhard Götz


----------



## Gerhard Bäurle (3 September 2009)

JesperMP schrieb:


> "Der DynDNS Dienst von MB Connect Line wurde um mymbnet.biz erweitert. Dieser Service wird derzeit kostenlos von MB Connect Line zur Verfügung gestellt. Es ist keine Anmeldung dafür notwendig".



Hallo,

auf *mymbnet.biz* ist jetzt eine kurze Erläutung zur Funktionsweise.


----------



## rostiger Nagel (21 September 2009)

Hier noch eine ergänzung aus dem Siemens FAQ:
http://support.automation.siemens.c...cslib.csinfo&lang=de&objid=38571711&caller=nl


----------



## PN/DP (22 September 2009)

*Anregung zum Siemens A&D Support Beitrag 38571711*

Danke Helmut für den Hinweis auf den neuen Beitrag im Siemens A&D Support.

Der Beitrag hat den Titel:
*Was ist beim Fernzugriff auf eine SIMATIC S7 mit STEP 7 über das Internet zu beachten?*

In dem Beitrag wird lediglich die einfachste, gleichzeitig jedoch gefährlichste technische 
Möglichkeit für einen Fernzugriff auf Automatisierungssysteme beschrieben: 
die einfache Portweiterleitung des Port 102 im Internet-Gateway der Anlage.

*Was tatsächlich unbedingt zu beachten ist, kommt in dem Beitrag jedoch nicht vor:
der (nicht vorhandene) Schutz vor unbefugten Zugriffen!*

Ich vermisse einen deutlichen Warnhinweis, daß bei dieser Fernzugriffs-Lösung unbefugte 
Zugriffe auf das Automatisierungssystem für jedermann ohne weiteres möglich sind.

Für Netzwerk-unkundige SPS-Techniker kann der Eindruck entstehen, daß die im Beitrag 
beschriebene Fernzugriffs-Lösung eine "ganz normale Sache" ist, die zudem ja von Siemens 
öffentlich empfohlen wurde.

Mir kommt es so vor, als ob den Artikel irgendein Praktikant bei Siemens geschrieben hat, der 
sich zwar viel Mühe mit den bunten Bildchen gemacht hat, aber die Tragweite des Themas nicht 
überblickt. Das kann auf keinen Fall von einem verantwortungsbewußten Support-Mitarbeiter 
stammen.

Bei den Beiträgen im Siemens A&D Support gibt es Möglichkeiten, interaktiv seine Meinung 
zu den Beiträgen dem A&D Support kund zu tun:

*Dieser Artikel...*




hat mir geholfen



hat mir nicht gholfen



Anregung zum Beitrag

Den letzten Punkt habe ich mal genutzt und meine Anregungen zu dem Beitrag verschickt. 
Den genauen Wortlaut will ich hier lieber nicht veröffentlichen, nur soviel:
Ich habe den nicht vorhandenen Warnhinweis auf den nicht vorhandenen Zugriffs-Schutz 
bemängelt und dem Autor empfohlen, diesen Thread hier im SPS-Forum zu lesen.

Und was die technische Qualität des Beitrags anbetrifft:
Umständlicher und verwirrender geht es ja wohl kaum noch.
Da wird doch allen ernstes empfohlen, alle Steuerungen doppelt im Step7-Projekt einzufügen!
Ob damit ggf. auch im Step7-Projekt integrierte HMI-Stationen (WinCC flexible) gemeint sind?

Irgendwie passt der Beitrag zur Qualität der Problem-Tip-Mails vom Siemens A&D Technical 
Support in letzter Zeit. Da hat sich wohl so mancher schon gefragt, ob die wohl von einem 
deutschen Ingenieur geschrieben wurden.

Gruß Harald


----------



## PN/DP (22 September 2009)

*Simatic-Station als Stellvertreter für Netzübergänge*

Hier mal noch ein Beispiel für unechte Simatic-Stationen als Stellvertreter für Router, Gateways, ganz allgemein Netzübergänge 
(die gelb gefärbten Stationen).

Die beiden Netlinks stellen Ethernet-Adapter dar (Netlink, S7LAN, ...).
Wenn die Ethernet-Adapter RFC1006 unterstützen, dann braucht man keine Treiber-Software für PC-Adapter und keine 
virtuellen COM-Ports mehr. Step7 findet dann auch allein den gerouteten Weg zu den verschiedenen Stationen.






Falls Siemens hier mal liest:
Es wäre echt hilfreich, wenn man das Aussehen der Simatic-Stationen individuell anpassen könnte (eigene Bitmap).

Gruß Harald


----------



## PN/DP (27 September 2009)

*Siemens reagiert auf Anregungen zu A&D Support Beitrag 38571711*

Für meine Anregungen zum Siemens A&D Support Beitrag
Was ist beim Fernzugriff auf eine SIMATIC S7 mit STEP 7 über das Internet zu beachten?
hat sich der Siemens Industrial Automation Systems Customer Support am 25.09.2009 bedankt. 
Der Beitrag wird nun von Siemens überarbeitet.

Danke
Harald


----------



## Rainer Hönle (28 September 2009)

Diese Seite ist momentan nicht erreichbar. War das doch zuviel für die Jungs?


----------



## PN/DP (28 September 2009)

*Beitrag wird überarbeitet*

Zitat aus der Antwort vom Siemens Industrial Automation Systems Customer Support:


> Wir werden den Beitrag 38571711 überarbeiten. Bis dahin werden wir ihn zunächst aus dem Internet nehmen.



Gruß Harald


----------



## rostiger Nagel (28 September 2009)

Harald,
da schau aber mal was die so schreiben, wenn sie
deine beiträge abschreiben, halte die Hand auf...

gruß helmut


----------



## PN/DP (28 September 2009)

Helmut,

ich kann ja schon mal in den Weiten des Inet ein großes Smilie mit gaaaanz breitem Grinsen suchen. 

Gruß Harald


----------



## Sinix (13 November 2009)

Hallo,

vielen Dank für die vielen sehr guten Beiträge zum Thema Fernwartung.
Da ich in letzter Zeit zunehmend mit der Thematik als Leidensgenosse von Helmut zu tun habe würde ich gern zu:



> *B) Mitglied des fernen Firmennetzwerkes werden über (SSL-)VPN-Zugang*
> 
> ...
> 
> ...


...wissen was man tun kann, um im Laufe der Zeit nicht eine Vielzahl von VPN-Software auf dem Service-PG zu verwalten. 

Ich sehe zum einen das Problem des Troubleshooting und zum anderen  Probleme wenn der Admin des Kunden Einstellungsänderungen vornimmt und nicht zu uns weiterleitet.

Die oben vorgeschlagene Software mag zwar super sein, aber letztendlich muss man das nehmen, was der Kunde hat. Die Kostenersparnis für mich steht derzeit meinen Problemen gegenüber.


----------



## DELTALOGIC Support (13 November 2009)

Hallo,

die angesprochene Problematik mit der Vielzahl verschiedener Zugänge und Softwaren ist vorhanden und lässt sich höchstens umgehen, indem man konsequent ausschließlich Mobilfunkgeräte selber liefert und autark vom restlichen Netz des Kunden verwendet. Sobald man verschiedenen Kunden ins Netzwerk muß, hat man verschiedene Systeme. Schon der Versuch sich nur den für die bevorzugte VPN Lösung benötigten Port vom Kunden für ausgehende Verbindungen freischalten zu lassen, wird nicht überall funktionieren.

SSL-VPN hat auch seine Grenzen, z.B. wenn man mal von einem mobilen Gerät ohne MS Betriebsystem zugreifen will. In der Bedienung ist es tatsächlich recht bequem. Dafür ist die Fehlerdiagnose teilweise sehr schwierig, weil gängige Diagnosewerkzeuge nicht richtig damit umgehen können, da ein SSL VPN nicht als Netzwerkschnittstelle im System angemeldet ist.

Ich persönlich finde OpenVPN sehr gelungen. Leichte Handhabung, leichte Parametrierung, wenig Anforderungen an die Verbindung (nur ein UDP Port wird benötigt), sichere Verschlüsselung, plattformübergreifend verfügbar (Windows und Linux sind mir wichtig), günstig, sehr gute Diagnosemöglichkeit.

Ein einziges VPN System anwenden zu können, können sich wohl nur Firmen erlauben, die ausschließlich ihre eigenen Systeme fernwarten und für die Fernwartung selber verantwortlich sind.

Bernhard Götz


----------



## Sinix (13 November 2009)

DELTALOGIC Support schrieb:


> die angesprochene Problematik mit der Vielzahl verschiedener Zugänge und Softwaren ist vorhanden und lässt sich höchstens umgehen, indem man konsequent ausschließlich Mobilfunkgeräte selber liefert und autark vom restlichen Netz des Kunden verwendet.
> Bernhard Götz



Damit wären aber die Kosten zumeist wieder auf der Lieferantenseite und wie sieht es mit der Übertragungsgeschwindigkeit in weniger industrialisierten Gegenden aus, sprich dort wo keine dicken Mobilfunkantennen installiert sind?


----------



## DELTALOGIC Support (13 November 2009)

Hallo,

dort ist oft noch EDGE verfügbar, und zumindest für die Anbindung einer SPS reicht das um vernünftig zu arbeiten. Megabyteweise Downloads sollte man sich da natürlich verkneifen.

Mit guten Richtantennen kann man bei Stationärer Montage und Sicht zum Funkturm durchaus 5km und mehr überbrücken - da wird es dann eben wieder aufwändiger, wegen Blitzschutz und witterungsunempfindlichen Antennen. Wenn der Aufwand mal so groß ist, kann man sich dann auch wieder mit verschiedenen VPN und Admins rumschlagen.

Kosten der Mobilfunklösung krigt man recht leicht auf die Kundenseite - Kunde soll die Karte stellen, Gerätekosten werden in der Anlage mit eingerechnet. Klappt natürlich nicht bei jedem Kunden  letztendlich muß jedoch der Kunde die Kosten tragen, denn vom Drauflegen kann der Lieferant nicht leben 

Bernhard Götz​


----------



## Sinix (16 November 2009)

...in Zeiten der Finanzkrise ist der Verkaufspreis einer Maschine oft das Argument das gegenüber Mitbewerbern entscheidet. Da bekomme ich als Programmierer/E-Planer auch die Pistole zur Kostenersparnis auf die Brust gesetzt,d.h. teuere Fernwartungsgeräte fallen aus dem Angebot. Das natürlich ein After-Sales-Service in Garantiezeit ohne Fernwartung die eigenen Kosten wieder steigen lässt, davon lassen sich die Kaufleute nur schwer überzeugen. Aber das gehört hier nicht zum Thema.

Gibt es vielleicht noch andere Vorschläge/Meinungen zu meiner Frage oben?
Ich weis z.B. von Lösungen mit der Software PC-Anywhere, habe aber keine Erfahrungen?


----------



## Rainer Hönle (16 November 2009)

PN/DP schrieb:


> Für meine Anregungen zum Siemens A&D Support Beitrag
> Was ist beim Fernzugriff auf eine SIMATIC S7 mit STEP 7 über das Internet zu beachten?
> hat sich der Siemens Industrial Automation Systems Customer Support am 25.09.2009 bedankt.
> Der Beitrag wird nun von Siemens überarbeitet.
> ...



Das ist jetzt bald zwei Monat her und die Seite ist immer noch nicht erreichbar. Die Überarbeitung scheint doch was Größeres zu sein.


----------



## DELTALOGIC Support (16 November 2009)

Guten Morgen



Mäuseklavier schrieb:


> Gibt es vielleicht noch andere Vorschläge/Meinungen zu meiner Frage oben?
> Ich weis z.B. von Lösungen mit der Software PC-Anywhere, habe aber keine Erfahrungen?



Fernwartungslösungen gibt es sehr viele - und auch sehr unterschiedliche Konzepte. Jedes Konzept hat Vor- und Nachteile. Im Falle von PCAnnywhere z.B. wird an der Anlage eben die Projektiersoftware auf einem PC benötigt. Wenn dafür extra eine Step7 Lizenz gekauft werden muß, spart das auch kein Geld mehr.

Ansonsten hört sich das für mich stark nach einem Fall an, "wer nicht hören will muß fühlen". Kaufleute die einmal begriffen haben, was Fernwartung für ein Einsparpotential (Personal- und Reisekosten, Reaktionsgeschwindigkeit) birgt, können das auch gut verkaufen. Nur wenn sie der Meinung sind, Fernwartung wäre nur ein Luxus für faule SPS Programmierer und völlig unnötig, werden sie sie auch nicht verkaufen.

Bernhard Götz


----------



## Gerhard Bäurle (16 November 2009)

Mäuseklavier schrieb:


> ...
> Gibt es vielleicht noch andere Vorschläge/Meinungen zu meiner Frage oben?
> Ich weis z.B. von Lösungen mit der Software PC-Anywhere, habe aber keine Erfahrungen?



 Eine pauschael Empfehlung macht keien Sinn, da uns eine genaue 
Umgebung nicht bekannt ist. Fernsteuersoftware wie PC-Anywhere 
setzt voraus, dass vor Ort ein PC ist UND dass dort die notwendige 
Software (STEP7) vorhanden ist. 

Wenn beides sowieso da ist, ist PC-Anywhere OK. Muss Du auch nur 
die Software kaufen, ist ein Fernwartungssystem meist günstiger.


----------



## Gerhard Bäurle (16 November 2009)

Mäuseklavier schrieb:


> ... d.h. teuere Fernwartungsgeräte fallen aus dem Angebot. Das natürlich ein After-Sales-Service in Garantiezeit ohne Fernwartung die eigenen Kosten wieder steigen lässt, davon lassen sich die Kaufleute nur schwer überzeugen...



Nachtrag:
Allerdings würde ich bei solchen "Kaufleuten" eher nach einem neuen 
Job suchen. Wer 1.000 Eur spart um 10.000 zu riskieren, der fährt
die Firma früher oder später ohnehin an die Wand.


----------



## Sinix (16 November 2009)

Das bedeutet bei PC-Anywhere handelt es sich um eine Lösung nach:



PN/DP schrieb:


> *C) RemoteDesktop-Verbindung zu einem vor-Ort-PC, der Step7 (...) installiert hat*



wobei der Vorteil sicher bei der Verwendung einer Soft-PLC liegt. Ein entscheidender Vorteil solch einer Fernwartung ist mit Sicherheit dann gegeben, wenn viele Steuerungen an verschiedenen Anlagenteilen bei einem Kunden betreut werden sollen. Bei nur einer Anlage und muss ein externer PC angeschlossen werden  halte ich dies nur bedingt sinnvoll, da hier wiederum eine Schnittstelle (z.B. CP) installiert werden muss. Bei vorinstallierter Projektierungs-Software könnten die Lizenzen kurzfristig online übertragen werden, allerdings müssten die Lizenzen immer dem Softwarestand entsprechen.


----------



## DELTALOGIC Support (16 November 2009)

Hallo,


Mäuseklavier schrieb:


> Bei vorinstallierter Projektierungs-Software könnten die Lizenzen kurzfristig online übertragen werden, allerdings müssten die Lizenzen immer dem Softwarestand entsprechen.



Das würde ich niemals so machen. Grund ist, daß zum Einen die Übertragung der Autorisierung im Rahmen der meißten Remote Desktop Tools nicht funktioniert und zum Anderen Siemens hier mit der nächsten Version des Automation License Managers Änderungen implementieren kann und damit immer die Gefahr besteht, daß es nicht mehr geht. Das merkt man natürlich erst, wenn man die Fernwartung braucht, und dann bricht die Panik aus 

Bernhard Götz


----------



## o_prang (16 November 2009)

Hallo mäuseklavier,

wie 'Deltalogic Support' schon geschrieben hat, gibt es unzällige Möglichkeiten der Fernwartung.
Und es gibt leider nicht die "eierlegendewollmilchsau" wo alles ganz einfach, flexibel und umsonst ist.
Jede Anlage, jeder Kundeneinsatz und jeder grundsätzlicher Wunsch was ist über Fernwartung erreichen will, kann neue Vorraussetzungen schaffen.

Vielleicht kannst Du mal schildern, was genau Du vor hast. Ich denke dann kann Dir am Besten geholfen werden, etwas Licht ins Dunkel zu bringen.


----------



## Sinix (16 November 2009)

@ DELTALOGIC Support

...genau deshalb lehne ich diese Fernwartungsvariante eigentlich ab...

@ o_prang

... mein aktueller Status ist, dass ich prinzipiell 2 Fernwartungsvarianten anbiete/installiere, dies hauptsächlich zum Zugriff auf S7-Steuerungen. Bedeutende Gesichtspunkte sind dabei Sicherheit, Verfügbarkeit, Geschwindigkeit, sowie fixe und variable Kosten. Die erste Variante ist der Einsatz von TS-Adapter ISDN, funktioniert super usw. 

Um den Trend der Technik zu folgen setze ich mittlerweile oft eine SPS mit Ethernetschnittstelle ein (z.B. Siemens Profinet). Um die Performance zu nutzen und Kosten zu sparen soll die Fernwartung über Ethernet erfolgen. Hier komme ich aber mittlerweile zu dem Problem meiner Frage oben: Viele verschiedene VPN-Clients auf meinem Service PG --> Troubleshooting 
Mit derzeit 3 verschiedenen Clients komme ich noch klar, aber es ist abzusehen das wenn es zukünftig mehr werden dies wohl in die Hose geht:sm23:


----------



## o_prang (17 November 2009)

Hi Mäuseklavier,

verschiedene Varianten dem Kunden anzubieten, ist auf jeden Fall der richtige Weg.
Ich würde versuchen, dem Kunden meine eigene Lösung der Fernwartung "aufzudrücken". Das ist sicherlich die Beste Möglichkeit für Dich. Auf wenn es nicht immer zum Erfolg werden wird!

Als Alternative zur DFÜ-Verbindung (mit dem ISDN Gerät)würde ich Dir eine Internetbasierende Lösung mit einem zentralen Server (wie Talk2M und wohl auch MBNet) vorschlagen. 
Dann gehts Du mit Deinem PC ins Internet (keine Kosten), die Maschine über das Kunden-LAN oder DSL ebenfalls (keine Kosten). 
So musst Du nur einmal die Geräte zahlen, und nix für die Verbindung.

Ich geben Dir Recht das viele VPN Clients auf einem PC nicht miteinander zurecht kommen. Da sind viele Probleme schon vorprogrammiert. Deswegen sollte man versuchen, dies tunlichst zu vermeinden. Kannste aber nur, wenn Du dem Kunden eine durchgängige Lösung vorschlagen kannst.


----------



## Rainer Hönle (28 November 2009)

PN/DP schrieb:


> Für meine Anregungen zum Siemens A&D Support Beitrag
> Was ist beim Fernzugriff auf eine SIMATIC S7 mit STEP 7 über das Internet zu beachten?
> hat sich der Siemens Industrial Automation Systems Customer Support am 25.09.2009 bedankt.
> Der Beitrag wird nun von Siemens überarbeitet.
> ...


Beitrag ist wieder online. Aber außer dass dort vpn empfohlen wird, hat sich doch nicht wirklich was geändert oder sehe ich das falsch?


----------



## SiPro (3 März 2010)

@PN/DP
wie kann man bei deinem Beispiel unterscheiden, ob man auf Anlage1 oder Anlage2 zugreifen will. Ich habe mal ein Beispiel aufgesetzt und den Netzwerkverkehr gesnifft. Der Simatic Manager versucht immer eine Verbindung zu 82.176.x.x )um bei deinem Beispiel zu bleiben) aufzubauen. An welche SPS (Anlage1 oder Anlage2) forwarded dein Kunde den Port102?
Danke
SiPro


----------



## PN/DP (3 März 2010)

Hallo SiPro

ich nehme mal an, Deine Frage bezieht sich auf meinen Beitrag #15 mit diesem Bild 









SiPro schrieb:


> An welche SPS (Anlage1 oder Anlage2) forwarded dein Kunde den Port102?


In der Kunden-Firewall (82.176.x.x) ist der Port 102 zu "PLC Anlage1" (192.168.10.1) geforwarded.
(natürlich, weil es die einzige SPS mit Ethernet-Anschluß ist).


SiPro schrieb:


> wie kann man bei deinem Beispiel unterscheiden, ob man auf Anlage1 oder Anlage2 zugreifen will.


Auf welche Anlage Du zugreifen willst, das weißt Du am Besten.
Step7 erkennt es daran, aus welchem Bausteinordner welcher Station du den Zugriff machst.
(Online-Ansicht, Baugruppenzustand, Bausteine übertragen oder beobachten, Variablentabelle, ...)

Für den Zugriff auf das MP277(1) aus WinCC flexible 2008 müßte man in WinCC flexible einstellen:
Routing aktivieren, nächste Station: 192.168.10.1 
(das hoffe ich jedenfalls, ich habe das mit WCCf2008 noch nicht ausprobiert)
Wäre das MP277(1) mit dem MPI(PLC Network) verbunden, dann sollte man theoretisch garnichts 
einstellen müssen, weil dann die "PLC Anlage1" den WCCf-Zugriff zum MP277(1) routet.

Gruß
Harald


----------



## SiPro (4 März 2010)

Guten Morgen Harald,

danke für Info.
Gibt es denn auch eine Lösung, wenn ich mehrere SPS'n über Ethernet vernetzt habe? 
Ist es denn grundsätzlich so, dass dann die SPS1 immer an die anderen weiter routet?
Hat jemand auch Erfahrung mit SIMOTION Scout in dieser Konstellation (Anstatt der SPS eine SIMOTION)?
Vielen Dank im voraus
Gruß
SiPro


----------



## Rainer Hönle (4 März 2010)

Routing funktioniert nur bei unterschiedlichen Netzen. Wenn alle am Ethernet hängen sind sie ja direkt erreichbar. 
Aber für genau diese Anforderung haben wir ein kleines :TOOL: entwickelt. Weitere Infos dazu hier .... 
Dieses Tool klinkt sich in die PG/PC-Schnittstelle ein und man kann IP-Adressen und Portnummern "on the fly" austauschen lassen, ist somit nicht mehr auf Port 102 festgelegt. Damit sind dann problemlos mehrere SPSen hinter einem Router erreichbar und das S7-Projekt muss nicht geändert werden. Achtung: für eine gesicherte Übetragung sollte zusätzlich VPN verwendet werden.


----------



## IBFS (4 März 2010)

@Rainer Hönle
Seit wann gibt es denn das Tool. Das ist mir bisher garnicht aufgefallen.

Gruß


----------



## Rainer Hönle (4 März 2010)

Dieses Tools ist brandneu und erst seit kurzem freigegeben.


----------



## tobias (4 März 2010)

Rainer Hönle schrieb:


> Dieses Tools ist brandneu und erst seit kurzem freigegeben.


 
Hallo
da ich auf VPN (eigentlich zukünftig wieder) verzichten möchte - benutze ich z.Zt. aus MicroWin - käme auf den ersten Blick dies 'Tool' meiner Vorstellung wahrscheinlich weitgehend entgegen.



> Software-Anforderungen Standard-Engineering-Tool von Siemens, z. B. SIMATIC Manager. *Das Systemsteuerungs-Applet »PG/PC-Schnittstelle einstellen« muss vorhanden sein.*



Überwiegend sind allerdings 21x und 22x - neuerdings einige 12xy bei uns vernetzt. 
Das »PG/PC-Schnittstelle einstellen« -Applet ist dabei ja dem Step7 identisch - Frage nun (die 21x mal aussen vorgelassen): Würde das mit den 22x plus CP243-1 aus MicroWin bzw. 12xy aus Basic auch funzen ?

Gruss
tobias


----------



## Rainer Hönle (4 März 2010)

MicroWin und Basic habe ich noch nicht damit getestet. Bei der 200er gehe ich davon aus, dass es funktioniert (da unser ACCON-NetLink ja auch für MicroWin freigegeben ist). Die 1200er-Software muss ich mir diesbezüglich ansehen. Oder selbst kurz mit der Demo testen.


----------



## PN/DP (4 März 2010)

*zwei Fragen*

Hallo Rainer,



Rainer Hönle schrieb:


> ... Damit sind dann problemlos mehrere SPSen hinter einem Router erreichbar und das S7-Projekt muss nicht geändert werden. Achtung: für eine gesicherte Übetragung sollte zusätzlich VPN verwendet werden.


*Frage 1:* Wenn ich VPN benutze, wozu brauche ich dann Euer neues Tool "ACCON-TeleService IE"?
(ich bin ja schon über den VPN-Kanal hinter der Firewall direkt im PLC-LAN)

*Frage 2:* Ist mit "ACCON-TeleService IE" folgende Aufgabe realisierbar?
In einem Projekt habe ich mehrere CPU315, die sind untereinander mit MPI vernetzt.
Jede 315-Station hat einen eigenen CP343-1 zum PLC-LAN.
Bei Station1 funktioniert der CP343-1 nicht (SF oder CPU ist in Stop und fordert Urlöschen an).
Kann ich nun mittels "ACCON-TeleService IE" über den CP343-1 der Station2 -> CPU Station2 -> MPI 
auf die CPU der Station1 zugreifen?
(in Step7 kann ich diese Wegewahl ja nicht direkt vorschreiben)

Gruß
Harald


----------



## Rainer Hönle (4 März 2010)

> *Frage 1:* Wenn ich VPN benutze, wozu brauche ich dann Euer neues Tool "ACCON-TeleService IE"?
> (ich bin ja schon über den VPN-Kanal hinter der Firewall direkt im PLC-LAN)


Das hängt davon ab. 
Wenn die Adressen der SPSen im Projekt auch im lokalen Netz erreichbar wären, wird nicht über VPN geroutet. 
Wenn die VPN nur bis zum Router (unter Beaufsichtigung der IT) geht und das PLC-Netz hinter einem zweiten Router (Firewall) sitzt, ist das auch ein Fall für ACCON-TeleService IE. 



> *Frage 2:* Ist mit "ACCON-TeleService IE" folgende Aufgabe realisierbar?
> In einem Projekt habe ich mehrere CPU315, die sind untereinander mit MPI vernetzt.
> Jede 315-Station hat einen eigenen CP343-1 zum PLC-LAN.
> Bei Station1 funktioniert der CP343-1 nicht (SF oder CPU ist in Stop und fordert Urlöschen an).
> ...


Ist derzeit nicht direkt ein Fall für ACCON-TeleServie IE. Wir senden nur den Connection Request direkt weiter. Und wenn dieser keine Routinginfo besitzt, wird auch nicht über Routing zugegriffen (eine derartige Erweiterung ist aber denkbar ;-)). 
Im aktuellen Fall würde ich Folgendes vorschlagen: In der Hardwarekonfig die entsprechende CP als nicht "vernetzt eintragen". Dadurch sollte die Siemens-Software erkennen, dass der Zugriff über TCP/IP nicht möglich ist und über einen gerouteten Zugriff (TCP/IP->MPI) die Verbindung aufbauen. Dies ist jetzt mal meine persönliche Einschätzung wie es gehen könnte, müsste aber mit der Siemens-Software verifiziert werden.


----------



## PN/DP (4 März 2010)

Hallo Rainer,

Danke für die Antworten.



Rainer Hönle schrieb:


> Im aktuellen Fall würde ich Folgendes vorschlagen: In der Hardwarekonfig die entsprechende CP als nicht "vernetzt eintragen".


Ja, das funktioniert. Allerdings kann ich dann die HW-Konfig nicht mehr direkt in die CPU einspielen,
nur über den Umweg vorher gesicherter "Systemdaten".

Ich habe in dem beschriebenen Fall jeden CP343-1 mit einem anderen Ethernet vernetzt und im Projekt ein 
PG/PC eingefügt, das dem jeweiligen Ethernet zugeordnet wird.
Der Zugriff auf eine andere Station wird nur ziemlich langsam, wenn ich vergesse, die Zuordnung zu ändern.
(weil Step7 dann ja den Weg über die zugeordnete Station und MPI nimmt)

Gruß
Harald


----------



## Rainer Hönle (4 März 2010)

Kann die CP wieder zum vernüftigen Leben erweckt werden? Oder hat sie ein grundsätzliches Problem?
Wenn Du mit Step7 die Hardwarekonfig nicht wieder vernünftig (also mit aktiver CP) auf die SPS bringst, dann könnte ich auch dafür eine Lösung bieten: Unser ACCON-S7-Backup unterstützt (in der Version die nächste Woche freigegeben wird) Routing. Allerdings werden nicht die Routinginformationen aus dem Projekt verwendet sondern entsprechend parametriert. Damit wäre es möglich, den Zugang über TCP/IP->MPI auf die SPS mit der defekten CP zu erhalten und die originalen Systemdaten mit der korrekten Einstellung für den CP zu übertragen. Habe ich allerdings auf diese Weise auch noch nicht (und schon gar nicht über Fernwartung) getestet.


----------



## PN/DP (4 März 2010)

In dem Projekt sind 8 ältere CPU 315-2AF03 (V1.2.0) und CP 343-1EX11 (V2.0.0) verbaut.
Alle paar Monate geht aus unerfindlichen Gründen irgendeine der CPU in Stop und fordert
Urlöschen an. In diesem Zustand ist die CPU nur über MPI erreichbar, der CP kann da wohl 
nichts dafür. Das ist ein Problem der Firmware der CPU (und vielleicht des CP).



PN/DP schrieb:


> Allerdings kann ich dann die HW-Konfig nicht mehr direkt in die CPU einspielen,
> nur über den Umweg vorher gesicherter "Systemdaten".


Damit meine ich, mit dem temporären "nicht vernetzt" eintragen in den CP ändert sich ja 
die Hardwarekonfig im Step7-Projekt und diese verfälschten "Systemdaten" kann ich nicht 
in die CPU einspielen, sonst würde danach die Station nicht mehr funktionieren.

Wenn nur das Programm zu beobachten oder zu ändern oder der CP tatsächlich defekt wäre, 
dann wäre Dein Workarround durchaus hilfreich, die CPU überhaupt zu erreichen.

Gruß
Harald


----------



## Rainer Hönle (4 März 2010)

Mit meinem Workaround könntest Du die unveränderten Systemdaten über ein Zwangsrouting wieder in die SPS nach Urlöschen mittels ACCON-S7-Backup einspielen.
Nachtrag: In der Hoffnung dass das nach dem Urlöschen mit den Routinginfos noch hinhaut. Ich gehe aber davon aus, dass die Infos nur für die Stationen davor wichtig sind. Der oder die letzte muss ja nicht mehr routen.


----------



## Rainer Hönle (4 März 2010)

tobias schrieb:


> Hallo
> da ich auf VPN (eigentlich zukünftig wieder) verzichten möchte - benutze ich z.Zt. aus MicroWin - käme auf den ersten Blick dies 'Tool' meiner Vorstellung wahrscheinlich weitgehend entgegen.
> 
> Überwiegend sind allerdings 21x und 22x - neuerdings einige 12xy bei uns vernetzt.
> ...


So, habe jetzt mal bei STEP7 Basic nachgesehen. Die verwenden nicht die PG/PC-Schnittstelle sondern greifen direkt auf die Netzwerkkarte zu. Da sind wir dann leider nicht im Spiel.


----------



## tobias (4 März 2010)

Hallo und vielen Dank !




Rainer Hönle schrieb:


> So, habe jetzt mal bei STEP7 Basic nachgesehen. *Die verwenden nicht die PG/PC-Schnittstelle sondern greifen direkt auf die Netzwerkkarte zu* Da sind wir dann leider nicht im Spiel.


Das ist natürlich ein kleiner, aber feiner Unterschied. War auch mir bisher so nicht aufgefallen - dachte über die Netzwerkkarte wäre (default)-Voreinstellung und hatte im Basic nach weiteren Schnittstellen(einstellungen) noch gar nicht gesucht. 
Für Mitte April habe ich das Tool hier auf der Liste reingequetscht - melde mich dann.
Gruss
tobias


----------



## markham (6 September 2010)

Hallo an Alle,

ich möchte gerne diesen Thread nochmals aufgreifen, da ich Probleme habe mich in ein S7 Steuerung über VPN einzuwählen.

Folgendes Szenario ist gegeben:
Wir arbeiten mit einem großen Maschinenhersteller aus Deutschland zusammen. Dieser Hersteller hat beim Endkunden einen VPN-Router installiert und für uns einen Zugang eingerichtet. Hier mal die Konfiguration:

IP: 192.178.190.24
Sub: 255.255.255.128
Gateway: 192.178.190.1
NAT-IP: 10.19.93.24

So wie ich das verstanden habe, wählen wir uns bei unserem Maschinenhersteller ein, der uns dann zu dem Endkunden weiterleitet (ich vermute ähnlich wie das Talk2M mit den eWon Geräten). 
Mit dem Cisco Client kann ich mich einwählen und die NAT-IP 10.19.93.24 anpingen.
Ein Übertragen bzw. Baustein online aufrufen ist allerdings nicht möglich. TCP Port 102 ist frei geschaltet. Die Einwahl-IP, die mir unter ipconfig/all vom Cisco VPN-Adapter angezeigt wird ist die 10.42.4.63, Sub 255.0.0.0

Auf Anfrage hat mir ein Mitarbeiter von unserem Maschinenhersteller gesagt, dass ich bei den Eigenschaften des CP343 als IP die NAT-IP 10.19.93.24 angeben soll, Subnet und Gateway sollen gleich bleiben. Allerdings wird die Konfiguration von Siemens S7 so nicht übernommen mit dem Hinweis: Die beiden Felder „Ip-Adresse“ und „Router“ müssen bezüglich des Netzwerkteils übereinstimmen. Der Mitarbeiter meinte dann, dass Simatic S7 das nicht unterstützt und eine Einwahl nicht möglich wäre. 

Nun zu meinen Fragen:
- Gibt es denn noch eine andere Möglichkeit das Ganze hinzubekommen? Ich dachte mir dass vielleicht von Deltalogic die Software Accon S7-Net funktionieren könnte, hab es aber nicht hinbekommen, bzw. wies ich nicht genau was ich einstellen muss. 

- Wenn ich im Net-Pro das ganze so aufbaue wie im Beitrag 15 (http://sps-forum.de/showpost.php?p=209220&postcount=15), würde es dann funktionieren? Dies hätte natürlich den Nachteil, dass ich nochmals zum Kunden fahren muß.

- Oder habe ich generell was falsch verstanden?

Bitte um Hilfe und Danke schon mal im Voraus.

Markham


----------



## PN/DP (7 September 2010)

*Fernzugriff projektieren bei NAT*

Hallo Markham,

das muß ja ein wirklich sehr großer Maschinenhersteller sein, der meint, daß er über 16 Millionen NAT-IP-Adressen braucht.
Ich frage lieber nicht, wer sich sowas ausgedacht hat und warum.



markham schrieb:


> Dieser Hersteller hat beim Endkunden einen VPN-Router installiert und für uns einen Zugang eingerichtet. [...]
> So wie ich das verstanden habe, wählen wir uns bei unserem Maschinenhersteller ein, der uns dann zu dem Endkunden weiterleitet


Du wählst Dich also nicht direkt auf den VPN-Zugang des Endkunden ein, sondern beim Maschinenhersteller und bekommst z.B. die IP 10.42.4.63 
zugewiesen. Dann sollst Du alles, was für die SPS 192.178.190.24 beim Endkunden bestimmt ist, zur NAT-IP 10.19.93.24 schicken. Da Du diese 
Adresse anpingen kannst, existiert diese Adresse schon. Deine SPS kann auf keinen Fall diese Adresse 10.19.93.24 bekommen. Hinter dieser 
Adresse verbirgt sich ganz allgemein ein Router, der Dich durch den VPN-Kanal zum Endkunden bringt. Der Hinweg zur SPS ist also klar.
Wenn Du Dich direkt beim Endkunden per VPN einwählen würdest, dann wäre das ganze NAT-IP-Gedöns sinnlos.



markham schrieb:


> Auf Anfrage hat mir ein Mitarbeiter von unserem Maschinenhersteller gesagt, dass ich bei den Eigenschaften des CP343 als IP die NAT-IP 10.19.93.24 angeben soll, Subnet und Gateway sollen gleich bleiben. Allerdings wird die Konfiguration von Siemens S7 so nicht übernommen.


Solchen Unfug verbreitet auch Siemens, daß für die Dauer der Online-Sitzung die öffentliche IP-Adresse (bei Dir die NAT-IP) im Step7-Projekt 
eingetragen werden soll, weil Sie nicht wissen, wie man auf anderem Weg Step7 mitteilt, daß es die Pakete zur SPS an diese Adresse schicken 
soll. Diese HW-Konfig darf auf keinen Fall in die reale SPS geladen werden!

Das S7-HW-Konfig das abweist ist allerdings logisch. Kein mir bekannter CP343-1 unterstützt default Gateways außerhalb des eigenen Netzwerk-
Segmentes. Für das Routing nach außerhalb des eigenen Netzes ist ja schließlich das Gateway zuständig.
Der Knackpunkt für den Rückweg ist also das Gateway 192.178.190.1. Dieses hat dafür zu sorgen, daß die Antwortpakete von der SPS durch den 
VPN-Kanal vom Endkunde zum Maschinenhersteller gelangen und der schickt die dann an Dich. Der Rückweg ist also auch klar.

Das Gateway 192.178.190.1 liegt außerhalb Deines verantwortungsbereiches. Ich würde überhaupt nicht einsehen, das ich wegen der Konfiguration 
des Gateways, was ich nicht zu verantworten habe, zum Kunden fahren soll. Oder höchstens gegen gute Bezahlung.



markham schrieb:


> Wenn ich im Net-Pro das ganze so aufbaue wie im Beitrag 15 (http://sps-forum.de/showpost.php?p=209220&postcount=15), würde es dann funktionieren? Dies hätte natürlich den Nachteil, dass ich nochmals zum Kunden fahren muß.


Ich meine, wenn Du es so wie in dem Beitrag machst, dann wird es funktionieren. Vorausgesetzt, das Gateway funktioniert wie erwartet.
Und es hat den Vorteil, daß Du eben nicht zum Kunden fahren mußt, weil Du an der SPS-Konfiguration nichts ändern mußt.
(wenn Du den CP343-1 wie in Deinem Beitrag angegeben konfiguriert hast und die HW-Konfig geladen hast)

Du mußt nur so einen Router-Stellvertreter "Router/Firewall [Fa.xyz]" wie im Beitrag #15 in Deinem Step7-Projekt einfügen, der Deinem Step7 
den Weg zu Deiner SPS zeigt. Der Router-Stellvertreter steht für den ganzen Weg nach der Einwahl beim Maschinenhersteller bis zum Gateway 
vor Deiner SPS beim Endkunden. Wie der Maschinenhersteller diesen Weg realisiert hat ist nicht Dein Problem.

Der eine "innere" CP343-1 des Router-Stellvertreters wird mit Deinem lokalen Projekt-Ethernet verbunden und so konfiguriert:
IP-Adresse: 192.178.190.1 (das Gateway Deiner SPS)
Subnetz: 255.255.255.128
Gateway: kein Routing verwenden

Der andere "äußere" CP343-1 des Router-Stellvertreters wird mit einem zusätzlichen Ethernet(WAN) verbunden und so konfiguriert:
IP-Adresse: 10.19.93.24 (die NAT-IP)
Subnetz: 255.255.0.0 (oder 255.0.0.0, falls Du mal eine andere Einwahl-IP als 10.93.x.x erhältst)
Gateway: kein Routing verwenden

Der CP343-1 Deiner SPS ist mit Deinem lokalen Projekt-Ethernet verbunden und wird so konfiguriert, wie er schon ist:
IP-Adresse: 192.178.190.24
Subnetz: 255.255.255.128
Gateway: 192.178.190.1

Nun noch ein PG/PC im Projekt einfügen und dem Ethernet(WAN) "zuordnen", dann weiß Step7, daß Deine SPS über die NAT-IP erreicht wird und dann 
sollte nach der Einwahl beim Maschinenbauer der Zugriff zu Deiner SPS gelingen.
Das Ethernet(WAN) würde ich noch zu Ethernet(Maschinenhersteller) umbenennen (oder so ähnlich).
Deine SPS wirst Du höchstwahrscheinlich nicht anpingen können, es sei denn, der Maschinenhersteller hat da extra was eingerichtet.



markham schrieb:


> Der Mitarbeiter meinte dann, dass Simatic S7 das nicht unterstützt und eine Einwahl nicht möglich wäre.


Entweder ist der Maschinenbauer dann doch nicht sooo groß, wenn Deine SPS die erste S7-SPS sein soll, die da eingebunden wird und die ganze 
Konfiguration ist völlig überzogen oder der Mitarbeiter hat einfach keine Ahnung von S7. Oder beides.



markham schrieb:


> Gibt es denn noch eine andere Möglichkeit das Ganze hinzubekommen? Ich dachte mir dass vielleicht von Deltalogic die Software Accon S7-Net funktionieren könnte, hab es aber nicht hinbekommen, bzw. wies ich nicht genau was ich einstellen muss.


Ich meine, der Zugriff müßte auch mit dem Tool "ACCON-TeleService IE" von Deltalogic funktionieren.

Gruß
Harald


----------



## markham (7 September 2010)

Guten Morgen Harald,

vielen, vielen Dank. *vde* 
Echt Super und ausführlich erklärt, so daß ich das auch verstehe. Werd es heute gleich mal ausprobieren.

Gruß
Markham

PS: Der Maschinenhersteller ist Weltmarktführer und hat über 10000 Mitarbeiter.


----------



## markham (8 September 2010)

Hallo Harald,

ich habe es gestern noch ausprobiert. Hat auf Anhieb super funktioniert. Danke nochmals. 





> Diese HW-Konfig darf auf keinen Fall in die reale SPS geladen werden!


Das heist doch jetzt aber, dass ich zwei Archive anlegen und speichern muß. Einmal ein Archiv mit Net-Pro im Grundzustand, dass ich benutze wenn ich vor Ort beim Kunden bin und HW-Konfig übertragen darf und eines mit dem Router-Stellvertreter für den Zugang über VPN, oder wie machst du das?

Ich hab es dann auch noch über den Accon-Teleservice IE probiert (ohne Router-Stellvertreter, ohne PG/PC-Station), aber egal was ich einstelle, ich komme damit nicht auf die Steuerung. Oder brauche ich da den Router-Stellvertreter auch?

Gruß
markham


----------



## DELTALOGIC Support (8 September 2010)

Hallo,

folgenden Einträge sollten bei Accon-Teleservice IE funktionieren:

- Direkte Zuordung auswählen
- Projektierte IP: 192.178.190.24
- Zieladresse: 10.19.93.24
- Port: 102

Sollte das nicht klappen, bitte kurz eine Mail an support@deltalogic.de .
Dann bekommen wir es eventuell anders hin.

VG Hanns-Joerg Renschler


----------



## PN/DP (8 September 2010)

markham schrieb:


> Das heist doch jetzt aber, dass ich zwei Archive anlegen und speichern muß. Einmal ein Archiv mit Net-Pro im Grundzustand, dass ich benutze wenn ich vor Ort beim Kunden bin und HW-Konfig übertragen darf und eines mit dem Router-Stellvertreter für den Zugang über VPN, oder wie machst du das?


Hallo markham,
nein, das mußt Du nicht.

Du mußt nur die "Zuordnung" des PG/PC ändern, je nachdem, wo Dein PG angeschlossen ist.
(Doppelklick auf PG/PC, oder Zielsystem > PG/PC zuordnen)
Von fern: PG/PC dem Ethernet(Maschinenhersteller) zuordnen
Vor Ort: PG/PC dem Ethernet(lokal) oder dem MPI(lokal) zuordnen

Du benutzt in Zukunft nur noch das Projekt, wo der Router-Stellvertreter drin ist.
Die HW-Konfig kannst Du jederzeit in Deine SPS übertragen, weil die Konfiguration des 
CP343-1 der SPS ja nicht manipuliert wird. Nur wenn Du - wie von dem Mitarbeiter und 
von Siemens vorgeschlagen - die öffentliche IP bzw. NAT-IP direkt im CP343-1 der SPS 
einträgst darfst Du die HW-Konfig nicht übertragen. 
Deshalb ja auch meine Meinung, daß solche Vorschläge Unfug sind.

Noch ein Hinweis: wenn Du Dich über ein Netzwerk mit der SPS verbindest, dann vor allen 
Eingriffen in die SPS zuerst durch Bausteinvergleich sicherstellen, daß Du mit der 
richtigen SPS verbunden bist.

Harald


----------



## Peter.Hentsch (20 Dezember 2010)

*Fehlermeldung*

Vielen Dank für den cleveren Trick, auch mit Step 7 5.5 scheint er noch Stand der Technik zu sein ;-)

Leider funktioniert es bei mir nicht. 
Step 7 scheint zwar tatsächlich die Stellvertreter-IP anzusprechen, ich bekomme aber die Meldung 13:16662 "Online: Die Verbindung kann nicht zur Zielbaugruppe aufgebaut werden."
Hat jemand einen Lösungsvorschlag?
Inwiefern muss sich denn die "Übertragungsstrecke" wie die Stellvertreter-CPU verhalten?

Zusatzinfos:

Anpingen kann ich meine SPS über die Stellvertreter-IP. Die gesamte Routing-Strecke scheint also zu funktionieren.

Ich teste in einem Versuchsaufbau eine Konfiguration mit zwei mGuard-Routern von innominate. Dabei baut der Router in der Anlage eine VPN-Verbindung zum Lieferanten auf, was die Abstimmung mit der Kunden-IT stark vereinfacht und unterschiedliche (unverträgliche) VPN-Clients auf dem Service-Rechner vermeidet.

Danke im Voraus für Eure Hilfe

Peter


----------



## PN/DP (30 Dezember 2010)

Peter.Hentsch schrieb:


> Ich teste in einem Versuchsaufbau eine Konfiguration mit zwei mGuard-Routern von innominate. Dabei baut der Router in der Anlage eine VPN-Verbindung zum Lieferanten auf


Hallo Peter,

(Du bist der Lieferant?) Die Anlage beim Kunde baut eine VPN-Verbindung zu Deinem Firmen-Netzwerk auf?
Du willst nun über diese VPN-Verbindung auf Deine Anlage zugreifen?
Dann brauchst Du den Router-Stellvertreter höchstwahrscheinlich nicht, da Du ja schon über den VPN-Kanal mit dem Kunde-Anlagen-Netzwerk verbunden bist. Dein Firmen-Router (Dein Standard-Gateway) müsste anhand der Ziel-IP-Adresse dafür sorgen, daß Deine Step7-Verbindung durch den VPN-Kanal geleitet wird.

Den Router-Stellvertreter braucht man nur bei Port-Forwarding im Kunde-Einwahl-Router, bei NAT-Szenarien oder wenn man über Router abweichend vom Standard-Gateway gehen muß.



Peter.Hentsch schrieb:


> Step 7 scheint zwar tatsächlich die Stellvertreter-IP anzusprechen, ich bekomme aber die Meldung 13:16662 "Online: Die Verbindung kann nicht zur Zielbaugruppe aufgebaut werden."


Der echte Router mit Deiner Stellvertreter-IP routet nicht die Step7-Verbindung (Port 102) zur Ziel-SPS oder in der Ziel-SPS ist kein Gateway/Router (für die Rück-Antworten!) eingetragen. In der Ziel-SPS müßte unter "(x) Router verwenden" die IP-Adresse des mGuard-Routers an der Anlage eingetragen sein.



Peter.Hentsch schrieb:


> Anpingen kann ich meine SPS über die Stellvertreter-IP. Die gesamte Routing-Strecke scheint also zu funktionieren.


Bist Du sicher, daß die Ping-Antworten von Deiner SPS kommen und nicht von irgend einem anderen Netzwerkteilnehmer, der die selbe IP-Adresse hat? 
Sind die Ping-Zeiten plausibel hoch (höher als im Firmen-Netzwerk)?
Oder pingst Du die Stellvertreter-IP an? Das ist NICHT Deine SPS! 

Wenn die Ping-Antworten tatsächlich von Deiner SPS kommen, dann bist Du erfolgreich mit dem Ziel-Netzwerk verbunden.
Welchen Weg Dein Ping zur Ziel-SPS tatsächlich genommen hat, kannst Du mit den Windows-Befehlen *tracert* und *pathping* in der Eingabeaufforderung analysieren.

Bei Port-Forwarding kann man die Ziel-IP nicht anpingen, nur die öffentliche IP des Kunde-Einwahl-Routers.

Welche IP-Adresse muß im Router-Stellvertreter eingetragen werden?

bei Port-Forwarding im Kunde-Einwahl-Router: die öffentliche Internet-IP-Adresse des Kunde-Einwahl-Routers
bei NAT: die zugeteilte NAT-IP-Adresse
bei VPN-Verbindung: die IP-Adresse des Gateways/Routers auf der PG-Seite, der in den VPN-Kanal zum Ziel-Netzwerk leitet
(falls hier überhaupt ein Router-Stellvertreter benötigt wird)

Für detailliertere Hinweise müßtest Du mal genauere Angaben zu Deinem Netzaufbau und den verwendeten IP-Adressen machen.

Harald


----------



## PN/DP (10 Juni 2011)

*SIMATIC Manager: Ändern der Zugangsadresse*

Nachtrag zu Fernzugriff projektieren bei Variante D) Port-Forwarding in der Kunden-Firewall
(da wird der Einsatz einer Dummy-SIMATIC-Station als Router-Stellvertreter im Step7-Projekt beschrieben)


PN/DP schrieb:


> die Station steht hier nur als Stellvertreter für den Firmenrouter/Firewall, um Step7 mitzuteilen, daß da ein Router ist und welche IP-Adressen der hat.





PN/DP schrieb:


> Ich habe mir angewöhnt, immer ein PG/PC ins Step7-Projekt einzufügen, wenn es mehrere Netzwerke vom selben Typ im Projekt gibt.
> Dies ist die einzige mir bekannte Möglichkeit, Step7 explizit vorzuschreiben, welchen Weg es zur Ziel-SPS nehmen soll.



Wie ich heute von Bär1971 erfahren habe (Danke!), gibt es doch schon lange (?) eine in Step7 eingebaute Möglichkeit, eine von der HW-Konfig abweichende Zugangsadresse für den Online-Zugang festzulegen, z.B. *um eine S7-Station über die öffentliche IP-Adresse des Kunde-Routers mit Port-Forwarding zu erreichen.* Diese Möglichkeit muß allerdings erst unter *Extras > Einstellungen* freigeschaltet werden (aus gutem Grund! Liebe Unwissende: Bitte nicht nachmachen  )



Zitat aus der Hilfe zum SIMATIC Manager:


> *Register "Ansicht" (Einstellungen)*
> 
> *Ändern der Zugangsadresse zulassen*
> Diese Option sollte immer ausgeschaltet sein (Voreinstellung). Schalten Sie sie nur ein, wenn dies für Ihren Anwendungsfall unbedingt erforderlich ist.
> ...



Da eine einmal so vorgenommene Änderung der Zugangsadresse bis zu einer erneuten Änderung "unsichtbar" bestehen bleibt (!!!), empfehle ich, besser meinen Router-Stellvertreter oder das Tool ACCON-TeleService IE zu benutzen, da es dabei jederzeit ersichtlich ist, daß eine von der HW-Konfig abweichende Zugangsadresse benutzt wird.

*Warnung
Bei unüberlegter Nutzung dieser versteckten Step7-Funktion ist es leicht möglich, versehentlich auf eine andere als die beabsichtigte CPU zuzugreifen, was zu Anlagenschäden bis hin zum Tod von Menschen führen kann!*
Das wird wohl auch der Grund sein, warum Siemens diese Möglichkeit in keinem Fernzugriffs-FAQ erwähnt.

Harald


----------



## Bär1971 (10 Juni 2011)

PN/DP schrieb:


> ...Wie ich heute von Bär1971 erfahren habe (Danke!)...



Ich bedanke mich bei dir für deine schnelle Hilfe obwohl du selbst grad viel um die Ohren hast. 

Vielen Dank nochmal für alles


----------



## xj900mb (6 September 2022)

Hallo,

ich möchte über Variante *D) (festes) Port-Forwarding Port 102 in der Kunden-Firewall *auf eine Maschine beim Kunden zugreifen.
siehe Bild im Anhang.
ich kann die öffentliche IP des Kunden-Routers anpingen und der Port 102 ist auch offen auf seiner und auf meiner Seite.
Allerdings kriegt Step7 die Verbindung nicht hin.
Ich bin über WLAN in meiner Firma mit dem Internet verbunden. muss ich in Step7 beim PG noch was einstellen?
Der Kunde konnte mit einem Netzwerk-Tool schon die S7-300 erreichen und deren Artikel-Nr auslesen.


----------



## DeltaMikeAir (6 September 2022)

Mach halt ein neues Thema auf, der Beitrag hier ist >13 Jahre alt.


----------



## Rainer Hönle (7 September 2022)

Hat die S7 im Projekt die IP-Adresse des Routers eingetragen oder noch die richtige?
Achtung: wenn die IP-Adresse des Routers eingetragen wird, auf keinen Fall die Hardwarekonfig runterladen. Sonst ist die SPS nicht mehr erreichbar.


----------

