Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst OPNsense IPSec NAT Problem

Mitglied: SomebodyToLove

SomebodyToLove (Level 1) - Jetzt verbinden

03.01.2019, aktualisiert 10:56 Uhr, 277 Aufrufe, 7 Kommentare, 4 Danke

Hallo,

ich bin aktuell am verzweifeln mit meiner VPN IPSec Konfiguration.

Ich bekomme einfach keinen Ping auf die Gegenseite hin, der Ping auf meinen Server (RDS) läuft nur gelegentlich....
Meine Hoffnung ist das mir hier jemand etwas Licht ins Dunkel bringen kann und mal meine Konfiguration zu checken ob ich einen groben Denkfehler drinnen habe.
Der IPSec Tunnel lässt sich auf jeden Fall schon mal aufbauen, deshalb denke ich das Phase 1 und Phase 2 soweit korrekt sein sollten.

Die Herausforderung dabei ist das mein eigentliches Netz beim Lieferanten schon belegt ist.
Eigentlich benötigen wir "nur" RDP Verbindungen vom Lieferanten auf unseren RDS und Druckjobs von uns zum Lieferanten.

Aktuell ist das Netzwerk so aufgebaut:

01.
+------------------------+                 +---------------------------+             +-------------------------------+
02.
|   Standort Lieferant   |                 |    Interner Drucker       |             |    Tatsächliche Drucker IP    |
03.
|                        |-----------------|                           |-------------|                               |
04.
|   22.22.22.22          |                 |    10.10.10.11/22         |             |    199.144.231.25/22          |
05.
+------------------------+                 +---------------------------+             +-------------------------------+
06.
            |         |                                                                                               
07.
            |         |                                                                +-----------------------------+
08.
            |         |                                                                |    Clients via RDP auf RDS  |
09.
            |         +----------------------------------------------------------------|                             |
10.
            |                                                                          |    XXX.XXX.XXX.XXX          |
11.
            |                                                                          +-----------------------------+
12.
            |                                                                                                         
13.
            |                                                                                                         
14.
+--------------------------+                +----------------------------+                                            
15.
|    Firmenstandort        |                |  Fake Netzwerk             |                                            
16.
|                          |----------------|                            |                                            
17.
|    WAN 44.44.44.44       |                |  192.168.55.0/24           |                                            
18.
+--------------------------+                +----------------------------+                                            
19.
                                                            |                                                         
20.
                                                            |                                                         
21.
                                                            |                                                         
22.
                                                            |                                                         
23.
                                                            |                                                         
24.
                                                            |                                                         
25.
                                             +----------------------------+                                           
26.
                          -                  |    Remote Desktop Server   |                                           
27.
                                             |                            |                                           
28.
                                             |        192.168.11.55       |                                           
29.
                                             |                            |                                           
30.
                                             +----------------------------+                                           
Auf unserer OPNSense habe ich die Einstellungen vorgenommen wie in diesem Artikel beschrieben:

https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-binat.html

Ich habe unter SPD in der Phase2 meine "richtige" LAN IP eingetragen 192.168.11.0/24

Unter One to One NAT habe ich folgendes konfiguriert:

opnsense-nat - Klicke auf das Bild, um es zu vergrößern

Aber ich bekomme einfach keinen Ping auf die Drucker an der Gegenseite.

Kann mir jemand sagen was ich an meiner Konfiguration falsch gemacht habe?

Aktuell bin ich schon zwei Wochen am Verzweifeln und bekomme es einfach nicht hin.

Meine Vermutung ist das ich beim NAT etwas grundlegendes Falsch mache.

Ich wäre für jede Antwort dankbar.

Vielen Dank.

Beste Grüße
Somebody
Mitglied: aqui
LÖSUNG 03.01.2019, aktualisiert um 15:07 Uhr
ich bin aktuell am verzweifeln mit meiner VPN IPSec Konfiguration.
Warum ??
Hier:
https://administrator.de/wissen/ipsec-vpn-mobile-benutzer-pfsense-firewa ... (Mobile User)
oder auch hier:
https://administrator.de/wissen/ipsec-vpn-praxis-standort-kopplung-cisco ... (Site to Site)
findest du doch Lösungen die du nur noch abtippen musst ?!

Wenn der Tunnel soweit sauber hochkommt, dann stimmen zu 98% deine Firewall Regeln nicht. Checke das !
Besonders hilft oft ein Blick in das Firewall Log was da geblockt wird.
Ping ist das ICMP Protokoll was du freigeben musst sowohl auf dem IPsec Tunnel Interface als auch den beteiligten LAN Interfaces beider Seiten. Hast du das beachtet.

Sinn macht es erstmal in den Firewall Regeln auf diesen Adaptern gesamt die IP Netze freizugeben, dann filterst du nicht Protokoll spezifisch, was das Troubleshootimng erheblich erleichtert.
Beim NAT kann man nichts falsch machen, das macht die pfSense automatisch und da muss man nix fummeln.
Im Tunnel macht man natürlich kein NAT ! Was aber eh Default ist !
Wie gesagt...der Fehler liegt mit 98%ider Wahrscheinlichkeit in falschen Firewall Regeln !
Nur nochmal als Erinnerung. Für die Regeln gelten folgende feste Grundregeln:
  • Traffic wird nur inbound (eingehend) gefiltert. Also alles was IN das Interface reinkommt von außen.
  • "First match wins" !! Der erste positive Hit in einer Regel bewirkt das nachfolgende Regeln NICHT mehr abgearbeitet werden. Beachte das ! Reihenfolge zählt hier also im Regelwerk !
Bitte warten ..
Mitglied: SomebodyToLove
03.01.2019 um 14:14 Uhr
Hallo aqui,

vielen Dank für deine Antwort und deinen verlinkten Artikeln, die hast du wirklich sehr sauber verfasst.

So wie ich bisher alles verstanden habe benötige ich NAT weil ich ja quasi ein "Zwischen Netz" habe.

Also mein Originales Netz hat die 192.168.11.0 dieses Netz ist aber bei unserem Lieferanten gegenüber schon belegt, weshalb er den VPN Tunnel auf ein anderes Netz gelegt hat 192.168.55.0

Jetzt muss ich doch meinem Router sagen das die Pakete welche von meinem "Original Netz (192.168.11.0)" auf das Netzwerk unseres Lieferanten (199.144.231.25/22) geschickt werden über das "Fake Netz (192.168.55.0)" geschickt werden, damit diese bei ihm richtig ankommen und er diese wieder entsprechend zu seinen Druckern weiter schicken kann.

Und dazu benötige ich doch dann NAT?

Die Firewall Rules habe ich wie folg eingestellt:

firewallrules - Klicke auf das Bild, um es zu vergrößern

Also quasi ALL ALL ALL

Ich überprüfe jetzt nochmal Anhand deiner Links meine config, vielleicht fällt mir ja noch etwas auf.

Deiner Ansicht nach dürfte ich überhaupt keine manuellen NAT Einstellungen benötigen?

Tausend Dank nochmal für die nächsten Denkanstöße!

Beste Grüße
Somebody
Bitte warten ..
Mitglied: aqui
LÖSUNG 03.01.2019, aktualisiert um 15:15 Uhr
So wie ich bisher alles verstanden habe benötige ich NAT
Das kommt auf die Sichtweise an !
NAT zum Internat ja ! Klar, denn da werden RFC 1918 IPs nicht geroutet
NAT im VPN Tunnel NEIN !
Sprich aller Traffic der in den VPN Tunnel geht darf NICHT geNATet werden. Logisch, denn sonst schaffst du dir in deinen internen Netzen eine Einbahnstrasse durch die NAT Firewall.
Aber letztlich brauchst du dich darum nicht zu kümmern, denn die pfSense macht grundsärtzlich kein NAT im VPN Tunnel. Es sei denn man konfiguriert das explizit, was aber kein normaler Netzwerker macht.
Oha....sorry, sehe gerade gleiche IP Netze auf beiden Seiten
Also mein Originales Netz hat die 192.168.11.0 dieses Netz ist aber bei unserem Lieferanten gegenüber schon belegt,
Das ist großer Schei... Ein IP Adress Designfehler !
Siehe dazu auch hier:
https://administrator.de/wissen/vpns-einrichten-pptp-117700.html#toc-7

Wenn irgend möglich solltest du dein Netz oder das gegenüber liegende auf eine andere IP Adresse umstellen.
Das wird dir die VPN Konfig erheblich erleichtern. Ohne das musst du ein Source und Destination NAT machen zwangsweise was die VPN Konfig unnötig verkompliziert und fast unmanagebar macht.
Ein IP Adressumstellung, sofern machbar, ist da das weitaus kleinere Übel.
Geht das partout nicht, dann hast du Recht, dann must du zwangsweise NATen im Tunnel was gruselig ist.
Und zwar sowohl Source als auch Destination NAT !!
Bitte warten ..
Mitglied: SomebodyToLove
04.01.2019 um 09:18 Uhr
Hallo aqui,

vielen Dank für deine Antwort.

Ich habe jetzt Testweise mal meinen PC auf die "Fake IP" gestellt, also 192.168.55.55 und habe alle NAT Regeln wieder deaktiviert.

In diesem Szenario sollte ich ja die gegenstelle pingen können oder?

Leider klappt selbst so der Ping nicht auf den Drucker im anderem Netzwerk, heißt das jetzt das da an der Gegenseite noch etwas falsch konfiguriet ist oder denkst du das ich noch etwas übersehen habe?

Phase 1 und 2 sind nach wie vor verbunden und unter Inbound / Outbound Traffic sehe ich auch das Traffic über den Tunnel läuft.

Unter der Traffic Analyse sehe ich wenn ich meinen Ping auf den Drucker starte (Traffic geht nach oben) also wandern die Pakete auch in den Tunnel.

Kennst du vielleicht noch andere Hilfsmittel für eine detailliertere Analyse?

Vielleicht hast du ja auch noch einen Ansatz für mich wie ich bei dem Problem noch weiter kommen könnte. Den Lieferanten habe ich bereits angeschrieben das er nochmal checken soll das ICMP auf den Drucker auch tatsächlich erlaubt ist.

Vielen Dank schon mal
Somebody
Bitte warten ..
Mitglied: aqui
LÖSUNG 04.01.2019, aktualisiert um 12:38 Uhr
In diesem Szenario sollte ich ja die gegenstelle pingen können oder?
Ja, aber dann solltest du auch eine saubere VPN Konfig aufsetzen und das gesamte NAT entfernen.
Leider klappt selbst so der Ping nicht auf den Drucker im anderem Netzwerk
Kannst du denn das lokale LAN Interface der FW in dem sich der Drucker befindet bzw. dessen IP pingen.
Wenn das geht, dann ist der übliche Fehler das für den Drucker vergessen wurde eine Gateway IP einzurichten !
Der klassische Fehler bei Druckern in segmentierten Netzen, dann können die natürlich andere IP Netze niemals erreichen ohne Gateway.
Diese IP sollte natürlich dann auch auf deine VPN FW zeigen. Oder...sollte das ein anderer Router sein, dieser dann eine statische Route auf das VPN Gateway eingetragen haben.
Traceroute (tracert bei Winblows) ist hier dann wieder dein bester Freund um die Routing Hops sichtbar zu machen !
Kennst du vielleicht noch andere Hilfsmittel für eine detailliertere Analyse?
Na klar... Der Klassiker ! Ganz einfach:
Statt des Druckers mal einen Laptop mit Wireshark der die gleiche IP hat wie der Drucker ins Netzwerk klemmen (Drucker natürlich abziehen)
Dann siehst du die eingehenden Ping Pakete (ICMP Echo Request) und wenn der Test Laptop dann seinerseits eine Gateway eingerichtet hat dann siehst du auch seine Antwort auf den Ping (ICMP Echo Reply).
Das zeigt dann das alles sauber rennt, das VPN funktioniert und der Drucker eine fehlende Gateway IP hat !
Drucker Netzwerk Interfaces supporten in der Regel immer ICMP (Pings) sogar bei den allerbilligsten Teilen vom Blödmarkt.
Nur...das Gateway muss natürlich auch stimmen
Bitte warten ..
Mitglied: SomebodyToLove
09.01.2019 um 14:39 Uhr
Hallo aqui,

vielen Dank für deine Tipps.

Ich habe es jetzt endlich hinbekommen.

Falls jemand so am verzweifeln ist wie ich, möchte ich hier noch kurz die Lösung zu meinen Problem schildern:

Also erstes Problem war, das trotz mehrfachem Nachfragen kein ICMP auf der Gegenseite konfiguriert bzw. erlaubt war.... #feelsbad

Gut nach dem dieses SICHER konfiguriert war konnte ich mit meinen Tests fortfahren.

Meine BINAT Einstellungen habe ich wie folgt konfiguriert:

Um bei meinem Beispiel zu bleiben:

Request läuft über: WAN 44.44.44.44
Sollte aber über: (192.168.11.55 Remote Desktop Server) ->192.168.55.55

Meine aktuelle One-to-One NAT Regel sieht wie folgt aus:

Interface: IPSec
Type: BINAT
External network: 192.168.55.0/24
Source: 192.168.11.0/24
Destination: 199.144.231.0/22

Danach hatte der Ping hin gehauen und die Gegenseite konnte sich via RDP auf meinen Terminalserver verbinden.

Nur leider habe ich immer noch nicht die Drucker erreicht. Ping ging gelegentlich, ist aber immer wieder abgebrochen.
Als ich mit dem Firewall Admin der Gegenseite telefoniert hatte sind wir durch die Logs gegangen. Wir haben erkannt das meine Firewall mit der WAN IP den Request stellt, die Firewall aber logischerweise meine interne LAN IP erwartet und deshalb meine Anfragen dropt.

Jetzt habe ich nochmal etwas in den Settings gesucht und bin letzten Endes drauf gekommen das ich zusätzlich Outbound NAT konfigurieren muss.

Folgende Settings unter Outbound NAT waren dann der Schlüssel zum Erfolg:

Interface: WAN

Source: 192.168.11.55
Port: any

Destination: 199.144.231.25
Port: any

Translation: 192.168.55.55/32

Ich habe in meinem Fall jetzt jeden Drucker einzeln hinzugefügt, waren nur 5, da ich mir mit den unterschiedlichen Subnetzen unsicher war ob es die Firewall sauber hin bekommt.

Jetzt läuft es auf jeden Fall und ich bin über glücklich.

Vielen Dank nochmal für die Unterstützung aqui.

Beste Grüße
Somebody
Bitte warten ..
Mitglied: aqui
09.01.2019, aktualisiert um 15:44 Uhr
Glückwunsch !
möchte ich hier noch kurz die Lösung zu meinen Problem schildern:
Dank für dein Feedback. Das hilft ganz sicher auch Anderen mit gleicher Problematik hier !
Obwohl der Grund ein lax und fehlerhaft designtes VPN IP Adress Konzept ist. Man kann nur jeden Leser ermutigen sowas VORHER zu bedenken und entsprechend exotischere IP Adressierungen für die lokalen LANs zu verwenden damit man solche Anpassungen nicht später machen muss um das wieder hinzubiegen.

Case closed !
Bitte warten ..
Ähnliche Inhalte
LAN, WAN, Wireless
PfSense: NAT vor IPSEC?
gelöst Frage von Fenris14LAN, WAN, Wireless12 Kommentare

Guten Tag, mal ne kleine Frage. Ich versuche folgendes umzusetzen: Client hinter einer pfSense => Soll Anfrage an virtuelle ...

Netzwerkgrundlagen

IPSec Site-to-Site über NAT ohne Portforwarding

Frage von BirdyBNetzwerkgrundlagen18 Kommentare

Hallo miteinander, ich habe da mal eine Frage: In unserem Hauptstandort gibt es eine Sophos UTM mit fester IP. ...

Router & Routing

Mikrotik CCR1036 IPSec UDP NAT Abbrüche PCoIP VDI

gelöst Frage von nahdekaRouter & Routing2 Kommentare

Hallo, ich betreibe ein VPN,, IPSec ESP'' das i.d.R. störungsfrei den lokalen Windows Clients über den VMWare Horizon Client ...

Firewall

IPSec VPN IKEv2 mit Zywall VPN Client hinter NAT - falscher DNS?

gelöst Frage von KodaCHFirewall5 Kommentare

Guten Morgen Ich habe mich daran versucht eine VPN Verbindung mit einer ZyWall zu erstellen. Dies ist Primär nicht ...

Neue Wissensbeiträge
Windows Mobile

Support für Windows Mobile endet im Dezember 2019

Information von transocean vor 22 StundenWindows Mobile

Moin, Microsoft empfiehlt als Alternative den Umstieg auf iOS oder Android, wie man hier lesen kann. Gruß Uwe

Internet

Kommentar: Bundesregierung erwägt Ausschluss von Huawei im 5G-Netz - Unsere Presse wird immer sensationsgieriger

Information von Frank vor 2 TagenInternet5 Kommentare

Hier mal wieder ein schönes Beispiel für fehlgeleiteten Journalismus und Politik zugleich. Da werden aus Gerüchten plötzlich Fakten, da ...

Windows 10

Netzwerk-Bug in allen Windows 10-Versionen durch Januar 2019-Updates

Information von kgborn vor 3 TagenWindows 101 Kommentar

Nur ein kurzer Hinweis für Admins, die Windows 10-Clients im Portfolio haben. Mit den Updates vom 8. Januar 2019 ...

Windows 10

Windows 10 V1809: Rollout ist gestartet - kommt per Windows Update

Information von kgborn vor 3 TagenWindows 102 Kommentare

Eine kurze Information für die Admins, die Windows 10 im Programm haben. Microsoft hat die letzte Baustelle (die Inkompatibilität ...

Heiß diskutierte Inhalte
DNS
SFTP über DynDNS nicht OK - über ext. IP funktioniert es
gelöst Frage von C.MorgensternDNS10 Kommentare

Hallo zusammen! Ich habe Probleme beim SFTP Zugriff auf eine Linux Maschine vom WAN aus über eine DynDNS Adresse. ...

Netzwerkmanagement
Server bauen
Frage von JugendringNetzwerkmanagement10 Kommentare

Moin Moin, wir, der Jugendring sind ein ständig wachsender Verein mit vielen Unterprojekten. Da liegt es nah, dass wir ...

E-Mail
Rechtssichere Archivierung von emails
Frage von gerd33E-Mail9 Kommentare

Hallo zusammen, bin gerade dabei, eine revisions- und rechtsichere email-archivierung aucf meinem Server zu projektieren. Da eigentlich nur ich ...

Off Topic
Darf ich ein Forum erstellen das Produkte eines Herstellers betrifft?
Frage von cyberwallOff Topic9 Kommentare

Hallo Community, ich habe da eine "rechtliche" bzw. allgemeine Frage zum erstellen von Foren. Darf ich als "normale Person" ...