25
IPSec VPN- Tunnel MikroTik HEX und FritzBox - SMB Zugriff funktioniert nicht
Hallo zusammen,
ich habe zwei Standorte über einen VPN IPSec Tunnel verbunden.
Standort A:
lokales Netz 192.168.100.0/24
VPN- Router = FritzBox 7590 mit fester öffentlicher IP (80.XXX.XXX.XXX)
Standort B:
lokales Netz 192.168.101.0/24
VPN- Router: MikroTik HEX S (6.47) hinter einer PFSense mit fester öffentlicher IP (62.XXX.XXX.XXX).
Der LAN Port (10.10.0.1) der PFsense und der WAN Port des MikroTik Routers (10.10.0.2) sind in einem Transfernetz (10.10.0.0/24). In der PFSense wurden die Ports 500, 4500 und Protokoll ESP auf die 10.10.0.2 weitergeleitet.
Ich habe das Problem, dass ich über den VPN- Tunnel nicht auf die Dateifreigabe eines Windows 7 Clients mit der 192.168.101.99 zugreifen kann. Der Zugriff per RDP ist aber möglich und ich kann über den VPN- Tunnel auch andere Dienste auf der Gegenseite erreichen (z.b. WebServer HTTP).
Bisher wurde für den Zugriff der AVM FritzFernzugang verwendet und damit ist der Zugriff auf die Dateifreigabe möglich (der VPN- Client bekommt dann eine lokale IP aus dem gleichen Netz der FritzBox 192.168.100.0/24). Freigabe und Benutzer sind somit korrekt eingerichtet und funktioniert grundsätzlich.
Ich habe im ersten Schritt eine Forward Regel (192.168.100.0/24 -> 192.168.101.0/24) eingerichtet. Außerdem habe ich die Windows Firewall Regel angepasst und bei Eingehend SMB zusätzlich zum lokalen Netzwerk noch die 192.168.100/24 eingetragen. Ausgehend habe ich das auf der anderen Seite auch kontrolliert/ erweitert.
Außerdem habe ich auf beiden Seiten bereits die Windows Firewall deaktiviert. Leider ohne Erfolg.
Ich habe dann einen Port Scan mit NMAP auf den Windows 7 Client gemacht auf den ich per SMB zugreifen will.
Port 445 ist nicht offen (Port 3389 ist offen und RDP Verbindung kann aufgebaut werden).
Deaktiviere ich die Windows Firewall wird mir Port 445 jetzt zwar angezeigt, aber als als "Filtered".
Ich habe keine weitere installierte Firewall auf dem Client gefunden. Aktuell nur die kostenlose Avira Antivirus Version und FritzFernzugang.
Egal was ich an dem Clients in der Firewall eingehend freischalte (z.b. Port 80 ), es wird über NMAP nicht als offen angezeigt.
Ich habe mich bei der Fehlersuche bisher eher auf den Windows Client konzentriert, da ja der Zugriff aus dem jeweils anderen Netz über bestimmte Ports/Dienste ja möglich ist.
Ich bin mir bei der MikroTik VPN- Konfiguration aber noch nicht 100% sicher.
Findet ihr hier noch einen Fehler? (ja, hab die Default Config nicht gelöscht und QuickSetup verwendet
)
Als Vorlage habe ich diesen Thread genommen (https://forum.mikrotik.com/viewtopic.php?t=101897)
Der Mikrotik ist wie folgt konfiguriert:
ich habe zwei Standorte über einen VPN IPSec Tunnel verbunden.
Standort A:
lokales Netz 192.168.100.0/24
VPN- Router = FritzBox 7590 mit fester öffentlicher IP (80.XXX.XXX.XXX)
Standort B:
lokales Netz 192.168.101.0/24
VPN- Router: MikroTik HEX S (6.47) hinter einer PFSense mit fester öffentlicher IP (62.XXX.XXX.XXX).
Der LAN Port (10.10.0.1) der PFsense und der WAN Port des MikroTik Routers (10.10.0.2) sind in einem Transfernetz (10.10.0.0/24). In der PFSense wurden die Ports 500, 4500 und Protokoll ESP auf die 10.10.0.2 weitergeleitet.
Ich habe das Problem, dass ich über den VPN- Tunnel nicht auf die Dateifreigabe eines Windows 7 Clients mit der 192.168.101.99 zugreifen kann. Der Zugriff per RDP ist aber möglich und ich kann über den VPN- Tunnel auch andere Dienste auf der Gegenseite erreichen (z.b. WebServer HTTP).
Bisher wurde für den Zugriff der AVM FritzFernzugang verwendet und damit ist der Zugriff auf die Dateifreigabe möglich (der VPN- Client bekommt dann eine lokale IP aus dem gleichen Netz der FritzBox 192.168.100.0/24). Freigabe und Benutzer sind somit korrekt eingerichtet und funktioniert grundsätzlich.
Ich habe im ersten Schritt eine Forward Regel (192.168.100.0/24 -> 192.168.101.0/24) eingerichtet. Außerdem habe ich die Windows Firewall Regel angepasst und bei Eingehend SMB zusätzlich zum lokalen Netzwerk noch die 192.168.100/24 eingetragen. Ausgehend habe ich das auf der anderen Seite auch kontrolliert/ erweitert.
Außerdem habe ich auf beiden Seiten bereits die Windows Firewall deaktiviert. Leider ohne Erfolg.
Ich habe dann einen Port Scan mit NMAP auf den Windows 7 Client gemacht auf den ich per SMB zugreifen will.
Port 445 ist nicht offen (Port 3389 ist offen und RDP Verbindung kann aufgebaut werden).
Deaktiviere ich die Windows Firewall wird mir Port 445 jetzt zwar angezeigt, aber als als "Filtered".
Ich habe keine weitere installierte Firewall auf dem Client gefunden. Aktuell nur die kostenlose Avira Antivirus Version und FritzFernzugang.
Egal was ich an dem Clients in der Firewall eingehend freischalte (z.b. Port 80 ), es wird über NMAP nicht als offen angezeigt.
Ich habe mich bei der Fehlersuche bisher eher auf den Windows Client konzentriert, da ja der Zugriff aus dem jeweils anderen Netz über bestimmte Ports/Dienste ja möglich ist.
Ich bin mir bei der MikroTik VPN- Konfiguration aber noch nicht 100% sicher.
Findet ihr hier noch einen Fehler? (ja, hab die Default Config nicht gelöscht und QuickSetup verwendet
)Als Vorlage habe ich diesen Thread genommen (https://forum.mikrotik.com/viewtopic.php?t=101897)
Der Mikrotik ist wie folgt konfiguriert:
# jun/14/2020 23:14:01 by RouterOS 6.47
# software id = 6TJI-NP1H
#
# model = RB760iGS
# serial number = A36
/interface bridge
add admin-mac=48:8F:5A:32:D5:1B auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec profile
add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 name=\
FritzBox nat-traversal=no
/ip ipsec peer
add address=80.XXX.XXX.XXX/32 exchange-mode=aggressive name=FritzBox passive=\
yes profile=FritzBox send-initial-contact=no
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm,3des name=FritzBox \
pfs-group=none
/ip pool
add name=default-dhcp ranges=192.168.101.10-192.168.101.100
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/port
set 0 name=serial0
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
sword,web,sniff,sensitive,api,romon,dude,tikapp"
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.101.205/24 comment=defconf interface=ether2 network=\
192.168.101.0
add address=10.10.0.2/24 interface=ether1 network=10.10.0.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server lease
add address=192.168.101.99 client-id=1:d4:85:64:6a:6d:7a mac-address=\
D4:85:64:6A:6D:7A server=defconf
/ip dhcp-server network
add address=192.168.101.0/24 comment=defconf dns-server=192.168.101.205 \
gateway=192.168.101.205 netmask=24
/ip dns
set allow-remote-requests=yes servers=10.10.0.1
/ip dns static
add address=192.168.101.205 comment=defconf name=router.lan type=A
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=accept chain=input connection-state=new dst-address=\
192.168.101.205 dst-port=80 protocol=tcp src-address=192.168.100.0/24
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Eingehend IPSec UDP 500" dst-port=500 \
protocol=udp
add action=accept chain=input comment="Eingehend IPSec UDP 4500" dst-port=\
4500 protocol=udp
add action=accept chain=input comment="Eingehend IPSec ESP" protocol=\
ipsec-esp
add action=accept chain=input comment="Eigehend IPSec AH" protocol=ipsec-ah
add action=accept chain=forward dst-address=192.168.101.0/24 log-prefix=\
"VPN Forward" src-address=192.168.100.0/24
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=accept chain=srcnat comment="Kein NAT f\FCr Pakete VPN Tunnel " \
disabled=yes dst-address=192.168.100.0/24 src-address=192.168.101.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
/ip ipsec identity
add notrack-chain=prerouting peer=FritzBox secret=\
"SECRETPASSWORTXXXXXXXXX"
/ip ipsec policy
add dst-address=192.168.100.0/24 peer=FritzBox proposal=FritzBox \
sa-dst-address=80.XXX.XXX.XXX sa-src-address=10.10.0.2 src-address=\
192.168.101.0/24 tunnel=yes
/ip route
add distance=1 gateway=10.10.0.1
/system clock
set time-zone-name=Europe/Berlin
/system logging
add disabled=yes prefix=vpn topics=ipsec
add disabled=yes prefix=Firewall topics=firewall
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
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: 579382
Url: https://administrator.de/contentid/579382
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
25 Kommentare
Neuester Kommentar
Hallo.
Hier brennt es bereits in den Augen. Die sollten keineswegs die selbe IP haben!
Zitat von @McBinz:
Zwischen dem MikroTik HEX (10.10.0.2) und der PFSense (10.10.0.2) gibt es ein Transfernetz (10.10.0.0/24).
Zwischen dem MikroTik HEX (10.10.0.2) und der PFSense (10.10.0.2) gibt es ein Transfernetz (10.10.0.0/24).
Hier brennt es bereits in den Augen. Die sollten keineswegs die selbe IP haben!
1
Moin, mir ist hier bei der Beschreibung einer kleiner Fehler unterlaufen.
Die PFsense hat im Transfernetz die 10.10.0.1 und der WAN Port des MikroTik die 10.10.0.2.
Die PFsense hat im Transfernetz die 10.10.0.1 und der WAN Port des MikroTik die 10.10.0.2.
Was hast Du denn für Betriebsysteme im Einsatz? Beides Win7 oder auch Win 10? Bei Win10 schon die Unterstützung für die SMB 1.0/CIFS-Dateifreigabe aktiviert?
Gruß
Stephan
Gruß
Stephan
Es sind noch Windows 7 Clients. Wenn sich beide im gleichen Subnetz befinden (192.168.100.0/24) dann funktioniert der Zugriff auf die Dateifreigabe. Nur aus dem anderen Netz 192.168.101.0/24 klappt der Zugriff nicht.
Mir ist außer der Windows Firewall oder Firewall Drittanbietersoftware keine andere Einstellungen unter Windows bekannt, die den Zugriff aus einem anderen Subnetz unterbinden.
Daher vermute ich, dass es doch noch an einer fehlerhaften VPN- Konfiguration des MikroTik und oder FritzBox liegen könnte. Bei der FritzBox kann ich aber nicht viel einstellen.
Mir ist außer der Windows Firewall oder Firewall Drittanbietersoftware keine andere Einstellungen unter Windows bekannt, die den Zugriff aus einem anderen Subnetz unterbinden.
Daher vermute ich, dass es doch noch an einer fehlerhaften VPN- Konfiguration des MikroTik und oder FritzBox liegen könnte. Bei der FritzBox kann ich aber nicht viel einstellen.
Mal blöd gefragt: hast Du es über IP oder Name versucht?
Mit der IP- Adresse.
Was mich stutzig macht ist die Tatsache, dass ich auf dem MikroTik -> IP -> Firewall -> Connections als Destination Adresse zwar die richtige Client IP angezeigt wird, aber als Destination Port 80. Ich erwarte hier bei Destination Address dann eigentlich Client IP:445 steht.
Wenn ich eine RDP Session auf den gleichen Client teste (was funktioniert), dann ist als Destination Address auch die Client IP mit Port 3389 angegeben.
Würde bedeuten, dass Port 445 auf 80 umgeleitet wird. Das würde ja mittels NAT geschehen, aber ich hab dafür doch keine NAT Regel definiert. In der FritzBox ist es ja nicht möglich.
Was mich stutzig macht ist die Tatsache, dass ich auf dem MikroTik -> IP -> Firewall -> Connections als Destination Adresse zwar die richtige Client IP angezeigt wird, aber als Destination Port 80. Ich erwarte hier bei Destination Address dann eigentlich Client IP:445 steht.
Wenn ich eine RDP Session auf den gleichen Client teste (was funktioniert), dann ist als Destination Address auch die Client IP mit Port 3389 angegeben.
Würde bedeuten, dass Port 445 auf 80 umgeleitet wird. Das würde ja mittels NAT geschehen, aber ich hab dafür doch keine NAT Regel definiert. In der FritzBox ist es ja nicht möglich.
Wieso ist das in der Fritte nicht möglich? Ich kann auf einer Fritzbox auch eine Portumleitung einrichten. Allerdings weiß ich, so aus dem FF, jetzt nicht, ob sich das auch auf VPN bezieht.
Erstens hast du die MASQUERADE Ausnahme für das VPN nicht aktiviert, zweitens ist das doppelte NAT hier auf dem Mikrotik hinter der Fritte überflüssig denn man sollte "Routen" dort wo es möglich ist und nur NATen wo man nicht anders kann. Eine statische Route auf der pFSense die auf den Mikrotik zeigt erledigt das dann. Und beim Zweifel beim Testen immer erst mal jegliche Firewall-Regel am Mikrotik u Client deaktivieren.
Drittens, ein VPN sollte man idealerweise immer am Perimeter terminieren und nicht erst ins Netz per Portforward reinlassen. Warum also nicht direkt an der pFSense??
Und meine erste Handlung bei Mikrotik, erst mal Default Config löschen und dann clean starten.
Drittens, ein VPN sollte man idealerweise immer am Perimeter terminieren und nicht erst ins Netz per Portforward reinlassen. Warum also nicht direkt an der pFSense??
Und meine erste Handlung bei Mikrotik, erst mal Default Config löschen und dann clean starten.
Erstens hast du die MASQUERADE Ausnahme für das VPN nicht aktiviert,
Wird auch immer und immer wieder in jedem IPsec Tutorial hier gepredigt... !!!
Die generelle Frage die sich stellt warum man das VPN auf dem VOR der Firewall kaskadierten Router enden lässt statt auf der pfSense wo es viel sinnvoller wäre. Siehe berechtigten Einwand des Kollegen @144260 oben. Das Design dieser VPN Lösung ist gruselig.
Aber egal, warum einfach machen wenn es umständlich auch geht...
Zitat von @aqui:
Die generelle Frage die sich stellt warum man das VPN auf dem VOR der Firewall kaskadierten Router enden lässt statt auf der pfSense wo es viel sinnvoller wäre.
Die generelle Frage die sich stellt warum man das VPN auf dem VOR der Firewall kaskadierten Router enden lässt statt auf der pfSense wo es viel sinnvoller wäre.
Hatte ich zuerst auch vorgeschlagen. Die PFSense wird aber von einem externen IT- Dienstleister betrieben, der darüber einen Glasfaser Internetanschluss für einen Bürokomplex mit mehreren Mietern bereitstellt.
Das war ursprünglich auch aktiviert. Habe ich jedoch auf Grund der verschiedene Tests und Fehlersuche deaktiviert. Die werde ich jetzt in jedem Fall wieder aktivieren und die SRCNAT Regel für Masquarade werde ich dann deaktivieren.
Denk aber daran das dann auf der pFSense dann eine Statische Route für dein internes Netz angelegt sein muss!!
Wenn du die nicht konfigurieren kannst/darfst musst du zwangsweise weiterhin alles (bis auf die internen Netzes des VPN) auf dem WAN-Port des MK NATen.
Wenn du die nicht konfigurieren kannst/darfst musst du zwangsweise weiterhin alles (bis auf die internen Netzes des VPN) auf dem WAN-Port des MK NATen.
Nein, die braucht er nicht, denn sein Mikrotik ist ja "hinter" der pfSense Firewall in deren lokalem Netzwerk.
Für seine Endgeräte im lokalen netz ist also der Mikrotik die zentrale Routing Instanz. Die pfSense ist komplett für den Mikrotik schon Internet, also routingtechnisch nicht relevant.
Einen fatalen Fehler gibt es aber auch zusätzlich noch in der MT Konfig des TO. Das Koppelnetz zwischen pfSense und Mikrotik ist ein RFC 1918 IP Netz, also ein privates IP Netz. Das bedingt dann das die vorgelagerte pfSense zwingend NAT ins Internet machen muss. Daraus folgt wiederum das IPsec zwingend im NAT Traversal Mode beidseitig laufen muss.
Bei der FritzBox ist NAT Traversal im IPsec immer als Default aktiviert. Der Mikrotik MUSS das also auch zwingend haben allerdings sieht man ja oben mit "add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 name=\ FritzBox nat-traversal=no " das es dort deaktivieert ist was ein Konfig Fehler ist.
Es wäre auch zudem besser, da sicherer, den MT wie die FB im IPsec Main Mode laufen zu lassen was aber nicht zwingend ist. NAT Traversal beidseitig schon.
Mit aktiver DPD würde auch bei einem Abbruch des Tunnel ein automatischer Reconnect initiiert.
Die IPsec Konfig könnte man also noch optimieren.
NAT/Masquerading im VPN Tunnel ist Blödsinn im eigenen internen Netzwerk, denn damit ist dann transparentes Routing, was du aber intern benötigst, technisch unmöglich.
Deaktiviere das also richtigerweise.
Für seine Endgeräte im lokalen netz ist also der Mikrotik die zentrale Routing Instanz. Die pfSense ist komplett für den Mikrotik schon Internet, also routingtechnisch nicht relevant.
Einen fatalen Fehler gibt es aber auch zusätzlich noch in der MT Konfig des TO. Das Koppelnetz zwischen pfSense und Mikrotik ist ein RFC 1918 IP Netz, also ein privates IP Netz. Das bedingt dann das die vorgelagerte pfSense zwingend NAT ins Internet machen muss. Daraus folgt wiederum das IPsec zwingend im NAT Traversal Mode beidseitig laufen muss.
Bei der FritzBox ist NAT Traversal im IPsec immer als Default aktiviert. Der Mikrotik MUSS das also auch zwingend haben allerdings sieht man ja oben mit "add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 name=\ FritzBox nat-traversal=no " das es dort deaktivieert ist was ein Konfig Fehler ist.
Es wäre auch zudem besser, da sicherer, den MT wie die FB im IPsec Main Mode laufen zu lassen was aber nicht zwingend ist. NAT Traversal beidseitig schon.
Mit aktiver DPD würde auch bei einem Abbruch des Tunnel ein automatischer Reconnect initiiert.
Die IPsec Konfig könnte man also noch optimieren.
NAT/Masquerading im VPN Tunnel ist Blödsinn im eigenen internen Netzwerk, denn damit ist dann transparentes Routing, was du aber intern benötigst, technisch unmöglich.
Deaktiviere das also richtigerweise.
Zitat von @aqui:
Nein, die braucht er nicht, denn sein Mikrotik ist ja "hinter" der pfSense Firewall in deren lokalem Netzwerk.
Für seine Endgeräte im lokalen netz ist also der Mikrotik die zentrale Routing Instanz. Die pfSense ist komplett für den Mikrotik schon Internet, also routingtechnisch nicht relevant.
Nein, die braucht er nicht, denn sein Mikrotik ist ja "hinter" der pfSense Firewall in deren lokalem Netzwerk.
Für seine Endgeräte im lokalen netz ist also der Mikrotik die zentrale Routing Instanz. Die pfSense ist komplett für den Mikrotik schon Internet, also routingtechnisch nicht relevant.
Das MASQUERADING am WAN des MK braucht er hier schon wenn er die Config der pfSense nicht ändern kann (oder darf) wie er sagt, denn ohne statische Route auf der pfSense kennt diese ja das Subnetz hinter dem WAN des MK nicht, weißt du ja selbst zu genüge.
Normal NATet die pfSense generell alles was sie an lokalen Interfaces hat OHNE extra Konfig per Default. Er kann den MT also auch nur als reinen Router laufen lassen was dann aber zu Recht eine statische Route erfordern würde, da hast du natürlich Recht. Sorry für die Verwirrung.
Aus Sicherheitsgründen ist es daher absolut ratsam den MT abzusichern mit NAT/Masquerading um schon generell einen Zugriff auf interne Netze am MT aus Richtung der pfSense sicher zu unterbinden. Zumal wenn dort noch andere Kunden aktiv sind, dann ist das zwingend.
Der MT WAN Port ist hier also quasi als "Internet Port" zu sehen und entsprechend abzusichern.
Hier kann man also immer die MT Default Konfig belassen und diese nur etwas anpassen. Die hat eine komplett wasserdichte Firewall mit NAT/Masquerading an ether1.
Eine Kunden spezifische Konfig auf der pfSense ist aber für ihn und sein VPN immer erforderlich, denn die pfSense muss eingehende IPsec Pakete auf den MT forwarden.
Es sei denn der MT ist immer als reiner IPsec Initiator konfiguriert, dann braucht es das Port Forwarding dort nicht. Aber dann ist NAT Traversal absolut Pflicht !
Aus Sicherheitsgründen ist es daher absolut ratsam den MT abzusichern mit NAT/Masquerading um schon generell einen Zugriff auf interne Netze am MT aus Richtung der pfSense sicher zu unterbinden. Zumal wenn dort noch andere Kunden aktiv sind, dann ist das zwingend.
Der MT WAN Port ist hier also quasi als "Internet Port" zu sehen und entsprechend abzusichern.
Hier kann man also immer die MT Default Konfig belassen und diese nur etwas anpassen. Die hat eine komplett wasserdichte Firewall mit NAT/Masquerading an ether1.
Eine Kunden spezifische Konfig auf der pfSense ist aber für ihn und sein VPN immer erforderlich, denn die pfSense muss eingehende IPsec Pakete auf den MT forwarden.
Es sei denn der MT ist immer als reiner IPsec Initiator konfiguriert, dann braucht es das Port Forwarding dort nicht. Aber dann ist NAT Traversal absolut Pflicht !
Danke für die ganzen Rückmeldungen. Ich habe NAT- Traversal auf dem MikroTik jetzt auch aktiviert
und MASQUERADE Ausnahme für das VPN aktiviert. Das MASQUERADING am WAN des MK ist weiterhin aktiv.
Anschließend habe ich über Active Peers die Verbindung gekillt, damit der Tunnel neu aufgebaut wird. Hat leider aber noch nicht geholfen.
IPSec stelle ich später noch auf MainMode um, aber damit dürfte es ja nicht zu tun haben. Kann es denn sein, dass die PFSense hier noch was rausfiltert?
add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 name=\
FritzBox nat-traversal=yesund MASQUERADE Ausnahme für das VPN aktiviert. Das MASQUERADING am WAN des MK ist weiterhin aktiv.
add action=accept chain=srcnat comment="Kein NAT f\FCr Pakete VPN Tunnel " \
disabled=no dst-address=192.168.100.0/24 src-address=192.168.101.0/24Anschließend habe ich über Active Peers die Verbindung gekillt, damit der Tunnel neu aufgebaut wird. Hat leider aber noch nicht geholfen.
IPSec stelle ich später noch auf MainMode um, aber damit dürfte es ja nicht zu tun haben. Kann es denn sein, dass die PFSense hier noch was rausfiltert?
Kann es denn sein, dass die PFSense hier noch was rausfiltert?
Nein ! Denk einmal selber etwas nach ! Der gesamte lokale Traffic zwischen den beiden lokalen LANs geht doch durch den verschlüsselten VPN Tunnel. In den kann die pfSense niemals hineinsehen und dort logischerweise dann auch nichts filtern. Würde sie am IPsec Protokoll an sich etwas filtern käme der Tunnel ja gar nicht erst zustande und somit auch keine VPN Connectivity die du ja hast !Wichtig ist natürlich das du in dem Mikrotik IPsec Policies alles an Protokollen freigegeben hast und hier keine Einschränkungen definiert hast !!
Kannst du denn alle Endgeräte gegenseitig in den beiden lokalen LANs pingen bzw. tracerouten übers VPN ??
Wenn das der Fall ist hat es nichts mehr mit dem VPN an sich oder Netzwerk an sich zu tun sondern einzig nur mit Winblows NTFS oder User Rechten ! Ein reines Windows Problem dann also.
Das man die lokale Windows Firewall (Firewall mit erweiterten Einstellungen) entsprechend customizen muss sollte auch klar sein. Die filtert generell alles weg was mit fremden IP Adressen am Rechner ankommt. Logischerweise dann auch allen Traffic des Datei- und Druckerdienstes, ICMP (Ping) usw. aus dem remoten VPN Netz.
Das musst du entsprechend anpassen das der Zugriff von diesen IP Adressen erlaubt ist.
Eine Schrotschuss Einstellung sieht so aus:
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Achte darauf !
Zitat von @aqui:
Kann es denn sein, dass die PFSense hier noch was rausfiltert?
Nein ! Denk einmal selber etwas nach ! Der gesamte lokale Traffic zwischen den beiden lokalen LANs geht doch durch den verschlüsselten VPN Tunnel.Das habe ich mir zwar auch schon gedacht, aber wenn man das Problem nicht gelöst bekommt dann geht man doch noch mal alle Optionen durch.
Wichtig ist natürlich das du in dem Mikrotik IPsec Policies alles an Protokollen freigegeben hast und hier keine Einschränkungen definiert hast !!
Ja, ist alles freigegeben.
Kannst du denn alle Endgeräte gegenseitig in den beiden lokalen LANs pingen bzw. tracerouten übers VPN ??
Ja, funktioniert beides.
Wenn das der Fall ist hat es nichts mehr mit dem VPN an sich oder Netzwerk an sich zu tun sondern einzig nur mit Winblows NTFS oder User Rechten ! Ein reines Windows Problem dann also.
Die Windows Firewall Einstellungen habe ich schon einige Male angepasst und musste ich hier in dem Fall z.b. auch für eingehend ICMP machen, damit PING über VPN funktioniert. Genauso bin ich bei Datei- und Netzwerkfreigabe auch vorgegangen.
Umgekehrt (192.168.101.0/24 -> 192.168.100/24.) funktioniert der Zugriff auf eine SMB- Freigabe Wir nehmen morgen mal einen anderen Windows Client aus dem 100er Netz und versuchen von dem aus mal auf die 192.168.101.99 zuzugreifen. Vielleicht hat der Client Rechner irgendein Problem (hab hier auch die ausgehenden Firewallregel geprüft und auch mal testweise deaktiviert).
Ich habe auf dem Client (192.168.100.28) einmal mit WireShark gesnifft. Man sieht, dass das erste Paket richtigerweise auf die richtige IP- Adresse 192.168.101.99 und Zielport 445. Es folgen dann aber weitere Pakete auf anderen Destination Ports 139 und 80. Er versucht hier auch die anderen Ports, weil die Firewall aktiv ist?
Umgekehrt (192.168.101.0/24 -> 192.168.100/24.) funktioniert der Zugriff auf eine SMB- Freigabe
Das ist dann definitiv ein reines Winblows SMB Problem. Mit dem Netzwerk selber hat es de facto hier nichts mehr zu tun. Das zeigt auch der Wireshark Trace deutlich.Die vielen Retransmission im Trace sollten dir auch zu denken geben ! Das ist nicht normal...
Mir ist nicht ganz klar, was der Mikrotik überhaupt in dem Netz macht. Wenn ich das richtig gelesen habe, hängen der Microtik und die pfSense am gleichen Standort. VPN kann aber die pfSense auch. Wozu dann also den Mikrotik? Nach meinem Dafürhalten hast Du hier eine künstliche Fehlerquelle mit eingebaut. Schon mal versucht den raus zunehmen und nur die pfSense zu nutzen?
Mir ist nicht ganz klar, was der Mikrotik überhaupt in dem Netz macht.
Der Mikrotik terminiert den IPsec VPN Tunnel der FritzBox auf der anderen Seite. Die pfSense kann er dafür nicht nehmen da diese die Internet Versorgung des gesamten Gebäudes mit einer Vielzahl anderer Kunden macht. Zudem hat er keinerlei Zugriff auf das System. Hat der TO oben erklärt.Wie gesagt: Es ist NICHT mehr das Netzwerk oder die VPN Verbindung. Nach den obigen Tests kann man das sicher ausschliessen.
Ahh. Hatte ich überlesen. Allerdings steht ganz oben:
Avira schon mal deinstalliert? Macht ab und zu Probleme.
Zitat von @McBinz:
Ich habe keine weitere installierte Firewall auf dem Client gefunden. Aktuell nur die kostenlose Avira Antivirus Version und FritzFernzugang.
Ich habe keine weitere installierte Firewall auf dem Client gefunden. Aktuell nur die kostenlose Avira Antivirus Version und FritzFernzugang.
Avira schon mal deinstalliert? Macht ab und zu Probleme.
FritzFernzugang
Und das macht erst recht so richtig Ärger!
Problem wurde gelöst und es funktioniert jetzt. Auf der FritzBox war Netbios deaktiviert und das ist jetzt wieder aktiviert worden.
Ich muss heute Abend aber noch mal genau nachfragen, weil vermutlich meinen die den NetBios Filter.
Herzlichen Dank für Eure Unterstützung!!
https://avm.de/service/fritzbox/fritzbox-7330/wissensdatenbank/publicati ....
4 NetBIOS-Filter deaktivieren
Führen Sie diese Maßnahme nur durch, wenn Sie Verbindungen über das SMB- oder CIFS-Protokoll zu Geräten im FRITZ!Box-Heimnetz herstellen wollen (z.B. um über das Internet auf Datei- und Druckerfreigaben zuzugreifen):
ACHTUNG!Die FRITZ!Box filtert die TCP- und UDP-Ports 139 und 445 ("NetBIOS-Filter"), da Computer darüber häufig angegriffen werden und diese Ports für die Kommunikation im Internet normalerweise nicht benötigt werden. Deaktivieren Sie den NetBIOS-Filter nur, wenn an allen Computern eine Firewall eingerichtet ist.
Klicken Sie in der Benutzeroberfläche der FRITZ!Box auf "Internet".
Klicken Sie im Menü "Internet" auf "Filter".
Klicken Sie auf die Registerkarte "Listen".
Deaktivieren Sie die Option "NetBIOS-Filter aktiv". Falls die Option nicht angezeigt wird, aktivieren Sie zunächst die Erweiterte Ansicht.
Klicken Sie zum Speichern der Einstellungen auf "Übernehmen".
Ich muss heute Abend aber noch mal genau nachfragen, weil vermutlich meinen die den NetBios Filter.
Herzlichen Dank für Eure Unterstützung!!
https://avm.de/service/fritzbox/fritzbox-7330/wissensdatenbank/publicati ....
4 NetBIOS-Filter deaktivieren
Führen Sie diese Maßnahme nur durch, wenn Sie Verbindungen über das SMB- oder CIFS-Protokoll zu Geräten im FRITZ!Box-Heimnetz herstellen wollen (z.B. um über das Internet auf Datei- und Druckerfreigaben zuzugreifen):
ACHTUNG!Die FRITZ!Box filtert die TCP- und UDP-Ports 139 und 445 ("NetBIOS-Filter"), da Computer darüber häufig angegriffen werden und diese Ports für die Kommunikation im Internet normalerweise nicht benötigt werden. Deaktivieren Sie den NetBIOS-Filter nur, wenn an allen Computern eine Firewall eingerichtet ist.
Klicken Sie in der Benutzeroberfläche der FRITZ!Box auf "Internet".
Klicken Sie im Menü "Internet" auf "Filter".
Klicken Sie auf die Registerkarte "Listen".
Deaktivieren Sie die Option "NetBIOS-Filter aktiv". Falls die Option nicht angezeigt wird, aktivieren Sie zunächst die Erweiterte Ansicht.
Klicken Sie zum Speichern der Einstellungen auf "Übernehmen".
Ich hoffe mal, das sich der Netbios Filter nur auf den Tunnel bezieht, ansonsten hast Du da jetzt en Scheunentor. Da kannst Du dann auch gleich noch 3389 auf machen, dann geht´s wenigstens schnell.
Zitat von @Dr.Bit:
Ich hoffe mal, das sich der Netbios Filter nur auf den Tunnel bezieht, ansonsten hast Du da jetzt en Scheunentor. Da kannst Du dann auch gleich noch 3389 auf machen, dann geht´s wenigstens schnell.
Ich hoffe mal, das sich der Netbios Filter nur auf den Tunnel bezieht, ansonsten hast Du da jetzt en Scheunentor. Da kannst Du dann auch gleich noch 3389 auf machen, dann geht´s wenigstens schnell.
Ich mache zur Sicherheit mal einen Portscan auf die öffentliche IP. Aber wenn ich in der Fritbox keine Portweiterleitung eingerichtet habe, sollte der Zugriff von außen ja so einfach auch nicht möglich sein.
