Messages

1

24.1 Legacy Series / IPsec NAT Rule help

« on: April 25, 2024, 07:37:08 pm »

Hello,

we do have an IPsec Tunnel that works as expected. "External" subnet 192.168.149.0/24 is linked to an internal IP 192.168.19.5. Host 192.168.19.5 must be redirected via RDP (3389) to an internal "real" host 192.168.10.8. Packets from 192.168.149.x are shown ion the foirewall Log and access to 192.168.19.5 is granted. But the RDP application stops after a timeout, so it seems as if the NAT 192.168.19.5:192.168.10.8 is not working.

Right now NAT is configured like this

NAT as portforwarding: everything that comes from interface IPsec and source 192.168.149.0/24 going to destination 192.168.19.5 port TCP/UDP 3389 NAT to 192.168.10.8 Port 3389.

Is there something that I forgot? Do we need to make the 192.168.19.5 "active"? Right now it is a "dead" IP within the NAT configuration.

2

German - Deutsch / NAT Frage IPsec

« on: April 24, 2024, 11:27:41 am »

Hallo,

ein konfigurierter IPsec Tunnel wird sauber aufgebaut. Externes Subnetz 192.168.149.0/24 wird auch sauber auf den internen Host 192.168.19.5 verknüpft. Im Firewall LOG kommen auch tatsächlich Datenpakete von 192.168.149.x an auf die 192.168.19.5.

Der 192.168.19.5 soll nun auf den "echten" Server (lediglich mit dem RDP Protokoll) mit der IP 192.168.10.8 via NAT umgeleitet werden. Genau das klappt gerade nicht wie gewünscht.

Aktuell ist das NAT so eingestellt:

NAT als Portweiterleitung: alles was von der Schnittstelle IPsec von Quelle 192.168.149.0/24 an das Ziel 192.168.19.5 Port TCP/UDP 3389 geht NAT auf 192.168.10.8 Port 3389.

Damit sollte das doch klappen...oder fehlt mir da noch was Essenzielles? Muss ggf. die 192.168.19.5 irgendwo "echt" aktiviert sein (z.B. als zweite IP auf einem internen Interface)? Aktuell ist Sie ja nur als NAT Eintrag vorhanden.

3

German - Deutsch / Frage zu NAT und IPsec

« on: January 26, 2024, 03:22:03 pm »

Hallo,

ganz einfaches Setup, aber mir fehlt aktuell die Orientierung, wenn ich versuche die Doku und meine Anforderung zu vereinen.

Verbindung Standort A zu Standort B
Standort A lediglich ein Host 192.168.1.99/32 auf Standort B Netz 10.30.22.112/28

Das hat so funktioniert. Nun kommt aber am Standort B das Subnetz 192.168.1.0/24 komplett "unter den Hammer", sprich kann nicht mehr für den Tunnel genutzt werden.

Nun soll das passieren:
Alle Pakete von 192.168.1.99/32 an 10.30.22.112 sollen die Source 192.168.7.99 erhalten.
Alle Pakete aus dem 10.30.22.112 an die 192.168.7.99 sollen nach dem Tunnel an die 192.168.1.99 gehen.

Leider habe ich das nicht in die GUI der Opnsense übersetzen können.

4

German - Deutsch / IPsec Verbindung Problem Zeit log Datei falsch, Uhrzeit aber scheinbar korrekt

« on: July 19, 2022, 04:29:53 pm »

Hallo,

merkwürdiges Problem:

IPsec Site2Site Tunnel. Phase 1 baut manchmal auf, Phase 2 nicht. In den Logs der beiden Opnsense werden komplett falsche Uhrzeiten angezeigt. Obwohl die Uhrzeit der jeweiligen Opnsense korrekt ist (Console date zeigt korrekte Zeiten an!). Woher kann so etwas kommen? Aktuellste Version OPNsense.

5

German - Deutsch / Webproxy Proxy Template ZIP Datei leer?

« on: February 22, 2022, 03:42:04 pm »

Hallo,

auf 4 Instanzen habe ich das selbe Problem: Die proxy-template.zip Datei (Webproxy Fehler, custom, download) ist leer.

6

German - Deutsch / Unbound Timeout

« on: December 21, 2020, 04:19:27 pm »

Hallo,

wir wollten Unbound auf der Opnsense nutzen zur Auflösung für die LAN Clients. Leider mussten wir auf einen externen DNS Server gehen, da Unbound aktuell keine Namen auflöst (Timeout).

LAN 192.168.2.0/24, DHCP auf der Opnsense, WAN Port der Opnsense statisch auf 192.168.3.2, Gateway 192.168.3.1 (geht leider nur im privaten Subnetz, da das WAN durch einen LTE Router bereit gestellt wird).

Ein eigentlich einfaches Setup...aber die Clients können nur am LTE Router (192.168.3.1) oder an den public DNS Server auflösen.

Unbound config:

Enabled
53
Alle Schnittstellen
DNSSEC ja
DNS64 nein
kein Weiterleitungsmodus
Zonentyp lokal: transparent
Zugriffslisten 127.0.0.1/8, 192.168.2.1/24 und 192.168.3.1/24


Lokale Ausflösung (Diagnose, DNS-Abfrage) von der Opnsense aus:

DNS-Hostname oder IP auflösen
Hostname oder IP   
www.opnsense.de
Rückmeldung   
Typ   Adresse
SOA   ns1.openprovider.nl.
Auflösungszeit pro Server   
Server   Abfragezeit
127.0.0.1   243 msec
192.168.3.1   88 msec
8.8.8.8   63 msec


Gruß

bcg

7

18.7 Legacy Series / Re: more than one IP at one interface

« on: September 28, 2018, 09:36:40 am »

Hello Matthias,

...Firewall...VirtrualIP...

Here you can add more IP-Addresses to interfaces. This works as you need it to.

8

18.7 Legacy Series / ipsec site to site

« on: September 27, 2018, 05:34:58 pm »

Hello,

sorry for maybe bothering you.

We do have an OPNsense connected directly to the internet (site a)  and another OPNsense, connected to a router that is not under our control (buliding is used by many companies with the internet access over a "LAN cable" and a private network: site b). They both have DNS names registered to the public IP (site b using a dyndns service).

site a and site b should be connected to each other. OpenVPN connects, but we have performance issues and packet sizes down to 0 with interruptions of larger file transfers. There was no solution for this (MSS, MTU...DF bit en/dis and so on).

So how can we setup ipsec between site a and site b.

9

German - Deutsch / Re: OpenSSL PtoP Verbindung über Shared KEy

« on: September 27, 2018, 09:49:07 am »

Hallo,

habe nun nochmals ein paar Kreuztest gemacht. Dazu habe ich auf den jeweiligen OPNsense Firewalls (mittlerweile 3 externe Standorte und die Zentrale) jeweils einen OpenVPN Server für die Clienteinwahl konfiguriert. An alle Standorte vom Client aus super Übertragungsraten. Sobald aber wieder zwischen den Standorten übertragen wird über den peer to peer VPN Tunnel: Abbrüche.

Also muss das Problem OpenVPN PtoP immanent sein.

Noch ein Dump von der Zentrale aus. Beobachtet wir ein Windows Explorer, der auf eine Freigabe in der Aussenstelle zugreifen will ggf. kann mir hier jemand Tips dazu geben. Interface ovpnc1

16:17:32.241552 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [P.], seq 1:179, ack 1, win 1026, length 178 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.242542 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [.], ack 179, win 123, length 0
16:17:32.269079 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [P.], seq 1:207, ack 179, win 123, length 206 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.269920 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [P.], seq 179:345, ack 207, win 1026, length 166 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.272748 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [P.], seq 207:476, ack 345, win 131, length 269 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.273190 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [P.], seq 345:906, ack 476, win 1025, length 561 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.283680 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52729: Flags [P.], seq 476:553, ack 906, win 140, length 77 SMB-over-TCP packet:(raw data or continuation?)

16:17:32.336655 IP ZENTRALE.52729 > HOSTAUSSENSTELLE.445: Flags [.], ack 553, win 1024, length 0
16:17:32.453384 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:32.665952 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:32.742814 IP ZENTRALE.986 > HOSTAUSSENSTELLE.111: Flags , seq 2801388187, win 8192, options [mss 1100,nop,wscale 8,nop,nop,sackOK], length 0
16:17:32.744237 IP HOSTAUSSENSTELLE.111 > ZENTRALE.986: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:33.095013 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:33.258400 IP ZENTRALE.986 > HOSTAUSSENSTELLE.111: Flags , seq 2801388187, win 8192, options [mss 1100,nop,nop,sackOK], length 0
16:17:33.259870 IP HOSTAUSSENSTELLE.111 > ZENTRALE.986: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:33.260101 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:33.261019 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:33.952091 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:34.070922 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:34.072397 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:35.667916 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0
16:17:35.680292 IP ZENTRALE.948 > HOSTAUSSENSTELLE.111: Flags [SEW], seq 921973020, win 8192, options [mss 1100,nop,wscale 8,nop,nop,sackOK], length 0
16:17:35.681522 IP HOSTAUSSENSTELLE.111 > ZENTRALE.948: Flags [R.], seq 0, ack 921973021, win 0, length 0
16:17:36.196003 IP ZENTRALE.948 > HOSTAUSSENSTELLE.111: Flags , seq 921973020, win 8192, options [mss 1100,nop,wscale 8,nop,nop,sackOK], length 0
16:17:36.197592 IP HOSTAUSSENSTELLE.111 > ZENTRALE.948: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:36.711463 IP ZENTRALE.948 > HOSTAUSSENSTELLE.111: Flags , seq 921973020, win 8192, options [mss 1100,nop,nop,sackOK], length 0
16:17:36.713077 IP HOSTAUSSENSTELLE.111 > ZENTRALE.948: Flags [R.], seq 0, ack 1, win 0, length 0
16:17:36.713344 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:36.714297 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:37.524031 IP ZENTRALE.927 > HOSTAUSSENSTELLE.111: UDP, length 56
16:17:37.525542 IP HOSTAUSSENSTELLE > ZENTRALE: ICMP HOSTAUSSENSTELLE udp port 111 unreachable, length 92
16:17:39.104005 IP HOSTAUSSENSTELLE.445 > ZENTRALE.52707: Flags [F.], seq 1, ack 1, win 140, length 0

10

German - Deutsch / Re: OpenSSL PtoP Verbindung über Shared KEy

« on: September 25, 2018, 04:21:25 pm »

Hallo,

das Setup ist denkbar einfach:

-Zentrale OPNsense mit zentrale.domain.de statisch mit einem privaten Backbone-Subnetz (192.168.33.0/24)
-Die Aussenstandort OPNsense (aktuell "nur" 5 an der Zahl) nutzen billig-Pappenheimer DSL Anschlüsse mit DHCP an den dort vorhandenen Routern im privaten Adressbereich. Adressbereiche Subnetze Standort: 192.168.40.0/24 bis 192.168.44.0/24)

Super hilfreich wäre für mich eine Beispielkonfiguration Serverseite-Client(bzw. Außenstandort)seite als Howto/Screenshot Doku.

Ich glaube, dass ich aktuell noch nicht entscheiden kann (mangels gewusst wie), wie ich den Zentralen Knoten aufsetze respektive die Außenstellen. Dabei kommt es mir nicht auf Firewallsettings an, sondern ganz speziell auf die Einrichtung des SSL VPN Teils.

UPDATE: ich habe nun einen Peer to Peer Tunnel eingerichtet. Der läuft auf Anhieb. Nun habe ich damit aber ein Problem: Webseitenzugriffe (z.B. Auf Webinterfaces der Geräte auf der Gegenseite klappen einwandfrei. Sobald aber Daten transferiert werden, brechen die Transfers ab. SMB/HTTP Upload. Egal mit welchem Protokoll. Größere Datenmengen können nicht überrtagen werden. Lokale Zugriff auf der Zentrale (OPNsens auf die Server dort) laufen einwandfrei. Auch am "Außenstandort" ist das LAN und die Performance gut. Aber alles was über den Tunnel geht: miserabel bis Abbruch. Manchmal startet ein Filetransfer, manchmal gar nicht. TCP WindowSize?

19:36:38.067697 IP LANZENTRALE.61243 > LANAUSSENSTELLE.microsoft-ds: Flags [P.], seq 179:345, ack 207, win 1026, length 166 SMB-over-TCP packet:(raw data or continuation?)

11

German - Deutsch / Re: OpenSSL PtoP Verbindung über Shared KEy

« on: September 21, 2018, 03:44:08 pm »

Hallo,

vielen Dank für die erste Antwort.

Um hier nicht noch mehr durcheinander zu werfen die Anforderung:

Viele OPNsense-Standorte müssen untereinander vernetzt werden. Dabei müssen Daten nur zu einer zentralen OPNsense übermittelt werden können.

Für mich als Neuling wäre es super, wenn ich eine Art Tutorial oder kleines HowTo bekommen könnte. Wie richtige ich die Zentrale ein, wie die "Aussenstellen". OpenVPN wäre hierbei die Voraussetzung, da bedingt durch NAT in den Außenstellen kein IPsec Tunnel anzuwenden ist.

Zentrale OPNsense: was muss wie eingerichtet werden
Außenstellen OPNsense: wie ist hier der OpenVPN Teil einzurichten.
->Tolle wäre eine einfache und gut kopierbare Außenstellenkonfiguration...

Vielen Dank vorab für Tips!

12

German - Deutsch / Re: OpenSSL PtoP Verbindung über Shared KEy

« on: September 18, 2018, 06:00:01 pm »

Hallo,

ist meine Idee nicht umsetzbar?

Ich versuche es nochmals zu beschreiben, für den Fall, dass meine vorherigen Versuche etwas zu verwirrend sind:

OPNsense SSL-VPN Server in der Zentrale. Dort wählen sich nun viele anderen OPNsense Firewalls "ein". IPsec kann leider nicht genutzt werden, da es ggf. private Subnetze mit NAT usw. zwischen den externen OPENsens Instanzen gaben kann. Auch ist die peer to peer Variante der OpenVPN Verbindung nicht ideal, da ich nur einen bestimmten Port zum Verbindungsaufbau verwenden kann..somit sollte das wie beim VPN Client über einen Port zum Server hin möglich sein.

Oder gibt es hier eine elegantere Lösung? Zerotier war von der Performance her zu schlecht.

13

18.7 Legacy Series / Several Sites via OpenSSL VPN

« on: September 16, 2018, 08:48:06 pm »

Hello,

I know how to setup OpenSSL VPN Server for single PtoP connection (Shared Key) and OpenVPN for RoadWarriors. But how to do this:

-One OPNsense OpenSSL VPN Server central

-Many OPNsense Installations connecting to this Central without using explicit peer to peer connections, but by usin username and password for example to connect to the same opened port?

14

German - Deutsch / Re: OpenSSL PtoP Verbindung über Shared KEy

« on: September 16, 2018, 10:28:23 am »

UPDATE:

Das was ich mit der PtoP Verbindung vorhabe scheint nicht wirklich so zu funktionieren. Darum die Frage: wie wird ein Client auf der OPNsense denn zu einem "RoadWarrior" Seerver verbunden bzw., wie ist der einzurichten?

Aufgabenstellung: viele OPNsense Firewalls verbinden sich auf eine zentrale Instanz, analog einem VPN Softwareclient. Die Unterscheidung wird dabei über den Usernamen/Passwort geregelt.

Den Server einzurichten ist dabei nicht das Problem, sondern die "Client-Seite" auf den externen OPNsense Instanzen: da hapert es gerade (CA/Zertifikate/Keys von wo nach wo...usw.)

15

German - Deutsch / OpenSSL PtoP Verbindung über Shared KEy

« on: September 15, 2018, 09:17:30 pm »

Hallo,

ich habe einen OpenSSL Server angelegt, auf den per shared key von außen verbunden wird. Ein Client (eine andere OPNsense) verbindet sich schon drauf. Jetzt würde ich gerne eine weitere OPNsense verbinden lassen. Geht das überhaupt? Die Pool IP ist bei beiden Clients die selbe...das sieht so aktuell nicht gut aus. Darum die Frage:


Standortvernetzung über OpenVPN mit shared key (da einfach zu konfigurieren auf der Clientseite) von mehreren Standorten aus auf den Server parallel einrichtbar?