OpenVPN : Ipfire als Client mit red/green/blue/orange mit Portunity fester IP

Wie kann man das Konfigurieren?
User avatar
Elluminatus
Posts: 32
Joined: July 2nd, 2016, 6:36 am

Re: OpenVPN : Ipfire als Client mit red/green/blue/orange mit Portunity fester IP

Post by Elluminatus » August 12th, 2017, 8:53 pm

Hier die ifconfig:
blue0 Link encap:Ethernet HWaddr 00:E0:4C:62:FA:3A
inet addr:10.0.1.10 Bcast:10.0.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:891280 errors:0 dropped:10312 overruns:0 frame:0
TX packets:1390850 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:143448232 (136.8 Mb) TX bytes:1629662132 (1554.1 Mb)
Interrupt:18 Memory:dfc00000-dfc20000

green0 Link encap:Ethernet HWaddr 00:E0:4C:62:FA:39
inet addr:10.0.0.10 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7008668 errors:0 dropped:0 overruns:0 frame:0
TX packets:15202478 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:507714474 (484.1 Mb) TX bytes:22873008986 (21813.4 Mb)
Interrupt:17 Memory:dfd00000-dfd20000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1826 errors:0 dropped:0 overruns:0 frame:0
TX packets:1826 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:399571 (390.2 Kb) TX bytes:399571 (390.2 Kb)

orange0 Link encap:Ethernet HWaddr 00:E0:4C:62:FA:3B
inet addr:10.0.2.10 Bcast:10.0.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5854 errors:0 dropped:0 overruns:0 frame:0
TX packets:4333 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6866308 (6.5 Mb) TX bytes:355449 (347.1 Kb)
Interrupt:19 Memory:dfb00000-dfb20000

red0 Link encap:Ethernet HWaddr 00:E0:4C:62:FA:38
inet addr:10.0.10.20 Bcast:10.0.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:16698240 errors:0 dropped:0 overruns:0 frame:0
TX packets:7984435 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24488889130 (23354.4 Mb) TX bytes:645704912 (615.7 Mb)
Interrupt:16 Memory:dfe00000-dfe20000

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:46.41.x.y P-t-P:46.41.x.y Mask:255.255.252.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1440 Metric:1
RX packets:164601 errors:0 dropped:0 overruns:0 frame:0
TX packets:281 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:9376658 (8.9 Mb) TX bytes:30571 (29.8 Kb)
Und ja bei tun0 sind inet addr und P-t-P identisch.

Rest folgt

Gruß Elluminatus
Image

User avatar
Elluminatus
Posts: 32
Joined: July 2nd, 2016, 6:36 am

Re: OpenVPN : Ipfire als Client mit red/green/blue/orange mit Portunity fester IP

Post by Elluminatus » August 12th, 2017, 8:57 pm

Hier noch aus dem Log die Openvpn:
OpenVPN

Verify
status: OK depth: 0, C=DE, ST=NRW, L=Wuppertal, O=Portunity GmbH, CN=server DN: emailAddress=hostmaster@portuniy.de: 84 Time(s)
status: OK depth: 1, C=DE, ST=NRW, L=Wuppertal, O=Portunity GmbH, CN=Portunity GmbH CA DN: emailAddress=hostmaster@portuniy.de: 84 Time(s)

Connections:
Configuration server:
188.246.0.52 connected 1 Time(s), Ports: 1194

**Unmatched Entries**
Linux ip addr del failed: external program exited with error status: 2: 17 Time(s)
OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options: 18 Time(s)
OpenVPN ROUTE: failed to parse/resolve route for host/network: fe80::8: 18 Time(s)
ROUTE6: default_gateway=UNDEF: 18 Time(s)
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).: 168 Time(s)
WARNING: file '/var/ipfire/ovpn/n2nconf/portunity/cert/ta.key' is group or others accessible: 18 Time(s)
WARNING: file '/var/ipfire/ovpn/n2nconf/portunity/portunity.login' is group or others accessible: 18 Time(s)
WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1440): 80 Time(s)
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this: 18 Time(s)
do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0: 18 Time(s)
library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.09: 18 Time(s)
write UDPv4: Network is unreachable (code=101): 1 Time(s)
IP6 habe ich nicht installiert und konfiguriert!

Brauchst Du noch etwas?
Und noch eine Frage, wo finde ich eigentlich die Datei interfaces bei ipfire? Unter etc/network/interfaces finde ich sie nicht...

Gruß Elluminatus

Nachtrag habe hier noch etwas gefunden:

https://www.portunity.de/access/wiki/VP ... 9.C2.A0.3F
Das Gateway lautet 188.246.4.1
Image

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN : Ipfire als Client mit red/green/blue/orange mit Portunity fester IP

Post by ummeegge » August 13th, 2017, 8:01 am

Moin Elluminatus,
OK trotz das heut Sonntag ist und es scheint als ob es gutes Wetter gibt ;) mal kurz step-by-step.
Elluminatus wrote:
August 12th, 2017, 8:53 pm
Und ja bei tun0 sind inet addr und P-t-P identisch.
Sollte nicht so sein. OpenVPN regelt das mittels "--ifconfig l rn" wobei 'l' dein VPN Endpunkt ist und 'rn' die remote IP --> https://openvpn.net/index.php/open-sour ... npage.html . Denke mal die Verbindung steht nicht.
Elluminatus wrote:
August 12th, 2017, 8:57 pm
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).: 168 Time(s)
Ich versteh ja irgendwie nicht warum die OpenVPN Provider sogerne Blowfish nehmen (billiger?), das ist ein 64 Bit Block Cipher welcher wenn der Server <= Version 2.3.12 ist durch SWEET32 angreifbar ist.
Das Problem ist alt aber durchführbare Attacken sind mittlerweile bekannt und ausführbar. AES|CAMELLIA|SEED (128 Bit BLock Cipher) bieten auch 128 bit Schlüssel an also ist der Kostenfaktor da eher nicht der Fall ??? Wenn deine Verbindung nach 64 MB Traffic keine rekeying macht (soft reset) und den Schlüssel austauscht, ist deine Verbindung Exploitable. Wenn der Server >= 2.3.13 ist dann hast du alle 64 MB einen Connection interrupt wegen dem soft reset was auch nicht so schön ist aber besser wie der andere Fall. Das alte reneg-sec 3600 (Schlüsselaustausch jede Stunde) wäre im günstigeren Fall hinfällig, im schlechteren Fall ist die Verschlüsselung kaputt.
Elluminatus wrote:
August 12th, 2017, 8:57 pm
WARNING: file '/var/ipfire/ovpn/n2nconf/portunity/cert/ta.key' is group or others accessible: 18 Time(s)
WARNING: file '/var/ipfire/ovpn/n2nconf/portunity/portunity.login' is group or others accessible: 18 Time(s)
Sollte eigentlich klar sein ? Würde die Rechte entsprechend einschränken...
Elluminatus wrote:
August 12th, 2017, 8:57 pm
WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1440): 80 Time(s)
Ist eine alte Sache --> https://openvpn.net/archive/openvpn-use ... 00037.html sollte aber eine Verbindung trotzdem zulassen obwohl das auch mit einem 'mssfix 0' zu verhindern sein sollte.
Elluminatus wrote:
August 12th, 2017, 8:57 pm
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this: 18 Time(s)
Würd ich wahrscheinlich so lassen weill das rekeying ansonsten eine User Interaktion verlangt.
Elluminatus wrote:
August 12th, 2017, 8:57 pm
write UDPv4: Network is unreachable (code=101): 1 Time(s)
Sieht so aus als ob der Server den Client nicht erreichen kann siehe auch --> https://forums.openvpn.net/viewtopic.php?t=8804#p15504 . Hast du für dein manuell angelegtes tun auch FW Regeln gesetzt ?
Der INPUT/OUTPUT zum Client muss gewährleistet sein ansonsten klappt das nicht mit dem Verbindungsaufbau.
Beim Fire würde bei regulären Verbindung ein Häkchen bei z.b. "OpenVPN auf Rot" das bewirken z.b.

Code: Select all

iptables -nL OVPNINPUT
. Das hier z.b. --> https://arashmilani.com/post?id=53 verdeutlich das ein wenig.
Elluminatus wrote:
August 12th, 2017, 8:57 pm
Und noch eine Frage, wo finde ich eigentlich die Datei interfaces bei ipfire? Unter etc/network/interfaces finde ich sie nicht...
Schau mal unter /var/ipfire/ethernet vielleicht ist es das was du suchst...
Elluminatus wrote:
August 12th, 2017, 8:57 pm
Das Gateway lautet 188.246.4.1
Müsste sich ja dann in deinem config file wiederfinden ?

Schau vielleicht erstmal das die Verbindung steht und ein "SENT CONTROL... " bzw. ein "Initialization Sequence Completed" im Log zu finden ist. Dann würd ich mal wegen dem Internen Routing nach orange0 bzw. Pydio schauen und dann das Firewalling über die FORWARD (CUSTOM Chains in firewall.local z.b.) regeln.

Ein paar Sachen zu Anfang.

Grüssle,

UE
Image
Image
Image

User avatar
Elluminatus
Posts: 32
Joined: July 2nd, 2016, 6:36 am

Re: OpenVPN : Ipfire als Client mit red/green/blue/orange mit Portunity fester IP

Post by Elluminatus » August 16th, 2017, 4:31 pm

Hi Ummeegge,

puh, das war jetzt ein wenig Arbeit mich da reinzufuchsen. Und ja am Sonntag war ich auch den ganzen Tag angehalten meiner besseren Hälfe im Garten zu helfen :)

Folgender Zwischenbericht:

1. Das Log sieht jetzt so aus:

Code: Select all

Aug 16 17:55:53 Hephaistos openvpn[2299]: OpenVPN 2.3.16 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 10 2017
Aug 16 17:55:53 Hephaistos openvpn[2299]: library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.09
Aug 16 17:55:53 Hephaistos openvpn[2299]: WARNING: file '/var/ipfire/ovpn/n2nconf/portunity/portunity.login' is group or others accessible
Aug 16 17:55:53 Hephaistos openvpn[2300]: WARNING: file '/var/ipfire/ovpn/n2nconf/portunity/cert/ta.key' is group or others accessible
Aug 16 17:55:53 Hephaistos openvpn[2300]: Control Channel Authentication: using '/var/ipfire/ovpn/n2nconf/portunity/cert/ta.key' as a OpenVPN static key file
Aug 16 17:55:53 Hephaistos openvpn[2300]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 16 17:55:53 Hephaistos openvpn[2300]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 16 17:55:53 Hephaistos openvpn[2300]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1440)
Aug 16 17:55:53 Hephaistos openvpn[2300]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Aug 16 17:55:54 Hephaistos openvpn[2300]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Aug 16 17:55:54 Hephaistos openvpn[2300]: UDPv4 link local: [undef]
Aug 16 17:55:54 Hephaistos openvpn[2300]: UDPv4 link remote: [AF_INET]188.246.x.y:1194
Aug 16 17:55:54 Hephaistos openvpn[2300]: TLS: Initial packet from [AF_INET]188.246.x.y:1194, sid=83def499 07719995
Aug 16 17:55:54 Hephaistos openvpn[2300]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Aug 16 17:55:54 Hephaistos openvpn[2300]: VERIFY OK: depth=1, C=DE, ST=NRW, L=Wuppertal, O=Portunity GmbH, CN=Portunity GmbH CA, emailAddress=hostmaster@portuniy.de
Aug 16 17:55:54 Hephaistos openvpn[2300]: VERIFY OK: nsCertType=SERVER
Aug 16 17:55:54 Hephaistos openvpn[2300]: VERIFY OK: depth=0, C=DE, ST=NRW, L=Wuppertal, O=Portunity GmbH, CN=server, emailAddress=hostmaster@portuniy.de
Aug 16 17:55:54 Hephaistos openvpn[2300]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 16 17:55:54 Hephaistos openvpn[2300]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Aug 16 17:55:54 Hephaistos openvpn[2300]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 16 17:55:54 Hephaistos openvpn[2300]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 16 17:55:54 Hephaistos openvpn[2300]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Aug 16 17:55:54 Hephaistos openvpn[2300]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 16 17:55:54 Hephaistos openvpn[2300]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug 16 17:55:54 Hephaistos openvpn[2300]: [server] Peer Connection Initiated with [AF_INET]188.246.x.y:1194
Aug 16 17:55:56 Hephaistos openvpn[2300]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Aug 16 17:55:57 Hephaistos openvpn[2300]: PUSH: Received control message: 'PUSH_REPLY,ping 10,ping-restart 60,route-ipv6 fe80::8,tun-ipv6,route-gateway 46.41.0.1,topology subnet,ifconfig 46.41.x.y 255.255.252.0'
Aug 16 17:55:57 Hephaistos openvpn[2300]: OPTIONS IMPORT: timers and/or timeouts modified
Aug 16 17:55:57 Hephaistos openvpn[2300]: OPTIONS IMPORT: --ifconfig/up options modified
Aug 16 17:55:57 Hephaistos openvpn[2300]: OPTIONS IMPORT: route options modified
Aug 16 17:55:57 Hephaistos openvpn[2300]: OPTIONS IMPORT: route-related options modified
Aug 16 17:55:57 Hephaistos openvpn[2300]: ROUTE6: default_gateway=UNDEF
Aug 16 17:55:57 Hephaistos openvpn[2300]: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Aug 16 17:55:57 Hephaistos openvpn[2300]: OpenVPN ROUTE: failed to parse/resolve route for host/network: fe80::8
Aug 16 17:55:57 Hephaistos openvpn[2300]: TUN/TAP device tun0 opened
Aug 16 17:55:57 Hephaistos openvpn[2300]: TUN/TAP TX queue length set to 100
Aug 16 17:55:57 Hephaistos openvpn[2300]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Aug 16 17:55:57 Hephaistos openvpn[2300]: /sbin/ip link set dev tun0 up mtu 1440
Aug 16 17:55:57 Hephaistos openvpn[2300]: /sbin/ip addr add dev tun0 46.41.x.y/22 broadcast 46.41.3.255
Aug 16 17:55:57 Hephaistos openvpn[2300]: GID set to nobody
Aug 16 17:55:57 Hephaistos openvpn[2300]: UID set to nobody
Aug 16 17:55:57 Hephaistos openvpn[2300]: Initialization Sequence Completed
Ein Ping vom IPfire auf 46.41.x.y funktioniert.
Ein Ping aus Blau auf 46.41.x.y funktioniert.

Aus dem WAN heraus funktioniert es noch nicht, ist ja auch klar mit den IPtabeles habe ich mich jetzt nämlich noch nicht beschäftigt.

Allerdings sagt ifconfig weiterhin:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:46.41.x.y P-t-P:46.41.x.y Mask:255.255.252.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1440 Metric:1
RX packets:4427 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:329458 (321.7 Kb) TX bytes:0 (0.0 b)
iptables -nL OVPNINPUT liefert:
Chain OVPNINPUT (1 references)
target prot opt source destination
Hier noch die conf datei:

Code: Select all

client
dev tun
proto udp
tun-mtu 1440
fragment 1400
mssfix

# Ersetzen Sie in der Folgenden zeile bitte <OpenVPN-Server> durch den im Produkt hinterlegten OpenVPN-Server ein
remote openvpn2-tp2.ffm.portunity.de 1194

auth-retry interact
resolv-retry infinite
nobind
persist-key
persist-tun
ca /var/ipfire/ovpn/n2nconf/portunity/cert/ca.crt 
tls-auth /var/ipfire/ovpn/n2nconf/portunity/cert/ta.key 1
ns-cert-type server

# Debug Level
verb 3
#tun-ipv6

# Bitte editieren Sie die Datei "/var/ipfire/ovpn/n2nconf/openvpn/portunity.login" an und passen 
# Ihre Benutzernamen und Ihre Passwort an
# Bitte beachten Sie das nicht in allen OpenVPN Paketen die Möglichkeit einkompiliert ist
# die Zugangsdaten aus einer separaten Datei zu lesen dann kommentieren Sie die folgenden 
# Zeilen bitte um

## Zugangsdaten abfragen und nicht aus einer Datei lesen
# auth-user-pass

## Zugangsdaten aus einer Datei lesen
auth-user-pass /var/ipfire/ovpn/n2nconf/portunity/portunity.login


# Den Tunnel als Default Gateway nutzen! Wenn Sie dies nicht möchten 
# dann kommentieren oder löschen Sie folgende Zeile!
# Eine Alternative dazu ist unter Linux PBR Policy Based Routing. 
# Zu finden in unserem WIKI unter folgendem Link:
# http://www.portunity.de/access/wiki/PBR_%28Policy_Based_Routing%29
# redirect-gateway

# Den Tunnel nach dem aufbau alle Rechte entziehen (Nicht bei Windows möglich)
# Bitte beachten Sie das es die Gruppe "nogroup" auf anderen Distributionen
# auch "nobody" heisen kann. Dann bitte einfach die Kommentare ändern!
user nobody
group nobody
#group nogroup

Es bleibt also noch die Fragen ob

1. es soweit gut und bedeutet jetzt "Initialization Sequence Completed" und der erfolgreiche Ping intern, dass trotz ifconfig Ausgabe der Tunnel steht?
2. es mit den beiden IP´s in der ifconfig zu problemen kommt...?
3. es Sinn macht "openvpn auf red" mal zu aktivieren oder zerhaut mir dies, die ganze konfiguration wieder - Den openvpn server hab ich ja nicht laufen
4. Welche "interne-virtuelle" IP hat jetzt mein Netzwerk?
5. Welche Firewallregeln müssten jetzt hinzugefügt werden, vllt am Anfang einfach mal testweise eine, die einfach alle Ports zu meinem Pydio Server in Ornage erlaubt (10.0.2.20)

Es wird Zeit, dass ich Dir mal ein paar Bier ausgebe! ;)

Beste Grüße
Elluminatus

Nachtrag eine Anfrage beim Support von Portunity ergab diese Aussage bzgl der Anzeige von ifconfig bei tun0:
dies scheint ein anzeige Fehler von Ihrem OpenVPN Client zu sein. Ein Ping direkt von der Tunnel Plattform aus funktioniert.. Wichtig ist das Sie die Antwort Pakete von IPs welche Sie von uns durch den Tunnel erhalten auch durch diesen wieder beantworten.
Last edited by Elluminatus on August 18th, 2017, 12:23 pm, edited 1 time in total.
Image

ummeegge
Community Developer
Community Developer
Posts: 4122
Joined: October 9th, 2010, 10:00 am

Re: OpenVPN : Ipfire als Client mit red/green/blue/orange mit Portunity fester IP

Post by ummeegge » August 18th, 2017, 11:26 am

Hallo Elluminatus,
Elluminatus wrote:
August 16th, 2017, 4:31 pm
puh, das war jetzt ein wenig Arbeit mich da reinzufuchsen.
der Lerneffekt war ja auch ein wünschenswerter Aspekt ;) .

Das Verbindungslog sieht wie ich finde gut aus, bis auf die schon oben erwähnten Probleme die ich da sehe (Cipher, HMAC, etc...), sofern du nicht eh schon was geändert hast würde ich die statische IP da noch unkenntlich machen z.b. '123.234.xx.xx'.
Elluminatus wrote:
August 16th, 2017, 4:31 pm
Nachtrag eine Anfrage beim Support von Portunity ergab diese Aussage bzgl der Anzeige von ifconfig bei tun0:

dies scheint ein anzeige Fehler von Ihrem OpenVPN Client zu sein. Ein Ping direkt von der Tunnel Plattform aus funktioniert.. Wichtig ist das Sie die Antwort Pakete von IPs welche Sie von uns durch den Tunnel erhalten auch durch diesen wieder beantworten.
Das mit dem Anzeigefehler tut sich bei mir ein wenig schwer aber nun gut, was der Service ansonsten sagt ist ja auch irgendwie richtig dennoch entsteht die Frage welche IP nun dein Ende des Transportnetzes hat (dazu unten noch ein Gedanke)...
Elluminatus wrote:
August 16th, 2017, 4:31 pm
iptables -nL OVPNINPUT liefert:
Chain OVPNINPUT (1 references)
target prot opt source destination
Das sollte klar sein da du die Verbindung ja nicht über das WUI angelegt hast, Freigabe hierfür müsste dann halt noch nachträglich manuell gemacht werden.
Elluminatus wrote:
August 16th, 2017, 4:31 pm
1. es soweit gut und bedeutet jetzt "Initialization Sequence Completed" und der erfolgreiche Ping intern, dass trotz ifconfig Ausgabe der Tunnel steht?
Sieht so aus ja.
Elluminatus wrote:
August 16th, 2017, 4:31 pm
2. es mit den beiden IP´s in der ifconfig zu problemen kommt...?
Wenn dein Tunnel bis jetzt ohne errors durchgelaufen ist, ist die Wahrscheinlichkeit gering würd ich denken.
Elluminatus wrote:
August 16th, 2017, 4:31 pm
3. es Sinn macht "openvpn auf red" mal zu aktivieren oder zerhaut mir dies, die ganze konfiguration wieder - Den openvpn server hab ich ja nicht laufen
das würde so erstmal nicht so viel Sinn machen denke ich da das WUI probieren würde den INPUT auf den dort konfigurierten Port (sofern gleich bzw. default) der ja schon durch deine Portunity Verbindung belegt ist aufzumachen, ich denke das dass intern zu einem error führt. Die Regeln über das WUI würden z.b. so aussehen

Code: Select all

Chain OVPNINPUT (1 references)
target     prot opt source               destination         
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:1194
was du dann manuell mit den entsprechenden Vorraussetzungen (Port, Protokoll, etc.) Regeln müsstest, ich würde auch schauen das du die Regeln dann komplett über ein Regelwerk definierst und nicht ein Teil da und einen anderen Teil dort nmachen musst, so bleibt das kompakter und übersichtlicher.
Ich würde hierfür obige Links nochmal checken (firewall.local, Beispiel Regeln etc.). Du findest hier --> http://git.ipfire.org/?p=ipfire-2.x.git ... dc;hb=HEAD auch das IPFire Firewall Skript was auch das OpenVPN für den Fire regelt mal als Beispiel.
Elluminatus wrote:
August 16th, 2017, 4:31 pm
4. Welche "interne-virtuelle" IP hat jetzt mein Netzwerk?
Nach deinem Log arbeitet dein Server mit --topology subnet (kein net30), regulär sollte dein Endpunkt die nächst höhere IP im letzten Oktett als der Server sein.
Elluminatus wrote:
August 16th, 2017, 4:31 pm
5. Welche Firewallregeln müssten jetzt hinzugefügt werden, vllt am Anfang einfach mal testweise eine, die einfach alle Ports zu meinem Pydio Server in Ornage erlaubt (10.0.2.20)
Das Routing würde dann auch nochmal eine Rolle spielen. Vom Server aus würde sich das ganz gut über den Userspace vom OpenVPN regeln lassen (Stichwort iroute bzw. CCD) da du aber keinen Zugriff auf den Server hast braucht´s wahrscheinlich ein SNAT bzw. MASQUERADE. Ganz gute Infos zu diesem Thema findest du u.a. z.b. hier --> http://backreference.org/2009/11/15/openvpn-and-iroute/ bzw. --> https://serverfault.com/questions/57016 ... d-iptables .
Elluminatus wrote:
August 16th, 2017, 4:31 pm
Es wird Zeit, dass ich Dir mal ein paar Bier ausgebe! ;)
Hört sich gut an :P ist auch nett von dir und wer weiss vielleicht wird das ja auch mal was ;) . Erst mal schauen ob alles klappt und du ein paar Schritte weiter kommst.

Grüsse,

UE
Image
Image
Image

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests