Page 2 of 2

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

Posted: August 12th, 2017, 8:53 pm
by Elluminatus
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

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

Posted: August 12th, 2017, 8:57 pm
by Elluminatus
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

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

Posted: August 13th, 2017, 8:01 am
by ummeegge
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

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

Posted: August 16th, 2017, 4:31 pm
by Elluminatus
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.

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

Posted: August 18th, 2017, 11:26 am
by ummeegge
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

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

Posted: August 24th, 2017, 1:53 pm
by Elluminatus
Hallo,

ich komme jetzt nicht mehr weiter.

Ich habe nochmal den Helpdesk angeschrieben um zu fragen, wie ich nun meine festes IP Netz welches ich von Portumity bekommen habe mit diesem tun0 verbinden kann. Folgende Antwort erhielt ich:

zur Übersicht:
46.41.x.y ist meine Tunnel Basis IP
46.41.a.b ist eine Adresse aus meinem Adresspool (geht von 46.41.a.b bis 46.41.a.i)


Um das Netz zu nutzen haben Sie mehrere Möglichkeiten, die ein wenig davon abhängig sind was Sie mit den IP-Adressen aus dem Netz letztlich vorhaben und wie das restliche Netzwerk aufgebaut ist.

Eine Möglichkeit ist: Sie legen die IP-Adresse 46.41.a.b mit Netzmaske /29 (255.255.255.248) auf einem Interface Ihrer IPFire an.
Geräte, welche eine öffentliche IP-Adresse bekommen sollen, erhalten dann eine IP-Adresse aus dem Range 46.41.a.c bis i mit der Gateway-Adresse 46.41.a.b.
Damit sind die Systeme unter den konfigurierten IP-Adressen direkt aus dem Internet erreichbar.

Eine weitere möglichkeit ist, die Adressen mittels NAT bzw. 1:1-NAT auf interne Server zu lenken.
Wie dies mit IPFire funktioniert, müssten Sie ggf. dem Handbuch entnehmen.
Darauf hin fragte ich nochmal nach:
Der Ipfire hat die Karte eth0 - 3 und tun0

eth0 ist mit de WAN verbunden
eth1 ist 10.0.0.10
eth2 ist 10.0.1.10
eth3 ist 10.0.2.10 und die DMZ

tun0 ist der Tunnel mit 46.41.x.y (sie haben ihn ja bereits gepingt)

tun0 ist eine virtuelle Anlage und hat keine physische Karte zugeordnet mit eth0-3 ist auch bereits die physishe Auslastung des IPfire erreicht.

unter 10.0.2.20 gibt es einen Server

Ich habe nun noch folgende Fragen.

1. Wie kann ich mein festes IP-Kit von Portunity durch den tun0 schicken - wie realisiere ich bspw Ihre Möglichkeit 1?
2. Nun möchte ich gerne bspw. eine mögliche Adresse aus meinem Adresspool (feste IP Kit von Portunity - bspw. die 46.41.a.c) auf die 10.0.2.20 lenken
Als Antwort bekam ich:

zu 1. Leider kennen ich die IPFire jetzt nicht, unter Linux gibt es aber die Möglichkeit Policy based Routing (PBR) zu verwenden um je nach Absender IP einzelne Route setzen zu können. Wie Sie dies auf der IPFire konfigurieren können wir so allerdings leider nicht sagen.

zu 2. Dazu binden Sie diese IP mit der Subnet Maske /32 und setzen in Ihrer IPFire eine Route für Ihr Beispiel 46.41.23.178/32 Route und geben als nächsten Hop dann die Interne IP des an auf dem Sie die IP Gebunden haben. Wichtig ist dass das öffenltiche Netz von Ihrer IPFire nicht mit der Basis IP des Tunnels maskiert wird![/quote]

Hier bin ich jetzt leider mit meinem Latein am Ende, d.h. ich habe überhaupt keine Ahnung wie diese Konfiguration aussehen müsste.

Ich bräuchte also Hilfe mit konkreten Angaben, was ich in welcher Datei nun hineinschreiben muss.
Was genau muss ich in welche Datei schreiben, damit die IP-Adresse 46.41.a.b mit Netzmaske /29 (255.255.255.248) auf dem tun0 Interface meiner IPFire liegt?

Und wie kann ich Policy based Routing (PBR) verwenden um je nach Absender IP einzelne Route setzen zu können am konkreten Beispiel 46.41.a.c geht immer nach 10.0.2.20 und umgekehrt und wie lösche ich die Regeln beim reboot und schreibe sie beim Start wieder neu (

Code: Select all

https://www.portunity.de/access/wiki/PBR_(Policy_Based_Routing)
(Beim Herunterfahren des tun0-Interfaces werden die Regeln übrigens nicht gelöscht sondern bleiben (inaktiv) erhalten. Es kann jedoch zu interessanten Problemen kommen, wenn PBR-Regeln zu inaktiven Geräten vorhanden sind, deswegen empfiehlt es sich die Regeln über die ifup- und ifdown-Scripte zu setzen resp. wieder zu löschen.) [/b]?



Vielen lieben Dank.
Ein etwas verwirrter Elluminatus

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

Posted: August 27th, 2017, 8:24 am
by ummeegge
Moin Elluminatus,
im Prinzip sagt der Support ja auch das was schon weiter oben geschrieben wurde und noch ein wenig besser da du für und mit dem PBR noch weitere Ideen (+ commandline) dazu bekommen hast. Die Routen in der Form könntest du z.b. über die rc.local setzen (wird bei jedem System(re)start ausgeführt) oder du schreibst dir das in den Konfig File, ein Testskript was den Healthstatus des Tunnels bzw. der Konfiguration checkt wäre hierbei vielleicht auch ganz nett. Ein Beipspiel für beide Szenarios findet sich als erste Idee zum starten im Wiki --> http://wiki.ipfire.org/en/configuration ... ns/addconf .
Um nun die Verwirrung so klein wie möglich zu halten ich weiss nun nicht was du schon alles probiert hast bzgl. Routing, Firewalling, mein Stand war bis jetzt das der Tunnel sich aufgebaut hat (wie läuft das rekeying ?). Oben waren einige Ideen schon bennantworden, wäre gut zu wissen was du davon gemacht hast, wenn was nicht geklappt hat was dass dann war (am besten mit Logmeldungen), hast du den Paketfluss mal gecheckt (tcpdump z.b.) damit du weiss wo die Pakete 'falsch abbiegen' ;) .

Bin gerade unterwegs von daher potentielle Anwort sind mit Verzug gut möglich.

Grüsse,

UE