zyklop
Dec 13, 2019
view2198
view23
0
Goto Top

Fritzboxen VPN über RootServer und V6 Tunnel

GermanQuestionRouters, RoutingNetworks
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
fritzvpn
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 525140

Url: https://administrator.de/contentid/525140

Printed on: April 19, 2024 at 13:04 o'clock

23 Comments
Latest comment
Goto Top
Member: zyklop
zyklop Dec 21, 2019 at 16:32:36 (UTC)
Goto Top
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
Member: aqui
aqui Dec 21, 2019 updated at 16:55:40 (UTC)
Goto Top
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... face-sad
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. face-wink
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.
Member: zyklop
zyklop Feb 15, 2020 at 13:40:54 (UTC)
Goto Top
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
Member: aqui
aqui Feb 15, 2020 at 14:22:54 (UTC)
Goto Top
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
Member: zyklop
zyklop Feb 17, 2020 updated at 22:06:52 (UTC)
Goto Top
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
Member: aqui
aqui Feb 18, 2020 at 10:49:24 (UTC)
Goto Top
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
Member: Horstchen
Horstchen Apr 01, 2022 at 20:56:04 (UTC)
Goto Top
Hallo zyklop,

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

Liebe Grüße,
Horst.
Member: aqui
aqui Apr 02, 2022 at 09:22:13 (UTC)
Goto Top
Einfach mal die Suchfunktion benutzen ! 😉
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Member: Horstchen
Horstchen Apr 02, 2022 at 09:47:42 (UTC)
Goto Top
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? 😅
Member: aqui
aqui Apr 02, 2022 at 09:56:03 (UTC)
Goto Top
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.
Member: Horstchen
Horstchen Apr 02, 2022 updated at 14:43:46 (UTC)
Goto Top
Hallo Aqui,
danke für Deine Mühen bisher face-smile. 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? face-smile
Member: Horstchen
Horstchen Apr 02, 2022 at 12:40:21 (UTC)
Goto Top
... oder muss ich die anderen fritzboxen über den Punkt "Diese FRITZ!Box mit einem Firmen-VPN verbinden" verbinden? :O
Member: aqui
aqui Apr 02, 2022 updated at 14:58:10 (UTC)
Goto Top
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.
heart1
Member: Horstchen
Horstchen Apr 02, 2022 updated at 15:52:50 (UTC)
Goto Top
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 face-sad.

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
Member: Horstchen
Horstchen Apr 02, 2022 updated at 15:53:49 (UTC)
Goto Top
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
Member: aqui
aqui Apr 02, 2022 at 18:47:06 (UTC)
Goto Top
  • 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 ?
Member: Horstchen
Horstchen Apr 02, 2022 updated at 20:03:48 (UTC)
Goto Top
  • Die VPN-Anzeigen snd grün, die Log Einträge sagen auch "Verbindung hergestellt":
bildschirmfoto 2022-04-02 um 21.14.23

bildschirmfoto 2022-04-02 um 21.12.59

  • 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
 1  194.59.204.2 (194.59.204.2)  0.538 ms  0.506 ms  0.479 ms
 2  ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  0.401 ms  0.376 ms  0.416 ms
 3  ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)  3.804 ms  3.804 ms  3.787 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * *^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...
Member: Horstchen
Horstchen Apr 02, 2022 at 20:02:32 (UTC)
Goto Top
... 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
Member: Horstchen
Horstchen Apr 03, 2022 at 05:53:00 (UTC)
Goto Top
... 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
07:49:05.045129 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x960), length 132
07:49:05.045227 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 3, length 64
07:49:06.069088 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x961), length 132
07:49:06.069127 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 4, length 64
07:49:06.069132 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x962), length 132
07:49:06.069135 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 5, length 64
07:49:08.053125 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x963), length 132
07:49:08.053164 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 6, length 64
07:49:09.077086 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x964), length 132
07:49:09.077123 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 7, length 64
07:49:09.077128 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x965), length 132
07:49:09.077131 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 8, length 64
07:49:11.061132 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x966), length 132
07:49:11.061171 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 9, length 64
07:49:12.085082 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x967), length 132
07:49:12.085123 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 10, length 64
07:49:12.085128 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x968), length 132
07:49:12.085132 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 11, length 64
07:49:14.101148 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x969), length 132
07:49:14.101195 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 12, length 64
07:49:14.101203 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96a), length 132
07:49:14.101209 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 13, length 64
07:49:16.149156 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96b), length 132
07:49:16.149204 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 14, length 64
07:49:16.149212 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96c), length 132
07:49:16.149218 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 15, length 64
07:49:18.197089 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96d), length 132
07:49:18.197136 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 16, length 64
07:49:18.197144 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96e), length 132
07:49:18.197149 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 17, length 64
07:49:20.085139 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x96f), length 132
07:49:20.085181 IP 192.168.20.50 > 192.168.178.1: ICMP echo request, id 35692, seq 18, length 64
07:49:20.085190 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x970), length 132
07: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
07:49:58.421132 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98a), length 132
07:49:58.421344 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 3, length 64
07:49:58.421413 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98b), length 132
07:49:58.421460 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 4, length 64
07:50:00.405084 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98c), length 132
07:50:00.405120 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 5, length 64
07:50:00.405125 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98d), length 132
07:50:00.405128 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 6, length 64
07:50:02.421119 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98e), length 132
07:50:02.421161 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 7, length 64
07:50:02.421166 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x98f), length 132
07:50:02.421168 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 8, length 64
07:50:04.405080 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x990), length 132
07:50:04.405115 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 9, length 64
07:50:05.429077 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x991), length 132
07:50:05.429109 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 10, length 64
07:50:05.429114 IP <public ip fritz20>.4500 > <ip vps>.4500: UDP-encap: ESP(spi=0xc084fd8a,seq=0x992), length 132
07:50:05.429117 IP 192.168.20.50 > 172.25.25.0: ICMP echo request, id 3181, seq 11, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

also prinzipiell scheint das routing zum Server ja zu klappen?
Member: Horstchen
Horstchen Apr 03, 2022 at 11:01:34 (UTC)
Goto Top
(UDP-encap) hatte ich testweise mal aktiviert...
Member: aqui
aqui Apr 03, 2022 at 12:23:26 (UTC)
Goto Top
Deute ich das richtig, dass anscheinend gar keine "richtige" Verbindung zum VPS aufgebaut wird?
Zumindestens der Ping kommt scheinbar nicht durch... face-sad
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.
Member: Horstchen
Horstchen Apr 03, 2022 updated at 12:55:41 (UTC)
Goto Top
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?
Member: aqui
aqui Apr 03, 2022 at 13:10:33 (UTC)
Goto Top
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.
GermanQuestionRouters, RoutingNetworks
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 3 CommentsAlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment