[Problem] Clients im Netzwerk der FB7390 nicht erreichbar aus Netzwerk des Kabel-Routers

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
c.monty schrieb:
Das mag sein, die Einstellungen in der FB7390 aus der WebUI lassen hier keine klare Aussage zu (siehe Screenshot im Anhang).
Zum Vergrößern anklicken....
Es ist als Router am Kabelmodem eingerichtet. Zudem scheint mir die Größe des Upstream etwas übertrieben. ;)
 
sf3978 schrieb:
Da Du auf beiden 7170-Boxen Freetz hast, wäre eine Möglichkeit, ein Tunnel (ohne oder mit minimaler Verschlüsselung) zwischen diesen Boxen. Die FB7170_1 (192.168.0.11) sollte der Server sein, und auf der FB7170_2 (192.168.178.10) der Client.
Zum Vergrößern anklicken....

Gibt es einen techn. Grund dafür, dass FB7170_1 als Server konfiguriert sein sollte?
Oder kann FB7170_1 auch Client und FB7170_2 Server mit VTun sein?

THX
 
Gut, ich beabsichtige die folgende Konfiguration zu verwenden.

FB7170_1 (=Server):
Code: 
default {
  type tun;
  proto udp;
  #comp lzo:1;
  keepalive yes;
}

# Tunnel zwischen FB7170_1 and FB7170_2 (192.168.0.11 <-> 192.168.100.10)
# Server entry
FB7170_2 {
  passwd tunnel;
  up {
    ifconfig "%% 192.168.0.1 pointopoint 192.168.0.11";
    route "add -net 192.168.100.10 gw 192.168.0.11";
    program /sbin/arp "-sD 192.168.0.11 eth0 pub";
  };
}

Aufrufparameter in der GUI:
-s 192.168.0.11

Ich kann den Service aus der GUI starten und sehe in der Konsole (mit ps):
Code: 
3176 root       616 S    vtund[s]: waiting for connections on port 5000

FB7170_2 (=Client):
Code: 
# Tunnel zwischen FB7170_2 und FB7170_1 (192.168.100.10 <-> 192.168.0.11)
# Konfiguration Client
FB7170_2 {
  passwd tunnel;
  up {
    ifconfig "%% 192.168.0.11 pointopoint 192.168.0.1";
    route "add -net 192.168.0.0 gw 192.168.0.1";
  };
}

Aufrufparameter in der GUI:
FB7170_2 192.168.0.11

Ich kann den Service aus der GUI starten und sehe in der Konsole (mit ps):
Code: 
3629 root       620 S <  vtund[c]: FB7170_2 tun tun0

In der hosts Datei steht in beiden FB7170:
Code: 
192.168.100.1 * * FB7390
192.168.100.10 * * FB7170_2
192.168.0.11 * * FB7170_1

In der Ausgabe von ifconfig sehe ich auf der FB7170_1 (=Server) das neue TUN Interface:
Code: 
tun0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.0.1  P-t-P:192.168.0.11  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:156 (156.0 B)  TX bytes:156 (156.0 B)

In der Ausgabe von ifconfig sehe ich auf der FB7170_2 (=Client) das neue TUN Interface:
Code: 
tun0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.0.11  P-t-P:192.168.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:156 (156.0 B)

Das Ergebnis der Ping-Anfrage ist aber unverändert negativ, d.h. ich kann von FB7170_1 aus die FB7170_2 nicht erreichen.
Desweiteren ist das TUN Interface auf beiden FB7170 instabil, d.h. es ist nach wenigen Sekunden nicht mehr verfügbar.

Frage:
Welche Auswirkung hat die Aktivierung des Tunnels zwischen FB7170_1 und FB7170_2, wenn das Kabel-Gateway andere Anfragen (aus dem Internet) per Port Forwarding an die FB7170_1 weiterleitet?
Ich frage dies deshalb, weil ich nicht ganz sicher bin, ob die IP-Adresse 192.168.0.11 dann für den Tunnel belegt ist, und das Port-Forwarding zu genau derselben IP-Adresse dann nicht mehr geht?


THX
 
Zuletzt bearbeitet:
c.monty schrieb:
Welche Auswirkung hat die Aktivierung des Tunnels zwischen FB7170_1 und FB7170_2, wenn das Kabel-Gateway andere Anfragen (aus dem Internet) per Port Forwarding an die FB7170_1 weiterleitet?
Ich frage dies deshalb, weil ich nicht ganz sicher bin, ob die IP-Adresse 192.168.0.11 dann für den Tunnel belegt ist, und das Port-Forwarding zu genau derselben IP-Adresse dann nicht mehr geht?
Zum Vergrößern anklicken....
Keine Auswirkungen hat die Aktivierung des Tunnels zwischen FB7170_1 und FB7170_2 , wenn alles richtig konfiguriert ist, was bei dir z. Zt. noch nicht der Fall ist. Das Kabel-Gateway ermöglicht ja die Kommunikation zwischen den 7170-Boxen (... von 192.168.178.10 -> 192.168.0.11). B.: Wähle als Protokoll tcp statt udp (wenn alles ok ist dann kannst Du auch mit udp experimentieren, wenn erwünscht), "encrypt no;", lauschender Port für den Server z. B. 23692, IPs für die tun-Interfaces aus einem Zwischennetz z. B.: 10.5.0.1 (Client) und 10.5.0.2 (Server), richtige Konfiguration der tun-Interfaces bzw. richtiges Routing, (evtl. auch richtiges MASQUERADING), auch ein down der Interfaces wenn nicht mehr benötigt. Nützliche tools sind auch "route -n" und "lsof -nPi" oder "netstat -tlpen".
 
OK.
Ich habe jetzt mal diese Konfiguration zusammengestellt, habe aber Zweifel ob das so funktioniert.
Kannst du da bitte drüber schauen?

Code: 
## Server
## ------------------------------------------------------------------
options {
  port 23692;		# Listen on this port.
  bindaddr { iface lo; };   # Listen only on loopback device.

  # Syslog facility
  syslog 	daemon;

  # Path to various programs
  #ppp 		/usr/sbin/pppd;            
  #ifconfig 	/sbin/ifconfig;
  #route 	/sbin/route;
  #firewall 	/sbin/ipchains;
  #ip		/sbin/ip;
}

lion {
  passwd tunnel;	# Password
  type ether; 		# Ethernet tunnel
  device tap0; 		# Device tap0 
  proto udp;   		# UDP protocol
  #compress  lzo:1;	# LZO compression level 1 
  encrypt  no;		# Encryption
  stat  yes;   		# Log connection statistic 
  keepalive yes;	# Keep connection alive

  up {	
	# Connection is Up 

	# Assign IP address 
	ifconfig "%% 10.1.0.1 netmask 255.255.255.0";
		
	# Add route to net 10.2.0.0/24  
	route "add -net 10.2.0.0 netmask 255.255.255.0 gw 10.1.0.2";

	# Enable masquerading for net 10.2.0.0.0/24 
	firewall "-A forward -s 10.2.0.0/24 -d 0.0.0.0/0 -j MASQ";
  };

  down {
	# Connection is Down

	# Shutdown tap device. 
	ifconfig "%% down"; 

	# Disable masquerading for net 10.2.0.0.0/24 
	firewall "-D forward -s 10.2.0.0/24 -d 0.0.0.0/0 -j MASQ";
  };
}

## Client
## ------------------------------------------------------------------
options {
  port 23692;		# Connect to this port.
  timeout 60;		# General timeout

  # Path to various programs
  #ppp		/usr/sbin/pppd;            
  #ifconfig	/sbin/ifconfig;
  #route		/sbin/route;
  #firewall	/sbin/ipchains;
  #ip		/sbin/ip;
}

lion {
  passwd tunnel;	# Password
  type ether;		# Ethernet tunnel
  device tap1; 		# Device tap1 
  up {
	# Connection is Up 

	# Assign IP address and netmask. 
	ifconfig "%% 10.1.0.2 netmask 255.255.255.0";
  };
  down {
	# Connection is Down 

	# Shutdown tap device
	ifconfig "%% down";
  };
}

THX
 
c.monty schrieb:
Ich habe jetzt mal diese Konfiguration zusammengestellt, habe aber Zweifel ob das so funktioniert.
Zum Vergrößern anklicken....
Hier meine funktionierende und anonymisierte Konfiguration:
Client:
Code: 
#client
options {
  type stand;
  syslog        daemon;
  ifconfig      /sbin/ifconfig;
  route         /sbin/route;
  firewall      /sbin/iptables;
  ip            /bin/ip;
}
default {
  compress no;
  speed 0;
  encrypt no;
}
# tun_client
tun_5 {
  password  <######>;
  type  tun;
  device tun0;
  timeout 60;
  persist yes;
  up {
	ifconfig "%% 10.1.0.2 pointopoint 10.1.0.1";
        route "add -net 192.168.148.0 netmask 255.255.255.0 gw 10.1.0.1";
	firewall "-t nat -A POSTROUTING -o %% -j MASQUERADE";
  };
  down {
	ifconfig "%% down";
       route "del -net 192.168.148.0 netmask 255.255.255.0 gw 10.1.0.1";
	firewall "-t nat -D POSTROUTING -o %% -j MASQUERADE";
   };
}
Server:
Code: 
#server
options {
  port 55555;
  type inetd;
  syslog        daemon;
  ifconfig      /sbin/ifconfig;
  route         /sbin/route;
  firewall      /usr/sbin/iptables;
  ip            /bin/ip;
}
default {
  compress no;
  speed 0;
  multi yes;
}
# tun_server
tun_5 {
  password <######>;
  type tun;
  device tun0;
  proto tcp;
  speed 256:512;
  encrypt no;
  #compress lzo:1;
  keepalive yes;
  up {
        ifconfig "%% 10.1.0.1 pointopoint 10.1.0.2";
        route "add -net 192.168.128.0 netmask 255.255.255.0 gw 10.1.0.2";
        firewall "-t nat -A POSTROUTING -o %% -j MASQUERADE";
  };
   down {
        ifconfig "%% down";
        route "del -net 192.168.128.0 netmask 255.255.255.0 gw 10.1.0.2";
        firewall "-t nat -D POSTROUTING -o %% -j MASQUERADE";
   };
}
 
Welchen Aufrufparameter verwendest du auf dem Client?
tun_5 <IP Adresse im Server-Netzwerk>

Ist 192.168.148.0 das Netzwerk des Servers oder des Clients?
 
Zuletzt bearbeitet:
Ich habe deine funktionierende Konfiguration an mein Netzwerk angepasst.

Server:
Diese Konfiguration startet fehlerfrei:
Code: 
## Server
## ------------------------------------------------------------------

options {
  port 5500;
  #type inetd;
  type stand;
  syslog        daemon;
  ifconfig      /sbin/ifconfig;
  route         /sbin/route;
  firewall      /usr/sbin/iptables;
  ip            /bin/ip;
}
default {
  compress no;
  speed 0;
  multi yes;
}
# Server: 192.168.178.0 (Netzwerk Client) != 192.168.0.0 (Netzwerk Server)
tun_1 {
  password <pass>;
  type tun;
  device tun0;
  proto tcp;
  speed 256:512;
  encrypt no;
  #compress lzo:1;
  keepalive yes;
  up {
        ifconfig "%% 10.1.0.1 pointopoint 10.1.0.2";
        route "add -net 192.168.178.0 netmask 255.255.255.0 gw 10.1.0.2";
        firewall "-t nat -A POSTROUTING -o %% -j MASQUERADE";
  };
   down {
        ifconfig "%% down";
        route "del -net 192.168.178.0 netmask 255.255.255.0 gw 10.1.0.2";
        firewall "-t nat -D POSTROUTING -o %% -j MASQUERADE";
   };
}

Mit dem Parameter "type inetd" im Abschnitt "options" started vtun nicht!

Die Ausgabe von "ps":
Code: 
3021 root       616 S    vtund[s]: waiting for connections on port 5500

Die Ausgabe von "ifconfig":
Code: 
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.1.0.1  P-t-P:10.1.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:156 (156.0 B)  TX bytes:240 (240.0 B)

Die Ausgabe von "route -n":
Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
82.212.62.62    192.168.0.1     255.255.255.255 UGH   0      0        0 lan
78.42.43.62     192.168.0.1     255.255.255.255 UGH   0      0        0 lan
192.168.178.0   10.1.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         192.168.0.1     0.0.0.0         UG    9      0        0 lan

Ausgabe von lsof -nPi:
Code: 
vtund    1608 root    3u  inet   8617       TCP 192.168.178.11:2068->192.168.0.12:5500 (ESTABLISHED)

Client:
Diese Konfiguration startet fehlerfrei:
Code: 
## Client
## ------------------------------------------------------------------

options {
  port 5555;
  type stand;
  syslog        daemon;
  ifconfig      /sbin/ifconfig;
  route         /sbin/route;
  firewall      /sbin/iptables;
  ip            /bin/ip;
}
default {
  compress no;
  speed 0;
  encrypt no;
}
# Client: 192.168.0.0 (Netzwerk Server) != 192.168.178.0 (Netzwerk Client)
tun_1 {
  password  <pass>;
  type  tun;
  device tun0;
  timeout 60;
  persist yes;
  up {
	ifconfig "%% 10.1.0.2 pointopoint 10.1.0.1";
        route "add -net 192.168.0.0 netmask 255.255.255.0 gw 10.1.0.1";
	firewall "-t nat -A POSTROUTING -o %% -j MASQUERADE";
  };
  down {
	ifconfig "%% down";
       route "del -net 192.168.0.0 netmask 255.255.255.0 gw 10.1.0.1";
	firewall "-t nat -D POSTROUTING -o %% -j MASQUERADE";
   };
}

Die Ausgabe von "ps":
Code: 
1608 root       612 S <  vtund[c]: tun_keys tun tun0

Die Ausgabe von "ifconfig":
Code: 
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.1.0.2  P-t-P:10.1.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:156 (156.0 B)  TX bytes:204 (204.0 B)

Die Ausgabe von "route -n":
Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.0.0     10.1.0.1        255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         192.168.178.1   0.0.0.0         UG    9      0        0 lan

Ausgabe von lsof -nPi:
Code: 
vtund    3021 root    3u  inet   5755       TCP *:5555 (LISTEN)
vtund    3417 root    4u  inet   6233       TCP 192.168.0.11:5500->192.168.0.10:2068 (ESTABLISHED)

Ich denke das passt soweit... allerdings funktionieren dann folgende Pings nicht:
Server:
192.168.178.x (d.h. zu allen Adressen im Netzwerk "Client")
10.1.0.2

Client:
10.1.0.1

Kann dies bedeuten, dass der Tunnel zwar aufgebaut ist, aber keine Verbindung zustande kommt?
 
Zuletzt bearbeitet:
c.monty schrieb:
Ich habe deine funktionierende Konfiguration an mein Netzwerk angepasst.
Code: 
## Server
options {
  type inetd;
}
Mit dem Parameter "type inetd" im Abschnitt "options" started vtun nicht!
Zum Vergrößern anklicken....
Wenn Du den Server im inetd-Modus benutzen willst, dann musst Du Eintragungen in die inetd.conf machen. Z. B.:
Code: 
root@fritz:/var/mod/root# cat /var/mod/etc/inetd.conf
#:vtund
<Port>   stream  tcp     nowait  root    /usr/bin/vtund  vtund -s -f /<Pfad>/vtund-server.conf -i -P <Port>
# END OF CUSTOM CONFIG
c.monty schrieb:
Ich denke das passt soweit... allerdings funktionieren dann folgende Pings nicht:
Server:
192.168.178.x (d.h. zu allen Adressen im Netzwerk "Client")
10.1.0.2
Client:
10.1.0.1
Kann dies bedeuten, dass der Tunnel zwar aufgebaut ist, aber keine Verbindung zustande kommt?
Zum Vergrößern anklicken....
Funktioniert der Ping von 192.168.0.11 nach 192.168.178.10 und von 192.168.178.10 nach 192.168.0.11? Funktionieren "telnet 192.168.178.10" und "telnet 192.168.0.11"? 10.1.0.1 und 10.1.0.2 sind nicht relevant.
Siehe auf beiden Boxen, die Ausgabe von: "lsof -nPi | grep vtun".

EDIT:

Du hast Folgendes gepostet:
Code: 
vtund    1608 root    3u  inet   8617       TCP 192.168.178.11:2068->192.168.0.12:5500 (ESTABLISHED)
Code: 
vtund    3417 root    4u  inet   6233       TCP 192.168.0.11:5500->192.168.0.10:2068 (ESTABLISHED)
Das verstehe ich nicht? Was sind das für IP-Adressen bzw. was sind das für Verbindungen?
 
Zuletzt bearbeitet:
sf3978 schrieb:
Du hast Folgendes gepostet:
Code: 
vtund    1608 root    3u  inet   8617       TCP 192.168.178.11:2068->192.168.0.12:5500 (ESTABLISHED)
Code: 
vtund    3417 root    4u  inet   6233       TCP 192.168.0.11:5500->192.168.0.10:2068 (ESTABLISHED)
Das verstehe ich nicht? Was sind das für IP-Adressen bzw. was sind das für Verbindungen?
Zum Vergrößern anklicken....

Sorry, da hat sich ein Schreibfehler eingeschlichen.
Korrekt muss die Information lauten:
Code: 
vtund    1608 root    3u  inet   8617       TCP 192.168.178.10:2068->192.168.0.11:5500 (ESTABLISHED)
Code: 
vtund    3417 root    4u  inet   6233       TCP 192.168.0.11:5500->192.168.0.10:2068 (ESTABLISHED)

Dies interpretiere ich so, dass auf dem Client (192.168.178.10) eine TCP-Verbindung zum Server (192.168.0.11) aufgebaut ist
TCP 192.168.178.10:2068->192.168.0.12:5500
und auf dem Server (192.168.0.11) eine Verbindung zur FB7390 (192.168.0.10)
TCP 192.168.0.11:5500->192.168.0.10:2068 (ESTABLISHED)
 
Zuletzt bearbeitet:
sf3978 schrieb:
Funktioniert der Ping von 192.168.0.11 nach 192.168.178.10 und von 192.168.178.10 nach 192.168.0.11? Funktionieren "telnet 192.168.178.10" und "telnet 192.168.0.11"? 10.1.0.1 und 10.1.0.2 sind nicht relevant.
Siehe auf beiden Boxen, die Ausgabe von: "lsof -nPi | grep vtun".
Zum Vergrößern anklicken....

Nein, vom Server (192.168.0.11) funktioniert kein Ping in das Netzwerk 192.168.178.0/24, d.h. weder zur FB7390 (192.168.178.1) noch zu irgendeinem anderen Client (192.168.178.x).

Nein, vom Client (192.168.178.10) funktioniert kein Ping in das Netzwerk 192.168.0.0/24, d.h. weder zur FB7390 (192.168.0.10) noch zu irgendeinem anderen Client (192.168.0.x).

Telnet ist deaktiviert auf beiden FB7170, aber ich habe eine ssh-Verbindung aus dem Netzwerk 192.168.178.x (mein PC) zu jeder der beiden FB7170.
 
Das sieht doch jetzt danach aus, als dass der Tunnel aufgebaut ist, aber keine Daten hindurchgeschickt werden können.
Denn ich kann ja aus beiden Netzwerken das jeweils andere Netzgerät nicht mehr erreichen.

Wenn ich den vtun auf dem Client abschalte, dann erreiche ich alle Geräte im Netzwerk 192.168.0.0/24.
 
c.monty schrieb:
Nein, vom Server (192.168.0.11) funktioniert kein Ping in das Netzwerk 192.168.178.0/24, d.h. weder zur FB7390 (192.168.178.1) noch zu irgendeinem anderen Client (192.168.178.x).
Nein, vom Client (192.168.178.10) funktioniert kein Ping in das Netzwerk 192.168.0.0/24, d.h. weder zur FB7390 (192.168.0.10) noch zu irgendeinem anderen Client (192.168.0.x).
Zum Vergrößern anklicken....
Ich habe nicht nach Pings auf Clients im jeweiligen Netzwerk gefragt. Meine Frage war: Funktioniert der Ping von 192.168.0.11 nach 192.168.178.10 und von 192.168.178.10 nach 192.168.0.11?
Kannst Du statt telnet, ssh-Verbindungen von 192.168.0.11 nach 192.168.178.10 und von 192.168.178.10 nach 192.168.0.11 herstellen/aufbauen?

EDIT:

Das Herstellen der ssh-Verbindungen zwischen den 7170-Boxen, soll durch den Tunnel stattfinden.
 
Zuletzt bearbeitet:
Nein! Keine Verbindung zwischen den beiden FB7170.
Der Ping von FB7170_1 (192.168.0.11) nach FB7170_2 (192.168.178.10) kommt nicht zurück, d.h. er bleibt ohne Antwort stehen:
Code: 
root@192:/var/mod/root# ping 192.168.178.10
PING 192.168.178.10 (192.168.178.10): 56 data bytes

Dasselbe gilt für den Ping von FB7170_2 (192.168.178.10) nach FB7170_1 (192.168.0.11); auch dieser bleibt ohne Antwort stehen.
 
c.monty schrieb:
Nein! Keine Verbindung zwischen den beiden FB7170.
Zum Vergrößern anklicken....
Versuch mal statt "encrypt no;", mit "encrypt blowfish256ecb;".
Wenn es nicht geht, dann versuch mal in den conf-Dateien das Routing nicht in das Subnetz, sondern zum Host. Z. B.:
Code: 
route "add -host 192.168.0.11 netmask 255.255.255.255 gw 10.1.0.1";
Code: 
route "add -host 192.168.178.10 netmask 255.255.255.255 gw 10.1.0.2";
 
sf3978 schrieb:
Versuch mal statt "encrypt no;", mit "encrypt blowfish256ecb;".
Wenn es nicht geht, dann versuch mal in den conf-Dateien das Routing nicht in das Subnetz, sondern zum Host. Z. B.:
Code: 
route "add -host 192.168.0.11 netmask 255.255.255.255 gw 10.1.0.1";
Code: 
route "add -host 192.168.178.10 netmask 255.255.255.255 gw 10.1.0.2";
Zum Vergrößern anklicken....

Die Änderung des Parameters "encrypt blowfish256ecb;" hat nichts bewirkt.

Die Änderung von "route ..." hat eine Verbesserung gebracht:
Der Ping von FB7170_2 (192.168.178.10) = Client zu FB7170_1 (192.168.0.11) = Server geht jetzt wieder durch.
Der Ping in die entgegengesetzte Richtung, also von FB7170_1 (192.168.0.11) zu FB7170_2 (192.168.178.10) geht nicht durch.

Damit ist die Situation identisch mit der Ausgangslage: die Kommunikation von 192.168.0.0/24 ins Netzwerk der FB7390 192.168.178.0/24 wird blockiert.
 
c.monty schrieb:
... die Kommunikation von 192.168.0.0/24 ins Netzwerk der FB7390 192.168.178.0/24 wird blockiert.
Zum Vergrößern anklicken....
Poste bitte bei hergestellter Tunnelverbindung, von beiden Boxen, folgende Ausgaben:
Code: 
ps | grep vtun
Code: 
lsof -nPi | grep vtun
Code: 
ifconfig
Code: 
route -n
Code: 
lsof -nPi | grep :5500
Code: 
iptables -L -nvx
Code: 
iptables -nvx -L -t nat
Kannst Du auf der FB7170_1 (192.168.0.11) die virtuelle IP-Adresse aktivieren/konfigurieren?
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 524 (Mitglieder: 11, Gäste: 513)

Neueste Beiträge

Statistik des Forums

Themen
246,201
Beiträge
2,247,954
Mitglieder
373,765
Neuestes Mitglied
walterronald99
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück