13.12.2019

2386

Fritzboxen VPN über RootServer und V6 Tunnel

Hallo Ihr lieben,

ich stehe wie viele demnächst vor dem Problem, das mein Anschluss auf (feste ungenattete) IP V6 umgestellt wird (Deutsche Glasfaser)
Bisher habe ich einen Unity Business Anschluss mit fester IP V4.
Nun habe ich mir überlegt, meinen ohnehin schon vorhandenen Root Server für mein VPN Netz zu "vergewaltigen".

Wie ich mir das vorstelle habe ich in einer kleinen Skizze im Anhang mal schnell aufgezeichnet.
Die derzeitigen Client Boxen wählen sich nach der umstellung bestenfalls über die Root Server öffentliche IP V4 an und werden per Portmapping dort einfach über einen V6 Tunnel zur "Master" Fritz weiter-/umgeleitet.

gegebene Voraussetzungen:

Clients --> alle IP V4 unterschiedlicher Provider, pingen über irgendein Gerät immer das 192.168.0.0 Netz an (klappt bisher prima zum Tunnel aufbauen)

Root Server --> feste öffentliche IP V4 mit rDNS und pingbar UND feste IP V6 (freie Range Verfügbar) 1GBit Bandbreite

"Master" Fritz --> nur noch feste (nicht genattete) IP V6 Range

Hat jemand eine Idee wie und mit welcher Software ich den Tunnel vom Root Server zur Fritz dauerhaft aufbauen/halten kann und wie das Portmapping auf
dem Root Server am Besten zu realisieren ist ?
Kann so ein Konstrukt funktionieren ?

Grüße und Danke im Voraus für Eure Ideen, bin sehr gespannt....

zyklop

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 525140

Url: https://administrator.de/forum/fritzboxen-vpn-ueber-rootserver-und-v6-tunnel-525140.html

Ausgedruckt am: 22.12.2024 um 13:12 Uhr

23 Kommentare

Neuester Kommentar

Oje, seit 7 Tagen nichtmal eine Antwort.....ist die Aufgabenstellung zu schwer oder habe ich etwa beim suchen die lösung meines problems übersehen ?

Grüße

zyklop

Hat jemand eine Idee wie und mit welcher Software ich den Tunnel vom Root Server zur Fritz dauerhaft aufbauen/halten

Wenn es dir nur um die Softwarefrage geht ist die Antwort ja recht einfach. Die FritzBox kann bekanntlich als VPN einzig nur native IPsec mit IKEv1 so das es übersichtlich wird.
Allerdings müssen wir wieder im freien Fall raten was für ein OS du denn auf deinem Server hast...

Bei Winblows nimms du den Klassiker: https://www.shrew.net/download
Bei Linux den Klassiker: https://www.strongswan.org
Fertisch... Weiss man eigentlich als Netzwerk Admin aber hast du vermutlich wirklich übersehen.

Zwei Dinge verwirren dennoch oben:

Einen reine v6 Anschluss gibt es eigentlich gar nicht. Das dürfte also nicht stimmen. Die DG wird dir sicher einen DS-Lite Anschluss legen mit CGN wie das üblich ist.
Eine "freie" v6 Range am Server dürfte auch nicht stimmen. Das ist mit Sicherheit ein vorgegebenes /64 oder anderer Prefix im Besitz des Server Hosters.

Beides spielt aber für die Lösung letztlich nur eine nebensächliche Rolle.

SO, ich bin nun einen riesen Schritt weiter,
Ich habe alle 6 SubNetze (Fritzboxen) erfolgreich auf meinem vServer verbunden und kann auch vom Vserver (Mitte der Sternförmigen Vernetzung) alle Netze Anpingen und auch von den Endpunkten zum Vserver (192.168.4.0 Netz) Die anderern haben 192.168.0.0 ~/1.0 ~/2.0 ~/5.0 ~/10.0 ~/11.0 (jeweils 192.168.x.x)
Dafür habe ich auf Ubuntu 18.04 den Strongswan (ipsec) installiert (kompiliert mit ipsec0 interface)
und die entsprechenden Configs auf die Fritzboxen gespielt.

Jetzt muss ich nur noch das 192.168.0.0 er Netzt mit dem 192.168.4.0 Netz verbinden damit ich auf alle anderen Netze Komme und alle anderen auf das 0er Netz.

Kann das 0er Netz leider nicht mehr "subnetten", da ich von IP 2 -253 fast alles vergeben habe.

Wie "route" ich nun auf dem vServer die Netze wie oben gewünscht ?
Hab schon Supernetting versucht, aber da weiss ich nicht so genau wie die configs da so ausehen müssten und ob die Fritzboxen dann noch connecten.

Hiermal beispielconfigs vom 0er und 2er Netz (Fritzbox) und von der /etc/ipsec.conf und secrets:

Fritz 0er Netz

vpncfg {
connections {
enabled = yes;
editable = no;
conn_type = conntype_lan;
name = "0erToRootserver";
boxuser_id = 0;
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remotehostname = "VSERVER-IP";
remote_virtualip = 0.0.0.0;
localid {
fqdn = "homebox";
}
remoteid {
fqdn = "VSERVER-IP";
}
mode = phase1_mode_idp;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "geheim";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.0.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.4.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.4.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}

Fritz 2er Netz

vpncfg {
connections {
enabled = yes;
editable = no;
conn_type = conntype_lan;
name = "2erToRootserver";
boxuser_id = 0;
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remotehostname = "VSERVER-IP";
remote_virtualip = 0.0.0.0;
localid {
fqdn = "homebox";
}
remoteid {
fqdn = "VSERVER-IP";
}
mode = phase1_mode_idp;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "geheim";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.2.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.4.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.4.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}

VSERVER ipsec.conf

config setup

conn home
authby=secret
auto=add
left=VSERVER-IP
leftsubnet=192.168.4.0/24
rightid=@homebox
rightsubnet=192.168.0.0/24
ike=aes256-sha-modp1024
esp=aes256-sha1-modp1024

conn home2
authby=secret
auto=add
left=VSERVER-IP
leftsubnet=192.168.4.0/24
rightid=@homebox2
rightsubnet=192.168.2.0/24
ike=aes256-sha-modp1024
esp=aes256-sha1-modp1024

VSERVER ipsec.secrets:

@homebox : PSK "geheim"
@homebox2 : PSK "geheim"

Wer bis hier zu lesen durchgehalten hat, der kann mir auch sicher weiterhelfen !!

Grüße
zyklop

Wie "route" ich nun auf dem vServer die Netze wie oben gewünscht ?

Da sollte dir ggf. dieser Thread helfen das zu lösen ?!
PFSense mit Fritzboxen verbinden

leider nein.....hier geht es um die config mit microtec Geräten....
Habe hier ein Fritzbox Netz auf Vserver......fehlt doch nur noch das routing ....
keiner eine idee ??
Habe jetzt schon den Fritten alle Netze bekannt gegeben, die in den Tunnel sollen....

accesslist = "permit ip any 192.168.4.0 255.255.255.0",
"permit ip any 192.168.0.0 255.255.255.0" ;

leider routet das ipsec0 Interface auf dem VServer das nicht, die pakete landen aber auf dem interface......fehlt nur noch dieses bisschen "verknoten".........
habe schon überlegt die 192.168.0.0 er Box (gewünschter Sternnetzmittelpunkt, was jetzt das 4er Netz/VServer ist) auf ein zweites interface einwählen zu lassen und dann z.B. ipsec0 und ipsec2 (or whatever) zu "bridgen", dann hätte ich doch auch die lösung oder ?!

wer weiss weiter ?!

Grüße
zyklop

mit microtec Geräten....

Wer ist Microtec ?? Gibt es eine Webseite zu diesem Hersteller ?
Zu deinem "Problem" findest du hier die Lösungen:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
PfSense IPsec hub and spoke
PFSense mit Fritzboxen verbinden

Hallo zyklop,

Hast du hierfür eine Lösung finden können? Ich stehe vor einem sehr ähnlichem Problem 😅.

Liebe Grüße,
Horst.

Einfach mal die Suchfunktion benutzen ! 😉
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

Hallo Aqui,
Ja, den Beitrag habe ich schon gesehen; nur bin ich mir da nicht so sicher, wie ich da mehrere FritzBoxen eingebunden bekomme?

Ich denke, dass der Abschnitt mit den Jumphosts der richtige einstiegspunkt ist. Eine fritzbox bekomme ich damit auch super eingebunden - nur wie geht es von da aus weiter? 😅

Das klappt so mit der Default Konfig. Jede weitere FB bekommt eine IP aus dem Pool addrs = 172.25.25.0/24 beim Dialin.
Das einzige was du machen musst ist nur eine andere User ID (id = keyid:strongswan@fritz.box) pro FB zu setzen.
Du kannst alternativ auch für alle diegleiche nutzen aber das ist sicherheitstechnisch natürlich nicht ganz so dolle. Klappt aber auch.

Hallo Aqui,
danke für Deine Mühen bisher

. Ich habe jetzt mal den Strongswan wie in der Anleitung neu aufgesetzt und ich bekomme auch zwei Fritzboxen mit dem VPS verbunden.

Meine aktuelle

/etc/swanctl/conf.d/vpn-server.conf

sieht (bis auf Platzhalter) wie folgt aus (die secrets werden noch ausgetauscht, jede box soll ein eigenes secret erhalten):

connections {
   fritz20 {
        local_addrs = <ip vom vps>
        remote_addrs = 0.0.0.0/0
        local {
            auth = psk
            id = <ip vom vps>
        }
        remote {
            auth = psk
            id = keyid:20@fritz.box
        }
        children {
            net {
                local_ts = 172.25.25.0/24
                remote_ts = 192.168.20.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }
        }
        version = 1
        fragmentation = yes
        proposals = aes256-sha1-modp1024
        rekey_time = 60m
        dpd_delay=0s
        encap=no
    }
    
     fritz178 {
        local_addrs = <ip vom vps>
        remote_addrs = 0.0.0.0/0
        local {
            auth = psk
            id = <ip vom vps>
        }
        remote {
            auth = psk
            id = keyid:178@fritz.box
        }
        children {
            net {
                local_ts = 172.25.25.0/24
                remote_ts = 192.168.178.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }
        }
        version = 1
        fragmentation = yes
        proposals = aes256-sha1-modp1024
        rekey_time = 60m
        dpd_delay=0s
        encap=no
    }  
}
pools {
  pool-ipv4 {
    addrs = 172.25.25.0/24
    dns = 172.16.7.254,10.99.1.254
  }
}
secrets {

 ike-1 {
      id = keyid:20@fritz.box
      secret = "-[TAB6gK:0u<#`1I7=CFc`g|/XYA6W"  
     }
 ike-2 {
      id = keyid:178@fritz.box
      secret = "-[TAB6gK:0u<#`1I7=CFc`g|/XYA6W"  
     }
}

die configs meiner Fritzboxen sehen jetzt so aus:

# Fritz 20
vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "vpn.meine-domain.tld";  
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = <ip des vps>;
                remote_virtualip = 0.0.0.0;
				localid {
                        key_id = "20@fritz.box";  
                }
                remoteid {
                        ipaddr = <ip des vps>;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "-[TAB6gK:0u<#`1I7=CFc`g|/XYA6W";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.20.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 172.25.25.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = "permit ip any 172.25.25.0 255.255.255.0";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
} 

Die für die Fritz178 sieht analog dazu aus - hier habe ich nur die 192.168.20.0 durch 192.168.178.0 ersetzt und die key-id ersetzt.

Wie gesagt - die Boxen verbinden sich mit dem VPS, leider komme ich noch nicht von meinem (.20.0) Netzwerk auf das andere (.178.0). (ich versuche stumpf von meinem Rechner die entlegene Fritte via ping 192.168.178.1 zu erreichen...)

Habe ich da was grundlegendes falsch gemacht?

Oh, und falls es interessant sein sollte:

~> cat /proc/sys/net/ipv4/ip_forward

1

Hast Du noch einen Tipp für mich?

... oder muss ich die anderen fritzboxen über den Punkt "Diese FRITZ!Box mit einem Firmen-VPN verbinden" verbinden? :O

leider komme ich noch nicht von meinem (.20.0) Netzwerk auf das andere (.178.0).

Denk dran das du die Fritz VPN Konfig Datei noch anpassen musst im Bereich "accesslist = "permit ip any..." Hast du das gemacht ? Oben ist das leider nicht zu sehen !
In der 178er FB muss da stehen:

accesslist = "permit ip any 172.25.25.0 255.255.255.0",
             "permit ip any 192.168.20.0 255.255.255.0"; 

und in der 20er FB entsprechend

accesslist = "permit ip any 172.25.25.0 255.255.255.0",
             "permit ip any 192.168.178.0 255.255.255.0"; 

Siehe auch hier:
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7490/230_Uber-VPN- ...
Achte auf Komma und Semikolon in dem Eintrag.
Andernfalls werden die jeweils remoten FB LAN IP-Netz sonst nicht in den Tunnel geroutet !
Dein vHost muss auch IP Forwarding aktiv haben in der sysctl.conf um diese Netze routen zu können.

Danke, dass Du Dir so geduldig Zeit für mich nimmst!

Die Einträge haben tatsächlich gefehlt. Die sind nun drin.

wie ich oben schon geschrieben habe, sollte das ip-forwarding aktiv sein:

cat /proc/sys/net/ipv4/ip_forward
1

leider funktioniert das mit dem Pingen noch immer nicht

.

Meine

/etc/swanctl/conf.d/vpn-server.conf

passt aber soweit?

Ansonsten hier noch mal die Ausgabe von sysctl -p:

sysctl -p /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

ggf. auch interessant:

ipsec status
Security Associations (2 up, 0 connecting):
    fritz178[2]: ESTABLISHED 115 seconds ago, <ip vps>[<ip vps>]...<public ip fb178>[178@fritz.box]
         net{2}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c6cd660c_i 51bb6eb7_o
         net{2}:   172.25.25.0/24 === 192.168.178.0/24
     fritz20[1]: ESTABLISHED 2 minutes ago, <ip vps>[<ip vps>]...<public ip fb20>[20@fritz.box]
         net{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c9ce51b2_i 76ba8ff7_o
         net{1}:   172.25.25.0/24 === 192.168.20.0/24

ich habe mir jetzt mal einen frischen Server geholt, der nur hierfür zu nutzen sein wird.

Muss ich bei iptables irgendwas beachten / konfigurieren?

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Kannst du denn die 172.25.25.er IPs des vServers pingen von den FB LANs ? Das würde erstmal den funktionierenden Tunnel auf den vServer verifizieren.
Ist die VPN Anzeige grün in der FB ?
Was zeigt ein traceroute auf die jeweiligen LAN IPs der FBs vom vServer bzw. aus den lokalen FB LANs ?

Die VPN-Anzeigen snd grün, die Log Einträge sagen auch "Verbindung hergestellt":

ich habe von meinem Rechner (aus der 20er FB) 172.25.25.1 bis 172.25.25.3 angepingt, alle mit timeouts. Zusätzlich habe ich mal ein

➜  ~ nmap -sn 172.25.25.0/24
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-02 21:06 CEST
Nmap done: 256 IP addresses (0 hosts up) scanned in 104.43 seconds

ausprobiert - tote Hose.

Traceroute .20 => 178

➜  ~ traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 64 hops max, 52 byte packets
 1  192.168.20.1 (192.168.20.1)  2.455 ms  2.880 ms  2.088 ms
 2  * * *
 3  * * *
 4  * *

traceroute VPS => .20:

traceroute 192.168.20.1
traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 60 byte packets
194.59.204.2 (194.59.204.2)  0.538 ms  0.506 ms  0.479 ms
ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  0.401 ms  0.376 ms  0.416 ms
ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)  3.804 ms  3.804 ms  3.787 ms
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* *^C

Deute ich das richtig, dass anscheinend gar keine "richtige" Verbindung zum VPS aufgebaut wird?

Zusätzlich noch die Ausgabe von netstat:

netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      322/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      456/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      456/sshd
udp        0      0 0.0.0.0:4500            0.0.0.0:*                           831/charon-systemd
udp        0      0 0.0.0.0:4500            0.0.0.0:*                           744/charon
udp        0      0 0.0.0.0:500             0.0.0.0:*                           831/charon-systemd
udp        0      0 0.0.0.0:500             0.0.0.0:*                           744/charon
udp        0      0 127.0.0.53:53           0.0.0.0:*                           322/systemd-resolve
udp        0      0 0.0.0.0:68              0.0.0.0:*                           831/charon-systemd
udp6       0      0 :::4500                 :::*                                831/charon-systemd
udp6       0      0 :::4500                 :::*                                744/charon
udp6       0      0 :::500                  :::*                                831/charon-systemd
udp6       0      0 :::500                  :::*                                744/charon

(mich wundert, dass da zwei charon-Instanzen(?) laufen. charon und charon-systemd...

... und hier noch einmal ein log, wenn sie die FB20 verbindet:

~# swanctl -T

07[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (532 bytes)
07[ENC] parsed ID_PROT request 0 [ SA V V V V V V ]
07[IKE] received XAuth vendor ID
07[IKE] received DPD vendor ID
07[IKE] received NAT-T (RFC 3947) vendor ID
07[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
07[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
07[ENC] received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
07[IKE] <public ip fb20> is initiating a Main Mode IKE_SA
07[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
07[ENC] generating ID_PROT response 0 [ SA V V V ]
07[NET] sending packet: from <ip vps>[500] to <public ip fb20>[500] (136 bytes)
07[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (228 bytes)
07[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
07[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
07[NET] sending packet: from <ip vps>[500] to <public ip fb20>[500] (244 bytes)
10[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (108 bytes)
10[ENC] parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
10[CFG] looking for pre-shared key peer configs matching <ip vps>...<public ip fb20>[20@fritz.box]
10[CFG] selected peer config "fritz20"  
10[IKE] IKE_SA fritz20[2] established between <ip vps>[<ip vps>]...<public ip fb20>[20@fritz.box]
10[IKE] scheduling rekeying in 3542s
10[IKE] maximum IKE_SA lifetime 3902s
10[ENC] generating ID_PROT response 0 [ ID HASH ]
10[NET] sending packet: from <ip vps>[500] to <public ip fb20>[500] (76 bytes)
10[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (92 bytes)
10[ENC] parsed INFORMATIONAL_V1 request 1382022848 [ HASH N(INITIAL_CONTACT) ]
15[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (716 bytes)
15[ENC] parsed QUICK_MODE request 1189992022 [ HASH SA No KE ID ID ]
15[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
15[IKE] received 3600s lifetime, configured 3960s
15[ENC] generating QUICK_MODE response 1189992022 [ HASH SA No KE ID ID ]
15[NET] sending packet: from <ip vps>[500] to <public ip fb20>[500] (316 bytes)
14[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (60 bytes)
14[ENC] parsed QUICK_MODE request 1189992022 [ HASH ]
14[IKE] CHILD_SA net{1} established with SPIs c961b8ea_i 09fb970b_o and TS 172.25.25.0/24 === 192.168.20.0/24


10[NET] received packet: from <public ip fb20>[500] to <ip vps>[500] (92 bytes)
10[ENC] parsed INFORMATIONAL_V1 request 1646706595 [ HASH N(DPD) ]
10[ENC] generating INFORMATIONAL_V1 request 2619893089 [ HASH N(DPD_ACK) ]
10[NET] sending packet: from <ip vps>[500] to <public ip fb20>[500] (92 bytes)

... in der Hoffnung, dass das alles etwas weiterhilft :D

... so, ich habe jetzt noch mal ein TCPDump gezogen, wenn ich von meinem Rechner (Fritz20) aus versuche 10.25.25.1 / 192.168.178.1 zu pingen.

Ich habe hierfür der Dokumentation (https://docs.strongswan.org/strongswan-docs/5.9/install/trafficDumps.htm ..) nach iptables angelegt.

ping 192.168.178.1:

# tcpdump -s 0 -n -i nflog:5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
49:05.045129 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x960), length 132
49:05.045227 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 3, length 64
49:06.069088 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x961), length 132
49:06.069127 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 4, length 64
49:06.069132 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x962), length 132
49:06.069135 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 5, length 64
49:08.053125 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x963), length 132
49:08.053164 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 6, length 64
49:09.077086 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x964), length 132
49:09.077123 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 7, length 64
49:09.077128 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x965), length 132
49:09.077131 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 8, length 64
49:11.061132 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x966), length 132
49:11.061171 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 9, length 64
49:12.085082 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x967), length 132
49:12.085123 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 10, length 64
49:12.085128 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x968), length 132
49:12.085132 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 11, length 64
49:14.101148 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x969), length 132
49:14.101195 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 12, length 64
49:14.101203 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96a), length 132
49:14.101209 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 13, length 64
49:16.149156 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96b), length 132
49:16.149204 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 14, length 64
49:16.149212 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96c), length 132
49:16.149218 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 15, length 64
49:18.197089 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96d), length 132
49:18.197136 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 16, length 64
49:18.197144 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96e), length 132
49:18.197149 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 17, length 64
49:20.085139 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96f), length 132
49:20.085181 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 18, length 64
49:20.085190 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x970), length 132
49:20.085193 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 19, length 64

ping 172.25.25.0:

# tcpdump -s 0 -n -i nflog:5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
49:58.421132 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98a), length 132
49:58.421344 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 3, length 64
49:58.421413 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98b), length 132
49:58.421460 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 4, length 64
50:00.405084 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98c), length 132
50:00.405120 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 5, length 64
50:00.405125 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98d), length 132
50:00.405128 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 6, length 64
50:02.421119 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98e), length 132
50:02.421161 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 7, length 64
50:02.421166 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98f), length 132
50:02.421168 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 8, length 64
50:04.405080 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x990), length 132
50:04.405115 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 9, length 64
50:05.429077 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x991), length 132
50:05.429109 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 10, length 64
50:05.429114 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x992), length 132
50:05.429117 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 11, length 64
^C
packets captured
packets received by filter
packets dropped by kernel

also prinzipiell scheint das routing zum Server ja zu klappen?

(UDP-encap) hatte ich testweise mal aktiviert...

Deute ich das richtig, dass anscheinend gar keine "richtige" Verbindung zum VPS aufgebaut wird?

Zumindestens der Ping kommt scheinbar nicht durch...

IPsec Pakete gehen aber an den vServer wie du mit UDP 4500 ja sehen kannst, der Tunnel ist also aktiv.
Sieht aber so aus als ob du fälschlicherweise die Netz Adresse gepingt hast was natürlich in die Hose geht. Du musst eine Hostadresse pingen wie 172.25.25.1

also prinzipiell scheint das routing zum Server ja zu klappen?

Jepp, das sieht gut aus.

So, ich habe jetzt mal mit einem Bekannten versucht, erst einmal seine und meine Fritzbox miteinander zu verbinden:

connections {
   fritz20 {
        local_addrs = <ip vps>
        remote_addrs = 0.0.0.0/0

        local {
            auth = psk
            id = <ip vps>
        }
        remote {
            auth = psk
            id = keyid:20@fritz.box
        }
        children {
            net20 {
                local_ts = 192.168.178.0/24
                remote_ts = 192.168.20.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }
        }
        version = 1
        fragmentation = yes
        proposals = aes256-sha1-modp1024
        rekey_time = 60m
        dpd_delay=0s
        encap=no
    }

    fritz178 {
        local_addrs = <ip vps>
        remote_addrs = 0.0.0.0/0
        local {
            auth = psk
            id = <ip vps>
        }
        remote {
            auth = psk
            id = keyid:178@fritz.box
        }
        children {
            net178 {
                local_ts = 192.168.20.0/24
                remote_ts = 192.168.178.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }

            net177 {
                local_ts = 192.168.178.0/24
                remote_ts = 192.168.177.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }

        }
        version = 1
        fragmentation = yes
        proposals = aes256-sha1-modp1024
        rekey_time = 60m
        dpd_delay=0s
        encap=no
    }


    fritz177 {
        local_addrs = <ip vps>
        remote_addrs = 0.0.0.0/0
        local {
            auth = psk
            id = <ip vps>
        }
        remote {
            auth = psk
            id = keyid:177@fritz.box
        }
        children {
            net178 {
                local_ts = 192.168.178.0/24
                remote_ts = 192.168.177.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }
        }
        version = 1
        fragmentation = yes
        proposals = aes256-sha1-modp1024
        rekey_time = 60m
        dpd_delay=0s
        encap=no
    }

}

secrets {
 ike-1 {
      id = keyid:20@fritz.box
      secret = "-[TAB6gK:0u<#`1I7=CFc`g|/XYA6W"  
     }
 ike-2 {
      id = keyid:178@fritz.box
      secret = "-[TAB6gK:0u<#`1I7=CFc`g|/XYA6W"  
     }

 ike-3 {
      id = keyid:177@fritz.box
      secret = "-[TAB6gK:0u<#`1I7=CFc`g|/XYA6W"  
     }

Das klappt so halb: FB178 kann sich entweder mit FB177 oder FB20 verbinden, beide gehen nicht: man kann anscheinend im Webinterface der FB nicht mehrere Verbindungen zum gleichen Host angeben. Ich vermute, dass hierfür die "Lösung" mit dem ipv4 pool genutzt werden sollte?

Das scheint etwas zu sein, was bei mir noch nicht klappt. Muss das Netz "172.25.25.0" irgendwie auf dem VPS angelegt werden?

Der Pool in der Beispielkonfig dient nur für die IKEv2 EAP Dialin VPN User die sich dort einwählen. Diese bekommen fortlaufend Adressen aus diesem virtuellen Pool. Das kannst du auch sehen wenn du ein ipconfig -all machst auf einem Windows VPN Client bei aktivem Tunnel.
Das ist quasi ein internes virtuelles Strongswan Netz. Deshalb ist in der FB Konfig das auch als remotes Netz angegeben.
M.E. ist das immer ein Punkt zu Punkt Netz also mit /30er Masken. Müsste man nochmal nachsehen.
Was dann vermutlich nicht geht ist dann intern über dieses Netz zu routen weil eben Punkt zu Punkt. Man müsste mal sehen wie dieses Netz als Pool Netz mit einer /24 an die Endgeräte gehen kann. Das würde vermutlich das Problem lösen.

Frage Netzwerke Router, Routing

Heiß diskutiert