Firewall Regeln: brauche Hilfe



  • Hallo,

    ich habe eine, für mich, etwas komplizierte Konstellation aufgebaut, die fast schon funktioniert.

    Ich habe mein Netz auf Komponenten von Ubiquiti umgestellt, inkl. deren Secure Gateway (USG). Als Modem davor kommt ein Vigor 130 am Telekom VDSL 50 zum Einsatz.

    Da das Secure Gateway derzeit über die Oberfläche konfiguriert nicht so gut VPN kann habe ich eine pfSense parallel dazu eingerichtet.

    Das Netz sieht also derzeit wie folgt aus:

    Vigor 130–------USG--------------------Switch----------internes Netz
                              I                            I
                              I                            I
                                ------pfSense------

    Netze:
    USG LAN1 - intern:192.168.114.0/24
    USG LAN2 - pfense WAN: 10.0.0.0/24
    openVPN zwischen Syno und pfSense 10.0.1.0/24
    Netz des Syno: 192.168.100.0/24

    Die pfSense hat im internen LAN die 192.168.114.2

    Ich habe dort nun verschiedene VPNs eingerichtet (openVPN und IPSec) dafür wurden am USG die Ports zur pfSense weiter geleitet. Das funktioniert auch alles.

    Darüber hinaus habe ich bei einem Freund ein Synology NAS welches ich über openVPN erreichen kann. Dieses soll nun aus meinem internen LAN erreichbar werden. Und das bekomme ich nicht hin.

    Die Verbindung per openVPN Client von der pfSense zum Remote Synonolgy wird aufgebaut. Ich kann auch per Ping über das Webinterface das Synology erreichen, allerdings nur, wenn ich das openVPN Interface(Client) als Sender auswähle.

    Ich gehe davon aus, hier fehlen noch entsprechende Routen in der Firewall.

    Kann mir da jemand behilflich sein?
    Ich hoffe ich habe es verständlich genug dargestellt, und keine wichtigen Infos vergessen.

    Vielen Dank und Gruß
    Christian



  • auf Komponenten von Ubiquiti umgestellt, inkl. deren Secure Gateway (USG)
    Ein "Secure Gateway" ist die pfSense auch.  ;D  Die  Ubiquitis werden damit vielleicht aber nicht glückkich.

    Deine LAN Geräte benutzen nun das USG als Default Gateway. Demnach werden Anfragen an das Netz hinter der VPN dahin geschickt. Daran kann eine Route auf der pfSense auch nichts ändern.

    Die Route für dieses Netz müsste also direkt auf jedem LAN Gerät gesetzt werden und auf die pfSense zeigen. Viel Aufwand?
    Möglicherweise funktioniert es auch, wenn du am USG eine entsprechende Route setzt, hängt aber von dieser ab.
    Eine andere, wenn auch unschöne Lösung wäre, auf der pfSense eine zusätzliche virtuelle IP für jedes Gerät, das im anderen Netz erreicht werden soll, und ein 1:1-NAT einzurichten.



  • Hallo,

    vielen Dank für die Antwort. Ja mir ist klar, dass das USG und pfSense eine ähnliche Aufgabe verrichten.

    Mein Gedanke war zu dem was jetzt nicht fehlt wie folgt:

    Wenn ich vom LAN Port also 192.168.114.2 der pfSense das entfernte Netz erreichen kann, müsste ich meinen Clients im Netzt sagen wenn Ihr das 192.168.100 er Netz wollt fragt am 192.168.114.2 an.

    Diese Route habe ich auf dem USG auch erstellt. Meiner Meinung nach fehlt ein Schritt dazwischen, nämlich vom LAN der pfSense in das entfernte Netz (openVPN)
    Ein traceroute von einem Client im LAN zeigt, dass er am USG Gateway fragt, und dann auf das LAN der pfSense geht.

    Wie müsste diese Route/Nat Regel aussehen?
    Oder habe ich da einen Denkfehler?

    Gruß
    Christian



  • Ja, die pfSense braucht schon eine Route, aber die sollte im Zuge der OpenVPN Client Konfiguration eingerichtet worden sein. Da ist bei "IPv4 Remote Networks" das entfernte Netz anzugeben.
    Überprüfen kann man das in Diagnostic > Routes.
    Wenn da die Route eingetragen ist, muss es von der pfSense her funktionieren.

    Ob die Paket, die ins Remote Netz gehen sollen an der pfSense ankommen, kannst du ja mit "Packet Capture", auch im Diagnostic Menü überprüfen.

    Grüße



  • Eine "etwas schönere" Lösung fällt mir dazu noch ein, nachdem du die pfSense offenbar ohnehin nur für VPN-Zwecke einsetzt:
    Du könntest die pfSense nur mit einem NIC an das USG hängen und letzterem sämtliches Routing überlassen. Ich kenne das USG nicht, aber das nötige Routing und Firewalling wird es ja beherrschen.

    D.h. also auf der pfSense das LAN deaktivieren. Ich nehme an, dass das USG LAN2 auf der pfSense ohnehin bereits das Default Gateway ist, dann ist hier nichts weiter zu tun. Ansonsten dieses als GW einrichten und eine statische Route zum LAN darauf setzen. System > Routing
    Eine Firewall-Regel am WAN für die Zugriffe aufs andere Netz ist aber nötig, oder du hängst einfach das LAN auf die USG und passt die Schnittstellen-Konfig an und deaktivierst das WAN.

    Am USG musst du die Route zum Remote-Netz so ändern, dass sie auf das WAN der pfSense zeigt.
    Zusätzlich werden entsprechende Firewall-Regeln nötig sein, die den Datenverkehr erlauben.

    Damit ist das Routing aus dem LAN eindeutig: alles geht aufs USG und dieses leitet den Traffic fürs Remote-Netz an die pfSense weiter.
    Auf der pfSense ankommende Pakete fürs lokale Netz werden aufs Default GW, also die USG geschickt und die gibt sie am LAN aus.

    Diese Umstellung wirkt sich natürlich auch auf andere ggf. installierte VPN Server aus, diese müssten entsprechend angepasst werden.

    Grüße



  • Hallo,

    vielen Dank für Deine Hilfe. Ich verstehe leider noch nicht alles, und kann es demnach nicht umsetzen.

    Also aktuell hängt die pfSense noch wie beschrieben mit zwei Beinen im System.
    Ich habe jetzt mal ein Paket Capture gemacht, un zu sehen, ob für zB einen Ping auf das Remote-NAS Anfragen am LAN der pfSense ankommen:

    
    07:20:35.824532 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55575, length 8
    07:20:35.824814 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55575, length 8
    07:20:36.356546 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55576, length 8
    07:20:36.356788 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55576, length 8
    07:20:36.888567 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55577, length 8
    07:20:36.888900 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55577, length 8
    07:20:37.420536 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55578, length 8
    07:20:37.420877 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55578, length 8
    07:20:37.945551 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55579, length 8
    07:20:37.945896 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55579, length 8
    07:20:38.477536 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55580, length 8
    07:20:38.477867 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55580, length 8
    07:20:38.557929 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 0, length 64
    07:20:39.005528 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55581, length 8
    07:20:39.005932 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55581, length 8
    07:20:39.537537 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55582, length 8
    07:20:39.537864 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55582, length 8
    07:20:39.559760 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 1, length 64
    07:20:40.069534 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55583, length 8
    07:20:40.069789 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55583, length 8
    07:20:40.559717 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 2, length 64
    07:20:40.601552 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55584, length 8
    07:20:40.601941 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55584, length 8
    07:20:41.133549 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55585, length 8
    07:20:41.133967 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55585, length 8
    07:20:41.560433 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 3, length 64
    07:20:41.665548 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55586, length 8
    07:20:41.665982 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55586, length 8
    07:20:42.197569 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55587, length 8
    07:20:42.197870 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55587, length 8
    07:20:42.560497 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 4, length 64
    07:20:42.729531 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55588, length 8
    07:20:42.729837 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55588, length 8
    07:20:43.261537 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55589, length 8
    07:20:43.261773 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55589, length 8
    07:20:43.564933 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 5, length 64
    07:20:43.565005 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:43.793572 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55590, length 8
    07:20:43.793864 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55590, length 8
    07:20:44.325559 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55591, length 8
    07:20:44.325869 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55591, length 8
    07:20:44.570089 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 6, length 64
    07:20:44.570129 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:44.833644 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55592, length 8
    07:20:44.833883 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55592, length 8
    07:20:45.334930 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55593, length 8
    07:20:45.335150 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55593, length 8
    07:20:45.574857 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 7, length 64
    07:20:45.574926 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:45.836301 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55594, length 8
    07:20:45.836744 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55594, length 8
    07:20:46.338344 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55595, length 8
    07:20:46.338787 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55595, length 8
    07:20:46.579097 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 8, length 64
    07:20:46.579152 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:46.846782 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55596, length 8
    07:20:46.847055 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55596, length 8
    07:20:47.378543 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55597, length 8
    07:20:47.378920 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55597, length 8
    07:20:47.582820 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 9, length 64
    07:20:47.582858 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:47.910537 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55598, length 8
    07:20:47.910782 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55598, length 8
    07:20:48.442568 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55599, length 8
    07:20:48.443121 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55599, length 8
    07:20:48.583056 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 10, length 64
    07:20:48.583094 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:48.964547 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55600, length 8
    07:20:48.964789 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55600, length 8
    07:20:49.484279 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55601, length 8
    07:20:49.484572 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55601, length 8
    07:20:49.587812 IP 192.168.114.1 > 192.168.100.216: ICMP echo request, id 3413, seq 11, length 64
    07:20:49.587850 IP 192.168.114.2 > 192.168.114.1: ICMP host 192.168.100.216 unreachable, length 36
    07:20:49.985291 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55602, length 8
    07:20:49.985547 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55602, length 8
    07:20:50.487270 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55603, length 8
    07:20:50.487573 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55603, length 8
    07:20:50.989290 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55604, length 8
    07:20:50.989555 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55604, length 8
    07:20:51.490270 IP 192.168.100.2 > 192.168.114.1: ICMP echo request, id 19633, seq 55605, length 8
    07:20:51.490519 IP 192.168.114.1 > 192.168.100.2: ICMP echo reply, id 19633, seq 55605, length 8
    
    

    Dem ist also scheinbar so.
    Aber jetzt geht es nicht weiter. wenn ich über Diagnostics/Ping einen Ping auf das Remote-NAS sende geht dies nur wenn ich abgehend den OVPClient nehme. Verwende ich dort das LAN kommt der Ping nicht an.

    Was fehlt denn dann und wie kann ich diese Lücke schließen?

    Die Umstellung auf nur ein "Bein" im Netz würde ich sonst alternativ testen. Das ist aber ne ganze menge arbeit mit einigen Fallstricken.

    Gruß
    Christian



  • Hallo,

    wenn du eine Ausgabe des Packet Captures hier einstellst, solltest du schon Detail beschreiben, wie an welchem Interface es gemacht wurde, welches Gerät wohin eine Verbindung versucht, ob dies erfolgreich war, damit man sich nicht alles zusammenreimen braucht, was dann auch irreführend und falsch sein könnte.
    Die beiden IPs 192.168.114.1 und 192.168.100.2 wurden bislang nicht genannt. Woher sollen wir wissen, was das für Geräte sind.

    Also darf ich raten. 192.168.100.2 ist das NAS im Remote-Netz, 192.168.114.1 das LAN-IF des USG und der Ping geht demnach vom NAS zum USG und wird auch beantwortet. Wenn so, sollte dasselbe Capture am LAN und am VPN Client Interface der pfSense zu sehen sein.

    Wenn das klappt, ist aber nicht klar, weswegen ein Ping vom LAN der pfSense aufs NAS nicht funktionieren soll. Auch diese Pakete müssten mit Packet Capture am VPN Client Interface zu sehen sein, vermutlich nicht am LAN.
    Wenn das nicht funktioniert, doch obiges so, wie vermutet, gegeben ist, hat es möglicherweise ein anderes Problem.

    Grüße



  • Hallo,

    ich bitte um Entschuldigung, die beiden IP Adressen habe ich nicht genannt.
    Das Capture ist auf dem LAN der pfSense entstanden. Protocol:any, IPv4 Only)

    192.168.114.1. ist das USG bei mir im Netz
    192.168.114.2 ist das LAN der pfSense
    192.168.100.1 ist das Gateway im Netz, wo mein Remote-NAS steht. Das Remote-NAS hat die 192.168.100.216

    Warum er die 192.168.100.2 anspricht ist mir nicht klar.

    Mach ich das gleiche Capture auf dem openVPN Client Interface kommt nichts an.

    Vielen Dank für Deine Hilfe.

    Gruß
    Christian



  • Okay, dann wird es etwas klarer.
    192.168.100.2 scheint der Router im anderen Netz zu sein.
    Und vom NAS kommt keine Antwort, auch logisch, wenn nicht mal der Request durchgeht.

    Nicht klar ist mir dann aber, weswegen der Remote Router das USG anpingt, das macht er eher, wenn er die IP als Gateway eingetragen hat.

    Die Pakete müssen am OpenVPN Client Interface zu sehen sein, ansonsten liegt es an der pfSense. Du hast geschrieben, du hast mehrere VPNs darauf eingerichtet. Haben die auch alle ein Interface und ein Gateway?
    Stimmen die Routen?
    Lassen die Firewall Regeln die Pings zu?



  • Hallo,

    ich habe jetzt noch einiges recherchiert und ausprobiert. Es ist wohl nicht ohne Anpassungen an der VPN Config von dem Remote-Syno möglich.
    In diesem Artikel https://openvpn.net/index.php/open-source/documentation/howto.html#scope wird darauf eingegangen (Abschnitt Including multiple machines on the client side when using a routed VPN (dev tun))

    Ganz so kompliziert hatte ich mir das nicht vorgestellt, und ich möchte ungern die GUI Möglichkeiten verlassen, denn das ist später mal kaum nachvollziehbar.

    Zum Glück gibt es immer mehrere Wege, die nach Rom führen.
    Da es mir hauptsächlich darum geht, dass mein Synology zu Hause eine Datensicherung auf das Remote-Synology machen kann habe ich nun die VPN Verbindung auf meinem NAS zu Hause eingetragen.

    Jetzt steht der Tunnel, und auf Grund der gesetzten Parameter ist das Remote-NAS aus meinem Netz erreichbar, auch per Ping. Die statische Route im USG gäbe ich entsprechend angepasst.

    Ich bedanke mich für die Unterstützung. Ganz super.

    Viele Grüße
    Christian