Software-Client über VPN nutzen

[Dominic]

Wir benutzen dazu grundsätzlich SplitDNS!
Im lokalen Netz wird auf die interne IP aufgelöst, extern zeigt es auf die öffentliche IP! Noch nie Probleme gehabt, provisionieren von extern kein Problem!

 

[Stroink]

extern zeigt es auf die öffentliche IP!

Ja, aber da ist doch meiner Meinung nach das Problem... Der PC ist nicht im lokalen Netz, er ist extern. Seine primäre Adresse ist die des Heimnetzes. Das er via VPN eine Adresse des Netzes der 3CX-TK hat, dürfte den 3CX-Client nicht interessieren. Denn vermutlich wird ja nur der Verkehr ins Firmennetzwerk über den Tunnel geroutet und der Rest geht normal ins Internet, oder?
Ich habe es neulich bei mir gemerkt, dass ich im Telefonat den Tunnel in die Firma getrennt habe und das hat den 3CX-Client nicht beeindruckt. Würde er den Tunnel genutzt haben, wäre das Gespräch ja abgerissen.

Gruß
Markus

 

[divaitp]

Grundsätzlich kann ich aber sagen, dass die Situation, Softclient ohne VPN von Zuhause (über den 3CX Tunnel Port 5090) bei all unseren Kunden funktioniert! Und ich behaupte mal das 90% der Anlage weltweit wo es so genutzt wird genau die gleiche Situation haben!

und genau das ist auch unsere Erwartung!
Wir gehen auch davon aus, dass irgendwas in der Konfig so eingestellt ist, welches der Server dazu bringt über die interne IP "reden" zu wollen, anstatt über eine erreichbare IP.
Wir können bestimmt morgen eine (geschwärzte) Provisionierungs-Datei hier hochladen, falls es hilft.

 

[divaitp]

Ja, aber da ist doch meiner Meinung nach das Problem... Der PC ist nicht im lokalen Netz, er ist extern. Seine primäre Adresse ist die des Heimnetzes. Das er via VPN eine Adresse des Netzes der 3CX-TK hat, dürfte den 3CX-Client nicht interessieren. Denn vermutlich wird ja nur der Verkehr ins Firmennetzwerk über den Tunnel geroutet und der Rest geht normal ins Internet, oder?

Genau so ist es bei uns...und warum ich eigentlich das VPN als Faktor nicht als relevant sehe. Heimnetz ist Heimnetz, hat den Server nicht zu interessieren. Selbst wenn eine lokale IP vorhanden ist, welche theoretisch bedeuten würde, dass 2 Clients direkt miteinander kommunizieren könnten, ist das irreführend, da die trotzdem in vollkommen getrennten Netzen stehen könnten! (z.B. 192.168.0.1 bei mir zuhause und 192 168.0.1 bei dir zuhause....)

 

[divaitp]

Wie habt Ihr denn den Client provisioniert? Über die Begrüßungsmail? Dann will der Client über den externen Weg laufen und deswegen klappt das auch nicht.

Begrüßungmail, ja. Aber über einen externen Weg, nein. Unser Server ist nur über VPN erreichbar.
....aber wie gesagt......dürfte an sich nicht relevant sein.
Allerdings, sind einige Server URLs in der Provisioning Datei, die zwar DNS-technisch auflösbar sind aber FW-technisch nicht erreichbar sind...kA ob das vielleicht die Ursache des Problems wäre...(?)

 

[patrickbuss]

@divaitp Habt ihr auf dem Windows Client schon einmal versucht nen SBC zum laufen zu bekommen? Der sich via VPN verbindet?

Wenn ja: wie verhält es sich da?

Läuft evt. noch ein Proxy im Netz?
Wird der gesamte Traffic vom Client über den VPN Tunnel geschickt oder nur Teile?
Läuft der DNS auch über den Tunnel? Wenn ja: Leg mal eine neue Zone mit dem ext FQDN der Anlage an und konfiguriere den Client so das er sich "extern" verbinden soll. (Kannste manuell auch über die hosts Datei am Client machen falls kein DNS Server im Netzwerk läuft)

 

[Dominic]

Unser Server ist nur über VPN erreichbar.

Nunja was haben wir denn nun? Einmal VPN, dann wieder nicht VPN, dann wollen wir öffentlich, aber dann ist der Sever nur per VPN erreichbar...

Ich beschreibe mal kurz die Situation ohne VPN.
Am besten habt ihr einen FQDN von 3CX, oder wenn ihr euren eigenen nutzt, muss der öffentlich auflösbar sein und ihr müsst auf eurer Anlage ein gültiges Zertifikat installiert haben.
Portforwarding von eurer öffentlichen IP auf die interne IP der Anlage mit TCP5001 und TCP/UDP5090. Für andere Funktionalitäten sind noch andere Ports erforderlich.
In der Nebenstellenkonfiguration ist unter Telefonprovisionierung, dann als Telefon die 3CX App auswählen weiter untern ein Haken bei "3CX-Tunnel für externe Verbindungen verwenden (nur 3CX-App)"

In der Firewall DPI und IPS für die 3CX deaktivieren.

Aus er Willkommensmail den QR Code mit der SMartphoneapp abscannen und fertig - einfacher geht es eigentlich nicht...

Wenn das nicht geht, habt ihr defintiv nen Bock in der Anlsage/Netzwerk oder Firewall und es sollte sich ein Fachman anschauen!

 

[bitn2]

Ich habe das nur überflogen... Wenn die Privaten Netze extern und intern wirklich die Selbe IP Range haben, kann das auch zu Problemen führen. Ich denke aber so wie sich das anhört ist irgendwas in der Firewall komplett verkonfiguriert. Wir nutzen 3CX und VPN schon sehr lange und es macht eigentlich echt wenig Probleme.

 

[B.Grass]

Moin Zusammen

Das klingt nach Firewall Problemen und die Frage was für eine Firewall hängt drin den ich habe die Erfahrung gemacht das es auch Firewalls gibt da kann man einstellen was man möchte es geht mit der 3cx nicht. am Schluss hat die 3cx eine eigen direkte Leitung bekommen direkt an die Fritzbox oder was auch immer vor der Firewall hängt mit dem passenden routen so das sie in zwei netzten ist.

 

[divaitp]

Moin zusammen,

wir können über FW, Routen reden und Annahmen stellen, wie wir wollen.
Bestimmt "kann" dies damit auch zu tun haben.
Meine Frage/Annahme wurde noch nicht geklärt: warum ändert er die IP im SIP-Body oder ich habe die Nachrichten da nicht recht verstanden.

Was ist hiermit:
https://www.3cx.de/forum/attachments/3cx_2-png.3822/ ?
Und es ist der Client, der die priv_IP sendet.

Beste Grüße
Stefan

 

[maan2304]

Moin zusammen,

bin zwar neu hier, aber ich mische mich auch mal ein:

Wenn das nicht geht, habt ihr defintiv nen Bock in der Anlsage/Netzwerk oder Firewall und es sollte sich ein Fachman anschauen!

Genau so sehe ich das auch, weil:

Selbst wenn eine lokale IP vorhanden ist, welche theoretisch bedeuten würde, dass 2 Clients direkt miteinander kommunizieren könnten, ist das irreführend, da die trotzdem in vollkommen getrennten Netzen stehen könnten! (z.B. 192.168.0.1 bei mir zuhause und 192 168.0.1 bei dir zuhause....)

DAS KANN nicht funktionieren - wenn eine solche Konstellation vorhanden ist, weiß ja weder der Server noch der Client, auf welchen Weg er seine Pakete bringen soll....
@divaitp: in einem der ersten Posts hast Du IP-Adressen gepostet. Könntest Du bitte mal von Server und Client
- (lokale) IP-Adressen, Subnet-Maske, (Standard-)Gateway bzw. Routing-Table posten
- sowie die IP-Adressen aus dem VPN-Netzwerk samt Subnet-Mask

Dann kann man sich zumindest mal ein Bild machen, was Ihr da machen wollt....

LG

Markus

 

[divaitp]

Hallo maan2304,

danke für dein Interesse und Unterstützung.
Hier ein Bild das vll. mehr sagt. Der Client über VPN spricht mit dem 3CX-Server.
Auch im Client selber, sind alle Nebenstellen aufgelistet und ich kann eine Nbst. anrufen.
Sonst müsste der Client mir doch eine Fehlermeldung bringen.
Tut er nicht.

* FW, sehen wir und natürlich nochmals an.

Wenn du mehr brauchst, müssen wir das erst zusammen schreiben.

Beste Grüße
Stefan

 

[maan2304]

Hallo Stefan,

wir sind - glaube ich - fast alle der Meinung, dass hier evt. ein grundsätzliches Problem im Routing vorliegt - deshalb auch meine Bitte, mal die IP-Konfiguration von Server, Client und VPN zu posten. Dann wissen wir zumindest mal, welche Wege die Pakete von Client und Server jeweils laufen sollen und ob das so korrekt ist.
Alles weitere sehen wir dann, wenn wir uns sicher sein können, dass die prinzipiellen Netzwerkeinstellungen funktionieren.

LG

Markus

 

[Tommy]

Auch wenn ich hier gleich Schelte bekomme, möchte ich mich hier einmal reinhängen. Leider ist es wie in so vielen Foren das nicht richtig gelesen wird oder an falscher Stelle gesucht wird, weil nicht sein kann das nicht sein kann.

Es ist doch unbestritten das hier ein Problem des 3CX Clients vorliegt - bzw. das Verhalten einmal hinterfragt werden muss.

Hier gibt es einen ORT A und einen ORT B. Im ORT A steht die 3CX. Das LAN von ORT A hat einen Beliebigen privaten IP Bereich.

ORT B ist das Homeoffice in welchen sich ein PC befindet. Dieser ist mit ORT A über eine VPN verbunden und bekommt aus dem LAN des ORT A eine IP Adresse. Das ist schon einmal eine Konstellation, welcher einigen nicht bewusst ist. Die beliebtesten Firewall/Router/VPN Gateways da draußen verwenden nämlich gern ein Transfer Netz für die VPN Einwahl. Der VPN Client bekommt dann aus dem Transfernetz eine IP Adresse und keine aus dem LAN A.

Wenn nun der Themenstarter sagt, er bekommt aus dem LAN von A eine IP Adresse und kann auch alle Geräte in dem LAN inkl. der 3CX anpingen und erreichen, dann funktioniert schon mal die Übertragung.

Nun ist es aber wohl so, das der 3CX Client an ORT B signalisiert, das er das RTP auf einer anderen IP Adresse empfangen möchte und das ist unlogisch. Der Client an ORT B ist ja für die 3CX unter einer Adresse aus seinem eigenen LAN IP Bereich erreichbar. Bei Routern welche keine Transfernetz nutzen, zeigt die IP Adresse der VPN Verbindung von ORT B in der ARP Tabelle unter der MAC Adresse des VPN Routers sichtbar. Für die 3CX ist der Client nicht extern, sondern intern.

Aus Sicht des Client ist das ganze ja noch simpler: Er hat eine Netzwerkkarte die eine IP Adresse aus dem IP Bereich der 3CX hat. Eine Software sollte dies automatisch erkennen und dann diesen Netzwerkadapter automatisch nutzen! Es ist doch auch uninteressant welche Metrik die Schnittstelle hat - entscheiden ist hier nur, das es eine Schnittstelle gibt die aus dem gleichen Subnet eine IP Adresse hat wie das Ziel.
Ziel: 3CX gleicher IP Bereich wie Quelle: Client durch seine VPN Verbindung.

Der 3CX Client scheint nun aber die Adressen zu vermischen. Er sendet scheinbar die IP Adresse die das Notebook an ORT A von seinem Lokalen Router zugeteilt bekommen hat. Natürlich existiert diese Adresse auf einem Netzwerkadapter auf dem Notebook, aber warum nutzt der 3CX Client diese wo er doch sieht das er die 3CX PBX direkt über einen vorhandenen Adapter erreichen kann.

Wichtig wäre zu wissen was steht im 3CX Client unter "Settings -> Configure Accounts -> Doppelklick auf den Account. Unter "My Location" stehen die IP bzw. DNS Namen der 3CX. Was steht hier unter "in office" und unter "out of office". Stehen hier die LAN IP Adressen der 3cx oder steht dort ein DNS Name. Steht dort ein DNS Name - wird dieser richtig aufgelöst am Client? Ein weiter Punkt ist "Use 3CXTunnel when Out of Office". Dieser sollte in eurem Fall nicht an sein. Wenn nun der Client meint er wäre Out of Office, dann versucht er die 3CX über den Tunnel 5090 zu erreichen was natürlich fehlschlägt, denn:

Ich würde auch erst einmal nicht an ORT A suchen sondern wirklich an ORT B am Notebook, denn dieses Verhalten sieht man im Wireshark nur, wenn der 3CX Client über den eigenen Tunnel zur 3CX Verbindet. Dann sendet er seine eigene LAN IP Adresse.

 

[maan2304]

Warum sollte es Schelte geben? Jeder konstruktive Punkt bringt uns doch weiter - und Unfehlbarkeit beansprucht hier doch hoffentlich niemand für sich
Irgendwo im Thread gab's da so ein paar Angaben, die mich halt vorsichtig gemacht haben: IP-Adressen, die - evt. - im gleichen privaten Bereich sein könnten (172.16.x.x) - was man ohne Subnet-Mask schonmal nicht beurteilen kann - dann der Satz eines Kollegen von Stefan - sinngemäß: auch wenn Server und Client die gleiche lokale IP haben, muss das über VPN gehen... (hab ich zumindest so verstanden)... bevor ich da dann anfange, Wireshark zu nutzen ist es doch bestimmt nicht falsch, erst einmal das Grundsätzliche abzuklopfen. Wenn bei meinem Auto der Motor nicht mehr anspringt, tausche ich ja auch nicht als erstes das Steuergerät....

 

[divaitp]

Hallo Tommy,

1. danke für dein "reinhängen".
2. bekommt ihr keiner "Schelte"

weiter...
Ich hab das mal getan, wie gewollt.
Bild von der Konfig.
Client-Software neu gestartet, leider kein Erfolg.

3cx.unsereDomain wird über den VPN vom DNS-Server (intern) aufgelöst
Client: Ping wird ausgeführt für 3cx.unsereDomain [172.20.19.1] mit 32 Bytes Daten:
Antwort von 172.20.19.1: Bytes=32 Zeit=50ms TTL=126
Antwort von 172.20.19.1: Bytes=32 Zeit=50ms TTL=126
Hintergund der beiden DNS-Einträge ist, wir wollen den ganzen Traffic intern haben, keinen öffentl. Zugang,

Noch weitere Ideen?
Nachtrag, ich brauche auch kein internes Telefon anrufen, es geht auch nicht die ECHO-Funktion "*888", was bestimmt das gleiche Problem ist.

Beste Grüße
Stefan

"sinngemäß: auch wenn Server und Client die gleiche lokale IP haben,"
Nein ich meinte im gleichen Netzwerk, gleiche IP's gibt es nicht, die mehfrach vergeben sind."das wäre ja total irre "

 

[Tommy]

Ich glaube dieser Satz ist aus der Überhitzung heraus entstanden. Ich glaube das war zu kurz gedacht, nachdem Motto: Es gibt doch da einen VPN Adapter über den die 3CX erreichbar ist, da ist doch egal -UND hier kommt dann der Denkfehler: ob das LAN an ORT A die selbe IP Adressen hat wie mein LAN an ORT B. Denn was hier nicht beachtet wurde: Auch wenn er VPN Client grundsätzlich in der Lage ist an die Öffentliche IP Adresse des Routers zu verbinden, entstehen dann im Notebook zwei Netzwerkadapter mit der Adressen aus dem gleichen IP Bereich und Windows wird dann Problem bekommen.

Ich hatte noch eine andere Idee die wieder mit dem Tunnel der 3CX zutun hat. Die IP Adresse die da Notebook bekommt ist zwar eine aus dem LAN von Ort A aber bestimmt mit einem kleineren Subnetz. Kommt hier eventuell der 3CX Client durcheinander und meint er müsse einen Tunnel zur 3CX aufbauen. Interessanterweise habe ich dieses Verhalten bei mir NICHT. Getestet: NCP VPN Client und Shrew Soft Client. Bei beiden verbindet sich der 3CX Client sauber über den VPN Adapter mit der 3CX... Ich dachte ich denke mal laut

 

[divaitp]

3cx-server:
IPv4-Adresse . . . . . . . . . . : 172.20.19.1
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 172.20.19.254
DNS-Server . . . . . . . . . . . : 172.20.19.254

172.20.19.254 = VLAN-Interface am securityGateway

Client LAN-Interface:
IPv4-Adresse . . . . . . . . . . : 10.1.9.10
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 10.1.9.1
DNS-Server . . . . . . . . . . . : 10.1.9.111

Client VPN-Interface:
IPv4-Adresse . . . . . . . . . . : 172.20.244.24(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.255
Standardgateway . . . . . . . . . :
DNS-Server . . . . . . . . . . . : 172.20.0.1

172.20.0.1 = DC im FirmenNetz
alle DNS-Einträge werden aufgelöst, vom Client bei VPN-Verbindung


Client statische Routen, per Windows-IKEv2
Route print:
0.0.0.0 0.0.0.0 10.1.9.1 10.1.9.10 25
10.0.0.0 255.0.0.0 Auf Verbindung 172.20.244.24 26
172.16.0.0 255.240.0.0 Auf Verbindung 172.20.244.24 26
und weitere....

hier sieht man, dass 172.20.19.1 da mit enthalten ist
172.16.0.0/12 = 172.16.0.1 - 172.31.255.254

Ich hoffe es hilft weiter

Beste Grüße
Stefan

 

[Tommy]

Hallo Tommy,

1. danke für dein "reinhängen".
2. bekommt ihr keiner "Schelte"

weiter...
Ich hab das mal getan, wie gewollt.
Bild von der Konfig.
Client-Software neu gestartet, leider kein Erfolg.

3cx.unsereDomain wird über den VPN vom DNS-Server (intern) aufgelöst
Client: Ping wird ausgeführt für 3cx.unsereDomain [172.20.19.1] mit 32 Bytes Daten:
Antwort von 172.20.19.1: Bytes=32 Zeit=50ms TTL=126
Antwort von 172.20.19.1: Bytes=32 Zeit=50ms TTL=126
Hintergund der beiden DNS-Einträge ist, wir wollen den ganzen Traffic intern haben, keinen öffentl. Zugang,

Noch weitere Ideen?
Nachtrag, ich brauche auch kein internes Telefon anrufen, es geht auch nicht die ECHO-Funktion "*888", was bestimmt das gleiche Problem ist.

Beste Grüße
Stefan

"sinngemäß: auch wenn Server und Client die gleiche lokale IP haben,"
Nein ich meinte im gleichen Netzwerk, gleiche IP's gibt es nicht, die mehfrach vergeben sind."das wäre ja total irre

Tja interessant. Was passiert denn wenn du im 3CX Client das Sympol mit den drei Figuren anklickst. Dann zieht der Client die Adresse der 3CX und versucht ein WebMeeting aufzubauen. Ich bin immer noch der Meinung das er irgendwie etwas mit "out of office" durcheinander bringt, was aber deiner Aussage komplett wiederspricht. Du schreibst ja das die DNS Auflösung die IP der 3CX zurückgibt. Also Windows weiß wie es zur 3CX geht und der 3CX Cleint ja scheinbar (bedingt) auch, denn sonst würdest du die Meldung bekommen das er keine Verbindung zur PBX bekommt....

 

[Tommy]

3cx-server:
IPv4-Adresse . . . . . . . . . . : 172.20.19.1
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 172.20.19.254
DNS-Server . . . . . . . . . . . : 172.20.19.254

172.20.19.254 = VLAN-Interface am securityGateway

Client LAN-Interface:
IPv4-Adresse . . . . . . . . . . : 10.1.9.10
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 10.1.9.1
DNS-Server . . . . . . . . . . . : 10.1.9.111

Client VPN-Interface:
IPv4-Adresse . . . . . . . . . . : 172.20.244.24(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.255
Standardgateway . . . . . . . . . :
DNS-Server . . . . . . . . . . . : 172.20.0.1

172.20.0.1 = DC im FirmenNetz
alle DNS-Einträge werden aufgelöst, vom Client bei VPN-Verbindung


Client statische Routen, per Windows-IKEv2
Route print:
0.0.0.0 0.0.0.0 10.1.9.1 10.1.9.10 25
10.0.0.0 255.0.0.0 Auf Verbindung 172.20.244.24 26
172.16.0.0 255.240.0.0 Auf Verbindung 172.20.244.24 26
und weitere....

hier sieht man, dass 172.20.19.1 da mit enthalten ist
172.16.0.0/12 = 172.16.0.1 - 172.31.255.254

Schreibfehler beim Subnetz der 3CX?