18
OpenWrt Client hinter FritzBox für IPsec IKEv2 aufbau in Hauptzentrale (Site-to-Site)
Hallo liebe Community,
aktuell bin ich etwas am verzweifeln. Ich versuche seit Tagen erfolglos einen IPSec Tunnel zum Hauptstandort aufzubauen.
Netzwerkumgebung:
Sophos XG (Hauptstandort mit fester IP) dient als VPN Gateway im Modus nur Antworten, IKEv2 und für den Anfang PSK(pre-shared key)
FritzBox(dynamische IP und privates Heimnetz) --> OpenWrt Router mit einer IP aus dem LAN Netzwerk der FritzBox, der OpenWrt soll mittels strongswan einen IPsec Tunnel zur Sophos aufbauen und dahinter ein eigenes Netz bereitstellen, welches nacher zwischen Sophos und Openwrt geroutet wird.
Hat jemand von euch schon mal mit solch einer config zu tun gehabt und kann eventuell seine config Dateien zur Verfügung stellen. Ich bin auf dem OpenWrt gebiet auch absoluter Neuling und würde euch gerne um Hilfe bitten.
VG
FlashLightz
aktuell bin ich etwas am verzweifeln. Ich versuche seit Tagen erfolglos einen IPSec Tunnel zum Hauptstandort aufzubauen.
Netzwerkumgebung:
Sophos XG (Hauptstandort mit fester IP) dient als VPN Gateway im Modus nur Antworten, IKEv2 und für den Anfang PSK(pre-shared key)
FritzBox(dynamische IP und privates Heimnetz) --> OpenWrt Router mit einer IP aus dem LAN Netzwerk der FritzBox, der OpenWrt soll mittels strongswan einen IPsec Tunnel zur Sophos aufbauen und dahinter ein eigenes Netz bereitstellen, welches nacher zwischen Sophos und Openwrt geroutet wird.
Hat jemand von euch schon mal mit solch einer config zu tun gehabt und kann eventuell seine config Dateien zur Verfügung stellen. Ich bin auf dem OpenWrt gebiet auch absoluter Neuling und würde euch gerne um Hilfe bitten.
VG
FlashLightz
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 557576
Url: https://administrator.de/contentid/557576
Ausgedruckt am: 02.11.2024 um 22:11 Uhr
18 Kommentare
Neuester Kommentar
Hat jemand von euch schon mal mit solch einer config zu tun gehabt
In Zeiten von VPNs und Homeoffice wohl mittlerweile jeder !Das Szenario funktioniert auch fehlerlos !
Ein kritischer Punkt ist wie immer die FritzBox !
Diese ist ja selber ein aktiver VPN Router auf IPsec Basis. Es dürfen keinerlei VPN Konfigs oder User usw. auf der FritzBox definiert sein. Ansonsten "denkt" logischerweise die FB immer sie ist der VPN Endpoint und antwortet aktiv auf die eingehenden IPsec Pakete was sie ja nicht soll !
Das muss man also absolut sicherstellen das diese die VPN Pakete an den kaskadierten OpenWRT durchreicht. Auch indem man dort natürlich die zum Protokoll korrespondierenden Ports forwardet. Zwingend ist das:
- UDP 500
- UDP 4500
- ESP Protokoll (IP Nummer 50, Achtung: kein UDP oder TCP 50 !)
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das es fehlerfrei klappt kanst du an einer simplen IKEv1 Konfig mit StrongSwan sehen. IKEv2 ist identisch.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Funktioniert hier in einem laufenden Design auch ohne irgendwelche Probleme.
Tip:
Um sicherzustellen das die FB wirklich IPsec Pakete sauber ans Ziel forwardet schliesst du einfach mal einen Wireshark Sniffer PC mit der gleichen IP ans Netz die der WAN Port deines kaskadierten OpenVPN Routers entspricht.
Versuchst du dann von außen einen IPsec Tunnel aufzubauen solltest du dort eingehenden UDP 500, 4500 und ESP Pakete sehen. Damit ist dann sichergestellt das die FB wirklich alle IPsec Protokollkomponenten forwardet und sie kann dann als möglicher Fehler sicher ausgeschlossen werden.
Mit OpenWRT kannst du natürlich auch tcpdump (ggf. Package nachinstallieren) verwenden statt Wireshark. Ist sogar noch besser, denn dann kannst du das im Live Szenario mitsniffern !
Hi,
Vielen Dank für die schnelle Antwort.
Auf der FritzBox habe ich alle VPN Einstellungen deaktiviert und einen exposed host auf den OpenWRT Router gemacht.
Würde die Konfiguration von der ipsec.conf passen und wo kann ich phase 1 und phase 2 konfigurieren?
Der openwrt soll ja die Verbindung initiieren.
Eventuell verwechsel ich auch left und right?
Datei ipsec.secrets, wo kann man festlegen, dass strongswan die Infos aus der Datei holt?
VG
Vielen Dank für die schnelle Antwort.
Auf der FritzBox habe ich alle VPN Einstellungen deaktiviert und einen exposed host auf den OpenWRT Router gemacht.
Würde die Konfiguration von der ipsec.conf passen und wo kann ich phase 1 und phase 2 konfigurieren?
Der openwrt soll ja die Verbindung initiieren.
Eventuell verwechsel ich auch left und right?
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
charondebug="all"
# strictcrlpolicy=yes
uniqueids = no
# Add connections here.
# VPN connections
conn sophos-ikev2
auto=add
type=tunnel
keyexchange=ikev2
right=%all
rightsubnet=10.0.1.0/24 (LAN Hinter openwrt)
rightid=dnsnamefritzbox
rightauth="**mein PSK??**"
left=%defaultroute
leftid=publicipsophos
leftsubnet=172.28.0.0/16
dpdaction=restart
authby=secret
Datei ipsec.secrets, wo kann man festlegen, dass strongswan die Infos aus der Datei holt?
publicsophosip : PSK "mein psk" VG
- Was sagt ein tcpdump ?? Kommen die IPsec Pakete am OpenWRT an ?
- Was sagt das Strongswan Log ?? Wird ein Tunnel aufgebaut und kannst du mit ifconfig dann das virtuelle Tunnel interface sehen ?
Hi aqui,
ich konnte folgende Konfiguration nun mal testen.
/etc/ipsec.conf
Wenn ich nun im OpenWRT "ipsec restart" ausführe finde ich folgendes im LOG des OpenWRT, es kommt mir spanisch vor, dass die 172.17.4.59 Adresse hier auftaucht?
Auf der Sophos seite sehe ich folgendes im LOG, antworten tut die Sophos auf die Public IP der FritzBox, die Antwort dazu erhält Sie ja auch, somit gehe ich nicht von einem NAT Problem aus:
Es scheint als würde Phase 1 nicht richtig an die Sophos übertragen werden ?
Zudem anbei ein Bild von der IPsec-Policy auf der Sophos:
ich konnte folgende Konfiguration nun mal testen.
/etc/ipsec.conf
# Add connections here.
conn sophos
ikelifetime=36000s
keylife=8h
rekeymargin=3m
keyingtries=5
mobike=no
# This server
left=0.0.0.0/0
leftid=fritzbox.dyndns.org
# The network behind this server
leftsourceip=10.0.2.1
leftsubnet=10.0.2.0/24
# The remote Sophos
right=sophosip
rightid=sophosip
#The network behind remote Sophos
rightsubnet=172.28.0.0/16
#Connection parameters
keyexchange=ikev2
authby=secret
ike=aes256-sha256-modp2048,aes128-sha1-modp2048,3des-sha1-modp2048!
esp=aes256-sha256,aes256-sha1,3des-sha1!
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=starWenn ich nun im OpenWRT "ipsec restart" ausführe finde ich folgendes im LOG des OpenWRT, es kommt mir spanisch vor, dass die 172.17.4.59 Adresse hier auftaucht?
Fri Mar 13 22:31:45 2020 daemon.info : 06[CFG] received stroke: add connection 'sophos'
Fri Mar 13 22:31:45 2020 daemon.info : 06[CFG] left nor right host is our side, assuming left=local
Fri Mar 13 22:31:45 2020 daemon.info : 06[CFG] added configuration 'sophos'
Fri Mar 13 22:31:45 2020 daemon.info : 08[CFG] received stroke: initiate 'sophos'
Fri Mar 13 22:31:45 2020 daemon.info : 08[IKE] initiating IKE_SA sophos[1] to sophosip
Fri Mar 13 22:31:45 2020 authpriv.info : 08[IKE] initiating IKE_SA sophos[1] to sophosip
Fri Mar 13 22:31:45 2020 daemon.info : 08[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Fri Mar 13 22:31:45 2020 daemon.info : 08[NET] sending packet: from 172.17.4.59[500] to sophosip[500] (420 bytes)
Fri Mar 13 22:31:45 2020 daemon.info : 10[NET] received packet: from sophosip[500] to 172.17.4.59[500] (36 bytes)
Fri Mar 13 22:31:45 2020 daemon.info : 10[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
Fri Mar 13 22:31:45 2020 daemon.info : 10[IKE] received NO_PROPOSAL_CHOSEN notify errorAuf der Sophos seite sehe ich folgendes im LOG, antworten tut die Sophos auf die Public IP der FritzBox, die Antwort dazu erhält Sie ja auch, somit gehe ich nicht von einem NAT Problem aus:
2020-03-13 23:31:45 11[NET] <68> received packet: from 91.17.YYY.XXX[500] to SophosIP[500] (420 bytes)
2020-03-13 23:31:45 11[ENC] <68> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP)N(HASH_ALG) N(REDIR_SUP) ]
2020-03-13 23:31:45 11[IKE] <68> no IKE config found for SophosIP...91.17.YYY.XXX, sending NO_PROPOSAL_CHOSEN
2020-03-13 23:31:45 11[ENC] <68> generating IKE_SA_INIT response 0 [ N(NO_PROP)]
2020-03-13 23:31:45 11[NET] <68> sending packet: from SophosIP[500] to 91.17.YYY.XXX[500] (36 bytes)Es scheint als würde Phase 1 nicht richtig an die Sophos übertragen werden ?
Zudem anbei ein Bild von der IPsec-Policy auf der Sophos:
Ich teste das morgen mal mit einer pfSense und OpenWRT...
Super vielen Dank 
Test funktioniert wie erwartet problemlos. Ich musste allerdings die Proposals in der StrongSwan Konfig etwas anpassen und diese statisch hinzufügen. Im Gegensatz zu Ubuntu/Debian Linux wollte die OpenWRT Variante keine Proposals negotiaten ohne dedizierte Angabe in der Konfig und konnte so keine SAs etablieren. Mit der statischen Angabe gings dann problemlos.
OpenWRT Router ist ein GL.int AR300M
1.) pfSense Konfig P1 und P2:
Connect Status:
Die Firewall Konfig entspricht genau diesem Tutorial:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
2.) StrongSwan Package installiert:
3.) StrongSwan Konfig Files und Status:
ipsec.conf
ipsec.secrets
Nach ipsec up pfsense hier der StrangSwan Status:
Works as designed...
Das ist allerdings ein Client Dialin. Für einen Site to Site Tunnel muss ich noch eine neue P1 erstellen...kommt aber noch.
Grundsätzlich zeigt es aber das es klappt.
Deinen Fehler vermute ich bei rightid=dnsnamefritzbox
Das kann eigentlich nicht sein, es sei denn du hast in der Sophos diesen Namen als Identifier (Destinguished Name) definiert was sehr ungewöhnlich wäre und vermutlich auch nicht der Fall ist.
Du musst dich generell entscheiden ob du den Identifier über die IP Adresse machst oder über einen Namen. IP Adresse geht bei dir nicht, da du in einer Kaskade mit doppeltem NAT logischerweise keine feste öffentliche IP hast sondern eine RFC1918 hinter NAT, deshalb scheidet IP aus.
Als Identifier nimmt man dann aber in der Regel den Hostnamen der Firewall hier im Test pfsense.
Das hast du vermutlich falsch gemacht, denn wenn die Sophos auf Hostname steht als Identifier und dort ihr Name definiert ist, ist das (geraten) sicher nicht der DNS Domain Name des FritzBox DDNS.
Damit hast du dann aber einen Mismatch im Identifier was dann sofort den Tunnelaufbau abbricht !
Das solltest du checken !
OpenWRT Router ist ein GL.int AR300M
1.) pfSense Konfig P1 und P2:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
2.) StrongSwan Package installiert:
3.) StrongSwan Konfig Files und Status:
ipsec.conf
root@GL-AR300M:/etc# cat ipsec.conf
# Add connections here.
conn pfsense
keyexchange=ikev2
ike=aes256-sha256-modp2048
esp=aes256-sha256-modp2048
right=10.99.1.99
rightsubnet=192.168.1.0/24
rightid=pfsense
rightauth=pubkey
leftsourceip=%config4
leftcert=pfSenseCA.crt
leftauth=eap-mschapv2
eap_identity=testuser
dpdaction=restart
auto=add root@GL-AR300M:/etc# cat ipsec.secrets
# /etc/ipsec.secrets - strongSwan IPsec secrets file
testuser : EAP test123 Nach ipsec up pfsense hier der StrangSwan Status:
root@GL-AR300M:/etc# ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.9.120, mips):
uptime: 7 minutes, since Mar 14 19:48:58 2020
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent xcbc cmac hmac ctr ccm gcm curl mysql sqlite attr kernel-netlink resolve socket-default connmark forecast farp stroke vici smp updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap dhcp whitelist led duplicheck addrblock unity
Listening IP addresses:
192.x.y.z
192.168.8.1
fd25:3b81:cd46:10::1
Connections:
pfsense: %any...10.99.1.99 IKEv2, dpddelay=30s
pfsense: local: [CN=vpnca, C=DE, ST=XY, L=XY, O=Private, OU=Lab] uses EAP_MSCHAPV2 authentication with EAP identity 'testuser'
pfsense: cert: "CN=vpnca, C=DE, ST=XY, L=XY, O=Private, OU=Lab"
pfsense: remote: [pfsense] uses public key authentication
pfsense: child: dynamic === 192.168.1.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
pfsense[1]: ESTABLISHED 6 minutes ago, 192.168.7.173[CN=vpnca, C=DE, ST=XY, L=XY, O=Private, OU=Lab]...10.99.1.99[pfsense]
pfsense[1]: IKEv2 SPIs: e24434982197428f_i* 632f91c8cf91345a_r, EAP reauthentication in 2 hours
pfsense[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
pfsense{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8f3befb_i ca73f766_o
pfsense{1}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 37 minutes
pfsense{1}: 10.98.98.1/32 === 192.168.1.0/24
root@GL-AR300M:/etc# Works as designed...
Das ist allerdings ein Client Dialin. Für einen Site to Site Tunnel muss ich noch eine neue P1 erstellen...kommt aber noch.
Grundsätzlich zeigt es aber das es klappt.
Deinen Fehler vermute ich bei rightid=dnsnamefritzbox
Das kann eigentlich nicht sein, es sei denn du hast in der Sophos diesen Namen als Identifier (Destinguished Name) definiert was sehr ungewöhnlich wäre und vermutlich auch nicht der Fall ist.
Du musst dich generell entscheiden ob du den Identifier über die IP Adresse machst oder über einen Namen. IP Adresse geht bei dir nicht, da du in einer Kaskade mit doppeltem NAT logischerweise keine feste öffentliche IP hast sondern eine RFC1918 hinter NAT, deshalb scheidet IP aus.
Als Identifier nimmt man dann aber in der Regel den Hostnamen der Firewall hier im Test pfsense.
Das hast du vermutlich falsch gemacht, denn wenn die Sophos auf Hostname steht als Identifier und dort ihr Name definiert ist, ist das (geraten) sicher nicht der DNS Domain Name des FritzBox DDNS.
Damit hast du dann aber einen Mismatch im Identifier was dann sofort den Tunnelaufbau abbricht !
Das solltest du checken !
Guten Morgen,
vielen vielen Dank für die Hilfe.
Inzwischen steht der Tunnel schon, aber das Routing in beide Richtungen scheint nicht zu funktionieren.
Muss ich dem OpenWRT noch sagen, dass der Traffic mit den IP`s 172.28.XXX.XXX durch den tunnel muss, wenn ja wie ?
Ein tracert von meinem HomePC sieht so aus:
Routenverfolgung zu 172.28.0.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms openwrt.lan [10.0.2.1]
2 1 ms <1 ms <1 ms 172.17.10.1 #Hier müsste die Sophos stehen???
3 1 ms 1 ms 1 ms FRITZ-NAS [172.17.4.1]
Ich habe u.a. folgendes geändert:
leftid=openwrt
rightsourceip=%config4
ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!
Somit sieht meine ipsec.conf nun so aus
Auf dem OpenWRT bekomme ich folgendes LOG:
Auf der Sophos mit fester öffentlicher IP ohne NAT, sieht das LOG so aus:
Vielen vielen Dank schon mal für die Hilfe, alleine hätte ich das nie hinbekommen dem VPN überhaupt zum starten zu bekommen.
Grüße und schönen Sonntag
vielen vielen Dank für die Hilfe.
Inzwischen steht der Tunnel schon, aber das Routing in beide Richtungen scheint nicht zu funktionieren.
Muss ich dem OpenWRT noch sagen, dass der Traffic mit den IP`s 172.28.XXX.XXX durch den tunnel muss, wenn ja wie ?
Ein tracert von meinem HomePC sieht so aus:
Routenverfolgung zu 172.28.0.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms openwrt.lan [10.0.2.1]
2 1 ms <1 ms <1 ms 172.17.10.1 #Hier müsste die Sophos stehen???
3 1 ms 1 ms 1 ms FRITZ-NAS [172.17.4.1]
Ich habe u.a. folgendes geändert:
leftid=openwrt
rightsourceip=%config4
ike=aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!
Somit sieht meine ipsec.conf nun so aus
# Add connections here.
conn sophos
ikelifetime=36000s
keylife=8h
rekeymargin=3m
keyingtries=5
mobike=no
keyexchange=ikev2
# This server
left=0.0.0.0/0
leftid=openwrt
leftsourceip=10.0.2.1
leftsubnet=10.0.2.0/24
# The remote Sophos
#rightauth=psk
right=93.241.209.146
rightid=93.241.209.146
rightsubnet=172.28.0.0/16
rightsourceip=%config4
#Connection parameters
authby=secret
#eap_identity=
aes256-sha256-modp2048!
esp=aes256-sha256-modp2048!
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=startAuf dem OpenWRT bekomme ich folgendes LOG:
Sun Mar 15 09:25:27 2020 authpriv.info ipsec_starter[8784]: Starting strongSwan 5.6.3 IPsec [starter]...
Sun Mar 15 09:25:27 2020 authpriv.info ipsec_starter[8784]: !! Your strongswan.conf contains manual plugin load options for charon.
Sun Mar 15 09:25:27 2020 authpriv.info ipsec_starter[8784]: !! This is recommended for experts only, see
Sun Mar 15 09:25:27 2020 authpriv.info ipsec_starter[8784]: !! http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad
Sun Mar 15 09:25:27 2020 daemon.err modprobe: ah4 is already loaded
Sun Mar 15 09:25:27 2020 daemon.err modprobe: esp4 is already loaded
Sun Mar 15 09:25:27 2020 daemon.err modprobe: ipcomp is already loaded
Sun Mar 15 09:25:27 2020 daemon.err modprobe: xfrm4_tunnel is already loaded
Sun Mar 15 09:25:27 2020 daemon.err modprobe: xfrm_user is already loaded
Sun Mar 15 09:25:27 2020 daemon.info : 00[DMN] Starting IKE charon daemon (strongSwan 5.6.3, Linux 4.9.152, mips)
Sun Mar 15 09:25:31 2020 daemon.info : 00[LIB] curl SSL backend 'mbedTLS/2.16.3' not supported, https:// disabled
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] disabling load-tester plugin, not configured
Sun Mar 15 09:25:31 2020 daemon.info : 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] PKCS11 module '<name>' lacks library path
Sun Mar 15 09:25:31 2020 daemon.info : 00[LIB] plugin 'uci' failed to load: Error relocating /usr/lib/ipsec/plugins/libstrongswan-uci.so: uci_lookup: symbol not found
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] attr-sql plugin: database URI not set
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] coupling file path unspecified
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loaded 0 RADIUS server configurations
Sun Mar 15 09:25:31 2020 daemon.info : 00[NET] using forecast interface br-lan
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] HA config misses local/remote address
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] sql plugin: database URI not set
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loading crls from '/etc/ipsec.d/crls'
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loading secrets from '/etc/ipsec.secrets'
Sun Mar 15 09:25:31 2020 daemon.info : 00[CFG] loaded IKE secret for SOP.HOS.IPX.XXX
Sun Mar 15 09:25:31 2020 daemon.info : 00[LIB] loaded plugins: charon addrblock af-alg agent attr blowfish ccm cmac connmark constraints ctr curl des dhcp dnskey duplicheck eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls farp fips-prf forecast gcm gcrypt ldap led md4 md5 mysql openssl pem pgp pkcs1 pkcs11 pkcs12 pkcs7 pkcs8 pubkey random rc2 resolve revocation smp sqlite sshkey test-vectors unity vici whitelist x509 xauth-eap xauth-generic xcbc nonce aes gmp sha1 sha2 curve25519 hmac stroke kernel-netlink socket-default updown
Sun Mar 15 09:25:31 2020 daemon.info : 00[JOB] spawning 16 worker threads
Sun Mar 15 09:25:31 2020 authpriv.info ipsec_starter[8792]: charon (8793) started after 4320 ms
Sun Mar 15 09:25:31 2020 daemon.info : 06[CFG] received stroke: add connection 'sophos'
Sun Mar 15 09:25:31 2020 daemon.info : 06[CFG] left nor right host is our side, assuming left=local
Sun Mar 15 09:25:31 2020 daemon.info : 06[CFG] 'sophos' has both left- and rightsourceip, but IKE can negotiate one virtual IP only, ignoring local virtual IP
Sun Mar 15 09:25:31 2020 daemon.info : 06[CFG] added configuration 'sophos'
Sun Mar 15 09:25:31 2020 daemon.info : 08[CFG] received stroke: initiate 'sophos'
Sun Mar 15 09:25:31 2020 daemon.info : 08[IKE] initiating IKE_SA sophos[1] to SOP.HOS.IPX.XXX
Sun Mar 15 09:25:31 2020 authpriv.info : 08[IKE] initiating IKE_SA sophos[1] to SOP.HOS.IPX.XXX
Sun Mar 15 09:25:32 2020 daemon.info : 08[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Sun Mar 15 09:25:32 2020 daemon.info : 08[NET] sending packet: from 172.17.10.230[500] to SOP.HOS.IPX.XXX[500] (464 bytes)
Sun Mar 15 09:25:32 2020 daemon.info : 12[NET] received packet: from SOP.HOS.IPX.XXX[500] to 172.17.10.230[500] (466 bytes)
Sun Mar 15 09:25:32 2020 daemon.info : 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
Sun Mar 15 09:25:33 2020 daemon.info : 12[IKE] local host is behind NAT, sending keep alives
Sun Mar 15 09:25:33 2020 daemon.info : 12[IKE] authentication of 'openwrt' (myself) with pre-shared key
Sun Mar 15 09:25:33 2020 daemon.info : 12[IKE] establishing CHILD_SA sophos{1}
Sun Mar 15 09:25:33 2020 authpriv.info : 12[IKE] establishing CHILD_SA sophos{1}
Sun Mar 15 09:25:33 2020 daemon.info : 12[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Sun Mar 15 09:25:33 2020 daemon.info : 12[NET] sending packet: from 172.17.10.230[4500] to SOP.HOS.IPX.XXX[4500] (256 bytes)
Sun Mar 15 09:25:33 2020 daemon.info : 14[NET] received packet: from SOP.HOS.IPX.XXX[4500] to 172.17.10.230[4500] (224 bytes)
Sun Mar 15 09:25:33 2020 daemon.info : 14[ENC] parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
Sun Mar 15 09:25:33 2020 daemon.info : 14[IKE] authentication of 'SOP.HOS.IPX.XXX' with pre-shared key successful
Sun Mar 15 09:25:33 2020 daemon.info : 14[IKE] IKE_SA sophos[1] established between 172.17.10.230[openwrt]...SOP.HOS.IPX.XXX[SOP.HOS.IPX.XXX]
Sun Mar 15 09:25:33 2020 authpriv.info : 14[IKE] IKE_SA sophos[1] established between 172.17.10.230[openwrt]...SOP.HOS.IPX.XXX[SOP.HOS.IPX.XXX]
Sun Mar 15 09:25:33 2020 daemon.info : 14[IKE] scheduling reauthentication in 35712s
Sun Mar 15 09:25:33 2020 daemon.info : 14[IKE] maximum IKE_SA lifetime 35892s
Sun Mar 15 09:25:33 2020 daemon.info : 14[IKE] CHILD_SA sophos{1} established with SPIs c6484b3a_i c9c31789_o and TS 10.0.2.0/24 === 172.28.0.0/16
Sun Mar 15 09:25:33 2020 authpriv.info : 14[IKE] CHILD_SA sophos{1} established with SPIs c6484b3a_i c9c31789_o and TS 10.0.2.0/24 === 172.28.0.0/16Auf der Sophos mit fester öffentlicher IP ohne NAT, sieht das LOG so aus:
2020-03-15 10:25:32 19[ENC] <97> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2020-03-15 10:25:32 19[IKE] <97> FritzBoxPublicIP is initiating an IKE_SA
2020-03-15 10:25:32 19[IKE] <97> remote host is behind NAT
2020-03-15 10:25:32 19[ENC] <97> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
2020-03-15 10:25:32 19[NET] <97> sending packet: from SOP.HOS.IPX.XXX[500] to FritzBoxPublicIP[500] (466 bytes)
2020-03-15 10:25:33 18[NET] <97> received packet: from FritzBoxPublicIP[4500] to SOP.HOS.IPX.XXX[4500] (256 bytes)
2020-03-15 10:25:33 18[ENC] <97> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT)
2020-03-15 10:25:33 18[CFG] <97> looking for peer configs matching SOP.HOS.IPX.XXX[SOP.HOS.IPX.XXX]...FritzBoxPublicIP[openwrt]
2020-03-15 10:25:33 18[CFG] <HO2-1|97> selected peer config 'HO2-1'
2020-03-15 10:25:33 18[IKE] <HO2-1|97> authentication of 'openwrt' with pre-shared key successful
2020-03-15 10:25:33 18[IKE] <HO2-1|97> authentication of 'SOP.HOS.IPX.XXX' (myself) with pre-shared key
2020-03-15 10:25:33 18[IKE] <HO2-1|97> IKE_SA HO2-1[97] established between SOP.HOS.IPX.XXX[SOP.HOS.IPX.XXX]...FritzBoxPublicIP[openwrt]
2020-03-15 10:25:33 18[IKE] <HO2-1|97> scheduling rekeying in 28290s
2020-03-15 10:25:33 18[IKE] <HO2-1|97> maximum IKE_SA lifetime 28650s
2020-03-15 10:25:33 18[IKE] <HO2-1|97> CHILD_SA HO2-1{4} established with SPIs c9c31789_i c6484b3a_o and TS 172.28.0.0/16 === 10.0.2.0/24
2020-03-15 10:25:33 18[APP] <HO2-1|97> [SSO] (sso_invoke_once) SSO is disabled.
2020-03-15 10:25:33 18[APP] <HO2-1|97> [COP-UPDOWN] (ref_counting) ref_count: 0 to 1 ++ up ++ (172.28.0.0/16#10.0.2.0/24)
2020-03-15 10:25:33 18[APP] <HO2-1|97> [COP-UPDOWN] (ref_counting_remote) ref_count_remote: 0 to 1 ++ up ++ (SOP.HOS.IPX.XXX#FritzBoxPublicIP)
2020-03-15 10:25:33 18[APP] <HO2-1|97> [COP-UPDOWN] (cop_updown_invoke_once) UID: 97 Net: Local SOP.HOS.IPX.XXX Remote FritzBoxPublicIP Connection: HO2 Fullname: HO2-1
2020-03-15 10:25:33 18[APP] <HO2-1|97> [COP-UPDOWN] (cop_updown_invoke_once) Tunnel: User '' Peer-IP '' my-IP '' up-client
2020-03-15 10:25:33 18[ENC] <HO2-1|97> generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
2020-03-15 10:25:33 18[NET] <HO2-1|97> sending packet: from SOP.HOS.IPX.XXX[4500] to FritzBoxPublicIP[4500] (224 bytes)
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][DB] (db_conn_info) hostname: 'HO2' result --> id: '1', mode: 'ntn', tunnel_type: '0', subnet_family:'0'
2020-03-15 10:25:33 21[APP] [COP-UPDOWN] (do_cop_updown_invoke_once) ---- exec remote updown ++ up ++
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) '/bin/service fwm:vpn_gateway_chains -t json -s nosync -b '{"local_server":"SOP.HOS.IPX.XXX","remote_server":"FritzBoxPublicIP","action":"enable","family":"0","conntype":"ntn","compress":"0"}'': success 0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN] (do_cop_updown_invoke_once) ---- exec subnet updown ++ up ++
2020-03-15 10:25:33 21[APP] [COP-UPDOWN] (do_cop_updown_invoke_once) [NTN] NTN get actual...
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][DB] (db_query) No data retrieved from query: 'SELECT ( nath.netid || '/' || nath.netmask )
AS natedlan FROM tblvpnconnhostrel AS rel JOIN tblhost AS h
ON h.hostid = rel.hostid JOIN tblhost AS nath ON rel.natedhost = nath.hostid WHERE rel.connectionid = $1 AND rel.hostlocation = 'L'
AND h.netid = $2 AND h.netmask = $3 LIMIT 1;' status: 2 rows:0
2020-03-15 10:25:33 21[APP]
2020-03-15 10:25:33 21[APP] [COP-UPDOWN] (do_cop_updown_invoke_once) [IPSEC0] using ipsec dummy interface 'ipsec0'
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][NET] (get_src_ip) source address for 172.28.0.0 is IP: 172.28.0.254
2020-03-15 10:25:33 21[APP]
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) 'ip route add 10.0.2.0/24 dev ipsec0 src 172.28.0.254 table 220': success 0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN] (add_routes) no routes to add for HO2 on interface ipsec0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) 'ip route flush cache': success 0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) 'ip route flush cache': success 0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) '/bin/service fwm:vpn_connection_chains -t json -s nosync -b '{"me":"SOP.HOS.IPX.XXX","peer":"FritzBoxPublicIP",
"mynet":"172.28.0.0/16","peernet":"10.0.2.0/24","connop":"1","iface":"Port8_ppp","myproto":"0","myport":"0","peerproto":"0","peerport":"0","conntype":"ntn","actnet":"",
"compress":"0","conn_id":"1"}'': success 0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) 'conntrack -D --not-protonum=6 --inzone-outzone=2': success 0
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) 'conntrack -D --not-protonum=6 --inzone-outzone=5': error returned 1
2020-03-15 10:25:33 21[APP] [COP-UPDOWN][SHELL] (run_shell) 'conntrack -D --protonum=50': error returned 1
2020-03-15 10:26:03 07[IKE] <HO2-1|97> sending DPD request
2020-03-15 10:26:03 07[ENC] <HO2-1|97> generating INFORMATIONAL request 0 [ ]
2020-03-15 10:26:03 07[NET] <HO2-1|97> sending packet: from SOP.HOS.IPX.XXX[4500] to FritzBoxPublicIP[4500] (80 bytes)
2020-03-15 10:26:03 17[NET] <HO2-1|97> received packet: from FritzBoxPublicIP[4500] to SOP.HOS.IPX.XXX[4500] (80 bytes)
2020-03-15 10:26:03 17[ENC] <HO2-1|97> parsed INFORMATIONAL request 2 [ ]
2020-03-15 10:26:03 17[ENC] <HO2-1|97> generating INFORMATIONAL response 2 [ ]
2020-03-15 10:26:03 17[NET] <HO2-1|97> sending packet: from SOP.HOS.IPX.XXX[4500] to FritzBoxPublicIP[4500] (80 bytes)
2020-03-15 10:26:03 11[NET] <HO2-1|97> received packet: from FritzBoxPublicIP[4500] to SOP.HOS.IPX.XXX[4500] (80 bytes)
2020-03-15 10:26:03 11[ENC] <HO2-1|97> parsed INFORMATIONAL response 0 [ ] Vielen vielen Dank schon mal für die Hilfe, alleine hätte ich das nie hinbekommen dem VPN überhaupt zum starten zu bekommen.
Grüße und schönen Sonntag
Ich habe u.a. folgendes geändert:
Mal ne doofe Frage:Was bedeutet das "!" am Ende der Proposals "ike=aes256-sha256-modp2048!" und "esp=aes256-sha256-modp2048!"
Muss ich dem OpenWRT noch sagen,
Nein, vermutlich nicht. Der Buhmann wird die Firewall im OpenWRT sein. Ein Raspberry Pi mit exakt identischer StrongSwan Konfiguration kann sofort pingen und das VPN nutzen. Zeigt das es rein nur die OpenWRT Firewall sein kann.Vermutlich behandelt die OpenWRT Firewall den WAN Port global mit den FW Regeln und blockt damit auch VPN Verkehr von außen. Ich vermute das man hier die Firewall entsprechend customizen muss !
Googelt man nach (OpenWRT StrongSwan) gibt es da Tips eine Zone "vpn" anzulegen die das dann entsprechend regelt. Da muss ich aber auch noch etwas forschen wie sich das mit OpenWRT und dessen Firewall verhält
Zitat von @aqui:
Mal ne doofe Frage:
Was bedeutet das "!" am Ende der Proposals "ike=aes256-sha256-modp2048!" und "esp=aes256-sha256-modp2048!"
Ich habe das in diversen Anleitungen so gefunden, gerade mal ohne getestet. VPN steht auch.Mal ne doofe Frage:
Was bedeutet das "!" am Ende der Proposals "ike=aes256-sha256-modp2048!" und "esp=aes256-sha256-modp2048!"
Zitat von @aqui:
Vermutlich behandelt die OpenWRT Firewall den WAN Port global mit den FW Regeln und blockt damit auch VPN Verkehr von außen. Ich vermute das man hier die Firewall entsprechend customizen muss !
Googelt man nach (OpenWRT StrongSwan) gibt es da Tips eine Zone "vpn" anzulegen die das dann entsprechend regelt. Da muss ich aber auch noch etwas forschen wie sich das mit OpenWRT und dessen Firewall verhält
Vermutlich behandelt die OpenWRT Firewall den WAN Port global mit den FW Regeln und blockt damit auch VPN Verkehr von außen. Ich vermute das man hier die Firewall entsprechend customizen muss !
Googelt man nach (OpenWRT StrongSwan) gibt es da Tips eine Zone "vpn" anzulegen die das dann entsprechend regelt. Da muss ich aber auch noch etwas forschen wie sich das mit OpenWRT und dessen Firewall verhält
Die Anleitung: https://openwrt.org/docs/guide-user/services/vpn/ipsec/strongswan/firewa ... habe ich gefunden, leider kann ich aber keine Firewallregeln in der Art und Weise anlegen.
Hier auch noch mal kurz der Auszug aus ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.9.152, mips):
uptime: 59 minutes, since Mar 15 10:58:24 2020
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon addrblock af-alg agent attr blowfish ccm cmac connmark constraints ctr curl des dhcp dnskey duplicheck eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls farp fips-prf forecast gcm gcrypt ldap led md4 md5 mysql openssl pem pgp pkcs1 pkcs11 pkcs12 pkcs7 pkcs8 pubkey random rc2 resolve revocation smp sqlite sshkey test-vectors unity vici whitelist x509 xauth-eap xauth-generic xcbc nonce aes gmp sha1 sha2 curve25519 hmac stroke kernel-netlink socket-default updown
Virtual IP pools (size/online/offline):
172.28.0.254: 1/0/0
Listening IP addresses:
10.0.2.1
fd90:6653:f7eb::1
172.17.10.230
Connections:
sophos: 0.0.0.0/0...sophospublicip IKEv2, dpddelay=30s
sophos: local: [openwrt] uses pre-shared key authentication
sophos: remote: [sophospublicip] uses pre-shared key authentication
sophos: child: 10.0.2.0/24 === 172.28.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
sophos[1]: ESTABLISHED 59 minutes ago, 172.17.10.230[openwrt]...sophospublicip[sophospublicip]
sophos[1]: IKEv2 SPIs: be4faa3e78853a48_i* 8226bb2d17016f99_r, pre-shared key reauthentication in 8 hours
sophos[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
sophos{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ca0fdb5e_i c7a3a070_o
sophos{1}: AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 6 hours
sophos{1}: 10.0.2.0/24 === 172.28.0.0/16
Erklärung zum "!" gefunden in der StrongSwan Doku:
"If you use ipsec.conf, you have to add an exclamation mark (!) to the end , otherwise the default proposals are appended, which might contain algorithms you do not want to use.
In order to restrict a responder to only accept specific cipher suites, the strict flag (!, exclamation mark)"
Man erzwingt damit also diese Crypto Credentials. Zwingend sind sie aber dann nicht wenn man es am Responder vorgibt. Oben hatte ich den auf "Auto" und nun mal "AES 256" vorgegeben im Responder und dann muss man sie auch nicht setzen im Strongswan.
Bei dir taucht ja wenigstens eine Zone "vpn" in Luci auf. Die habe ich hier auf dem GL.inet nicht einmal.
Ich vermute aber das das eine Eigenart des GL.inet ist ?!
Habe jetzt auch eine reine IKEv2 Tunnel Connection am laufen mit:
Die ipsec.secret sieht so aus:
Status:
root@GL-AR300M:~# ipsec status
Security Associations (1 up, 0 connecting):
pfsense[2]: ESTABLISHED 9 minutes ago, 192.x.y.173[strongswan]...10.99.1.99[pfsense]
pfsense{2}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: c73cb57e_i c4af2742_o
pfsense{2}: 192.168.8.0/24 === 192.168.1.0/24
root@GL-AR300M:~#
Tunnel steht also...!
Das klappt vom Tunnelaufbau fehlerlos. Aber...
Durch den Tunnel kommt nix !
Wenn du testhalber mal einen RasPi mit Strongswan und exakt der gleichen Konfig in exakt dem gleichen Design nimmst gehen Pings und Daten problemlos durch den Tunnel !! Strongswan ist es also de facto nicht !
Was zeigt das nur die OpenWRT Firewall der böse Buhmann ist.
Nur... wie bringt man der nun bei das sie VPN Tunneltraffic am WAN Port passieren lassen soll ?? Grrr...
Der muss man irgendwie sagen das SRC:192.168.1.0/4 -> DST: 192.168.8.0/24 passieren darf, nur ich finde keine Option dort zur Eingabe von IP Adressen. Muss wohl nochmal Dr. Google ran...?!
"If you use ipsec.conf, you have to add an exclamation mark (!) to the end , otherwise the default proposals are appended, which might contain algorithms you do not want to use.
In order to restrict a responder to only accept specific cipher suites, the strict flag (!, exclamation mark)"
Man erzwingt damit also diese Crypto Credentials. Zwingend sind sie aber dann nicht wenn man es am Responder vorgibt. Oben hatte ich den auf "Auto" und nun mal "AES 256" vorgegeben im Responder und dann muss man sie auch nicht setzen im Strongswan.
Bei dir taucht ja wenigstens eine Zone "vpn" in Luci auf. Die habe ich hier auf dem GL.inet nicht einmal.
Ich vermute aber das das eine Eigenart des GL.inet ist ?!
Habe jetzt auch eine reine IKEv2 Tunnel Connection am laufen mit:
conn pfsense
keyexchange=ikev2
authby=psk
right=10.99.1.99
rightsubnet=192.168.1.0/24
rightid=pfsense
rightauth=psk
left=%any
leftsubnet=192.168.8.0/24
leftid=strongswan
leftauth=psk
dpdaction=restart
mobike=no
auto=add # /etc/ipsec.secrets - strongSwan IPsec secrets file
: PSK "test123" root@GL-AR300M:~# ipsec status
Security Associations (1 up, 0 connecting):
pfsense[2]: ESTABLISHED 9 minutes ago, 192.x.y.173[strongswan]...10.99.1.99[pfsense]
pfsense{2}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: c73cb57e_i c4af2742_o
pfsense{2}: 192.168.8.0/24 === 192.168.1.0/24
root@GL-AR300M:~#
Tunnel steht also...!
Das klappt vom Tunnelaufbau fehlerlos. Aber...
Durch den Tunnel kommt nix !
Wenn du testhalber mal einen RasPi mit Strongswan und exakt der gleichen Konfig in exakt dem gleichen Design nimmst gehen Pings und Daten problemlos durch den Tunnel !! Strongswan ist es also de facto nicht !
Was zeigt das nur die OpenWRT Firewall der böse Buhmann ist.
Nur... wie bringt man der nun bei das sie VPN Tunneltraffic am WAN Port passieren lassen soll ?? Grrr...
Der muss man irgendwie sagen das SRC:192.168.1.0/4 -> DST: 192.168.8.0/24 passieren darf, nur ich finde keine Option dort zur Eingabe von IP Adressen. Muss wohl nochmal Dr. Google ran...?!
So, Teilerfolg !
Schaltet man das Masquerading und Rejecting ab am OpenWRT WAN Port klappt es erwartungsgemäß sofort !
Gut, in einer Kaskade mit einem NAT Router davor wie deiner FritzBox kann man damit problemlos leben. Dort ne statische Route auf das IP Netz hinter dem OpenWRT und transparent routen. Fertig ist der Lack !
Damit wäre das Problem dann erstmal gelöst in so einen Kaskaden Umfeld wenn man auf NAT und FW am kaskadierten System verzichten kann.
So sieht das jetzt funktionierende Design aus:
Aber irgendwie muss man das doch auch der OpenWRT Firewall beibringen können das die auch mit NAT den Traffic passieren lässt...??
https://openwrt.org/docs/guide-user/services/vpn/ipsec/strongswan/firewa ...
Schaltet man das Masquerading und Rejecting ab am OpenWRT WAN Port klappt es erwartungsgemäß sofort !
Gut, in einer Kaskade mit einem NAT Router davor wie deiner FritzBox kann man damit problemlos leben. Dort ne statische Route auf das IP Netz hinter dem OpenWRT und transparent routen. Fertig ist der Lack !
Damit wäre das Problem dann erstmal gelöst in so einen Kaskaden Umfeld wenn man auf NAT und FW am kaskadierten System verzichten kann.
So sieht das jetzt funktionierende Design aus:
Aber irgendwie muss man das doch auch der OpenWRT Firewall beibringen können das die auch mit NAT den Traffic passieren lässt...??
https://openwrt.org/docs/guide-user/services/vpn/ipsec/strongswan/firewa ...
Hi,
vielen Dank für deinen Beitrag. Ich habe es so ausprobiert, aber irgendwie schein doch noch etwas zu klemmen....
Auf der FritzBox habe ich jetzt:
IPv4 Routing für das OpenWrt Netz gemacht mit der WAN SchnittstellenIP vom OpenWRT.
UDP500&4500, ESP Forwarded auf WAN SChnittstellenIP vom OpenWRT
Auf dem OpenWRT:
Wie in dem Screenshot beschrieben alles auf accept und Masquerading deaktiviert.
Wie vorher auch schon steht der Tunnel und es geht weiterhin nichts durch den Tunnel
Langsam bin ich ja mit meinem Latein am Ende, spricht etwas gegen eine Remotesession?
VG
vielen Dank für deinen Beitrag. Ich habe es so ausprobiert, aber irgendwie schein doch noch etwas zu klemmen....
Auf der FritzBox habe ich jetzt:
IPv4 Routing für das OpenWrt Netz gemacht mit der WAN SchnittstellenIP vom OpenWRT.
UDP500&4500, ESP Forwarded auf WAN SChnittstellenIP vom OpenWRT
Auf dem OpenWRT:
Wie in dem Screenshot beschrieben alles auf accept und Masquerading deaktiviert.
Wie vorher auch schon steht der Tunnel und es geht weiterhin nichts durch den Tunnel
Langsam bin ich ja mit meinem Latein am Ende, spricht etwas gegen eine Remotesession?
VG
Hast du den OpenWRT mal rebootet ??
Wenn die Firewall und NAT so aus ist kannst du denn dann transparent routen zwischen beiden IP Netzen ?!
Das würde ja erstmal verifizieren das das Routing dann sauber klappt und NAT deaktiviert ist.
Habs hier auf einem 2ten GL.inet diesmal ein MT300N v2 wiederholt und auch da klappte es sofort auf Anhieb mit diesen FW Settings !!
Vielleicht mal den OpenWRT wieder auf Werksreset, StrongSwan-full Package neu installieren und nochmal ganz neu aufsetzen ?!
Sonst nimmst du einen RasPi 4
Wenn die Firewall und NAT so aus ist kannst du denn dann transparent routen zwischen beiden IP Netzen ?!
Das würde ja erstmal verifizieren das das Routing dann sauber klappt und NAT deaktiviert ist.
Habs hier auf einem 2ten GL.inet diesmal ein MT300N v2 wiederholt und auch da klappte es sofort auf Anhieb mit diesen FW Settings !!
Vielleicht mal den OpenWRT wieder auf Werksreset, StrongSwan-full Package neu installieren und nochmal ganz neu aufsetzen ?!
Sonst nimmst du einen RasPi 4
Hi aqui,
vielen Dank!
Auch wenn ich Ihn nicht neu installiert habe, läuft der Tunnel jetzt. Ganz interessant ist, das ich vom OpenWrt nicht Pingen kann, aber von meinen Clients!
Als letztes wäre es natürlich super geil wenn ich an der FritzBox keine Einstellungen ändern müsste, denkst du das bekommen wir noch irgendwie hin?
Und hast du bedenken im Thema Sicherheit ?
VG & 1000 Dank!
vielen Dank!
Auch wenn ich Ihn nicht neu installiert habe, läuft der Tunnel jetzt. Ganz interessant ist, das ich vom OpenWrt nicht Pingen kann, aber von meinen Clients!
Als letztes wäre es natürlich super geil wenn ich an der FritzBox keine Einstellungen ändern müsste, denkst du das bekommen wir noch irgendwie hin?
Und hast du bedenken im Thema Sicherheit ?
VG & 1000 Dank!
läuft der Tunnel jetzt.
👍das ich vom OpenWrt nicht Pingen kann, aber von meinen Clients!
Das liegt vermutlich daran das der OpenVPN eine andere Source IP nutzt. Hast du mehrere LAN Segmente am OpenWRT oder nur LAN und WAN.Mein GL.inet hat nur die 2 Interfaces und da klappt es auch vom Router selber fehlerlos.
wenn ich an der FritzBox keine Einstellungen ändern müsste
Was genau meinst du damit ??Du betreibst das ganze ja in einer kaskaden Struktur. Ein Port Forwarding der IPsec Ports sind daher immer zwingend, das ist dir vermutlich auch klar.
Anders könnte die FB ja die IPsec Frames niemals an den dahinter kaskadierten Router weiterleiten weil eingehende Pakete sonst nie deren Firewall überwinden könnten.
Das wird also in einem Kaskaden Design immer bleiben müssen. Sofern du das denn meinst und nicht irgendwas anderes ?!?
Es sei denn du terminierst das IPsec direkt auf der FritzBox, was ja auch gehen würde da die FB ja selber aktiv IPsec kann. Allerdings ist deren VPN Performance sehr gruselig. Klar, denn sie ist ja ein billiger Plaste Consumer Router und für den Massenmarkt gemacht und eben kein Business Router. So fair muss man ja sein.
Und hast du bedenken im Thema Sicherheit ?
Nöö. Die Firewall der FB ist ja voll aktiv und schützt letztlich alles was dahinter ist.
Ich habe nur LAN/WAN/VPN als Zone.
Und nur mein internes Segment.
Soweit passen die Einstellungen nun.
Nun musste ich aber zusätzlich noch feststellen, dass nur einseitiger Verkehr möglich ist, wenn ich vom Sophos HQ aus, einen Ping auf einen Client absetze geht das nicht.
VG
Und nur mein internes Segment.
Soweit passen die Einstellungen nun.
Nun musste ich aber zusätzlich noch feststellen, dass nur einseitiger Verkehr möglich ist, wenn ich vom Sophos HQ aus, einen Ping auf einen Client absetze geht das nicht.
VG
Was dann aber wieder für ein Firewall Problem spricht.
Wenn du Pingen kannst, dann ist das ja immer ein beidseitiger Test. Du schickst ein ICMP Echo Request und das Ziel antwortet mit einem ICMP Echo Reply. Es wird also Hin- und Rückroute getestet. Wenn der Ping durchkommt klappen also immer auch beide Richtungen.
Das riecht also irgendwo nach einer FW Regel in der Sophos oder sowas...?!
Hier im testaufbau mit der pfSense klappt das bei beiden OpenWRT Router bidirektional. Ich kann also auch über das Diagnostic Menü der FW den OpenWRT pingen.
Endgeräte in den jeweiligen LANs klappt auch fehlerlos.
Wenn du Pingen kannst, dann ist das ja immer ein beidseitiger Test. Du schickst ein ICMP Echo Request und das Ziel antwortet mit einem ICMP Echo Reply. Es wird also Hin- und Rückroute getestet. Wenn der Ping durchkommt klappen also immer auch beide Richtungen.
Das riecht also irgendwo nach einer FW Regel in der Sophos oder sowas...?!
Hier im testaufbau mit der pfSense klappt das bei beiden OpenWRT Router bidirektional. Ich kann also auch über das Diagnostic Menü der FW den OpenWRT pingen.
Endgeräte in den jeweiligen LANs klappt auch fehlerlos.
