OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of Gauss23 »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Messages - Gauss23

Pages: 1 2 [3] 4 5 ... 49
31
German - Deutsch / Re: Endlich läuft das Ding .. ABER
« on: February 22, 2021, 07:41:42 am »
Du brauchst in jedem Fall eine Firewall Regel auf dem Interface, von wo Du Zugriffe auf diesen nginx oder HAProxy  zulassen willst.

32
21.1 Production Series / Re: OpenVPN Site to Site pc's not pinging
« on: February 21, 2021, 10:18:33 pm »
Please share a screenshot of OpenVPN server config

33
German - Deutsch / Re: Firewall rule Verwendung
« on: February 21, 2021, 05:54:18 pm »
Wann geht nicht aber wie oft schon:
in der Ansicht der Regeln für ein Interface oben auf "Inspect" klicken. Dann sieht man wie oft die Regel angewandt wurde. Leider gehen die Counter immer wieder auf 0 wenn man eine Kleinigkeit ändert an den Regeln. Ist also nur aussagekräftig, wenn man ne Weile keine Regeländerungen vorgenommen hat.

34
German - Deutsch / Re: NAT funktioniert nicht mehr
« on: February 21, 2021, 05:50:41 pm »
Den Hintergrund warum das nicht funktioniert, verstehst Du aber? Die Anfragen kommen aus dem LAN und gehen wieder ins selbe LAN. Die OPNsense muss also die Source Adresse umschreiben, damit der Gitea Server seine Antwort an die OPNsense sendet. Du könntest mal schauen, ob Du die Requests am Gitea Server siehst. Du solltest die Source Adresse von der OPNsense sehen. Wenn da die IP vom LAN Gerät drin ist, ist es falsch. Wäre ein erster Schritt, um zu erfahren, was die OPNsense da mit dem Paket so anstellt. Oder mal ein TCPdump auf der OPNsense während eines solchen Zugriffs mitschneiden.

Als härteste Maßnahme: Du könntest den Gitea Server in ein eigenes VLAN packen. Dann braucht es kein Reflection Zeug.

35
German - Deutsch / Re: NAT funktioniert nicht mehr
« on: February 21, 2021, 09:44:33 am »
Quote from: macalloy on February 19, 2021, 09:20:39 pm
D.h. Zugriff mit dem DynDNS Namen; es funktioniert nur noch direkt die IP adresse (bzw. LAN interner Name).

Nur zur Sicherheit. Der DynDNS Name wird aber noch mit der richtigen IP aktualisiert? Das hast Du überprüft?
Und mit welcher IP Adresse funktioniert es? Die interne oder kannst Du auch die WAN IP nehmen?

36
German - Deutsch / Re: User basierte Firewall Regeln für OpenVPN
« on: February 19, 2021, 04:43:19 pm »
Quote from: lewald on February 19, 2021, 04:32:43 pm
Würde das in Client Override nicht mit  IPv4 Local Network gehen?

Da kannste ja pro Client sagen welche netze oder Hosts erreichbar sein sollen.

Ja, ginge vermutlich auch. Wenn er das aber feiner justieren will, wie z.B. nur auf den Fileserver per CIFS in dem einen Netz, dann muss er das mit FW Regeln lösen.

37
German - Deutsch / Re: User basierte Firewall Regeln für OpenVPN
« on: February 19, 2021, 04:27:50 pm »
Ich fürchte nicht.

Du kannst Aliasse anlegen und somit bestimmte Nutzer gruppieren, um nicht viele einzelne FW Regeln zu haben, sondern das etwas zu strukturieren. Das müsste man ja auch nur für Benutzer machen, die spezielle Berechtigungen brauchen.

Alternativ kannst Du auch weitere OpenVPN Server anlegen und darüber die Berechtigungen regeln. Jeder OpenVPN Server hat dann seinen eigenen IP-Bereich.

38
German - Deutsch / Re: WireGuard VPN, kein Surfen
« on: February 19, 2021, 01:41:58 pm »
Ich nehme immer die Invert-Variante. Man gewöhnt sich dran :)

39
German - Deutsch / Re: WireGuard VPN, kein Surfen
« on: February 19, 2021, 10:46:10 am »
Na du musst das WireGuard Netz in die Outbound NAT Regel hinzufügen.

Outbound NAT -> auf dem WAN Interface, Source sind die lokalen Netze (eben dann inkl Wireguard) und los.

40
21.1 Production Series / Re: tls-crypt fails from opnsense openvpn client, but work from other clients
« on: February 19, 2021, 10:43:48 am »
Quote from: geoher on February 19, 2021, 10:37:55 am
Thak's for your reply!

It looks like opnsense does not support tls-crypt, but rather the older tls-auth.
I needed to change to tls-auth on my openvpn server to be compliant with the openvpn client on opnsense.
As usual, hours spent looking for a 5 sec fix

Still protected, but more vulnerable to unfriendly hammering.

How do I mark this as "solved"?

Regards, GeoHer

Did you read my answer? I gave the correct hint to bring tls-crypt up and running. No need to switch to tls-auth.

Disable the checkbox in the GUI for TLS-auth and add the tls-crypt key in the advanced/custom settings box on the same page. Like in my last answer.

41
21.1 Production Series / Re: Rule not taking effect
« on: February 18, 2021, 09:00:27 pm »
The problem is not in the OPNsense as far as I can see. It’s the way from 10.8.0.2 to 172.25.25.11 you need to check.  You need to make sure that the packets are going through your OPNsense in both directions

42
German - Deutsch / Re: Logging - Live View
« on: February 18, 2021, 08:46:26 pm »
Grätscht Dir da evtl eine Regel rein, die den Gateway umbiegt?
Du hast logging auf ALLEN Regeln an?

43
German - Deutsch / Re: Logging - Live View
« on: February 18, 2021, 08:41:36 pm »
Im Live-View sieht man jeweils nur einen Verbindungsversuch. Wenn er der Client dann ewig auf Timeout wartet, sieht man nichts neues.
Ich richte mir im Live View einfach einen Filter ein, alle Auto-Refresh an und wähle einfach 500 Zeilen aus. Dann sehe ich meistens auch die gescheiterten Versuche.
Sonst wüsste ich nicht, warum Du da nichts sehen solltest.

44
21.1 Production Series / Re: Download button is opening a webpage with text of ISO.
« on: February 18, 2021, 08:33:38 pm »
Just a normal left-click. Download starts with the correct filename to my download folder.

45
21.1 Production Series / Re: Rule not taking effect
« on: February 18, 2021, 08:31:36 pm »
I think we have a case of asymmetric routing here.
On your last screenshot you see traffic coming from port 3389 (RDP) to a high port on 10.8.0.2. What you see are the responses of the RDP server. Usually those packets are covered by the state from the opening packet going FROM 10.8.0.2 to 172.25.25.11.
What I think is: the packets are going another way FROM 10.8.0.2 TO 172.25.25.11. The OPNsense is blocking those packets because they claim to be an established connection but your OPNsense does not have a state saved for it.

You need to check the routing. Packets need to take the same way in both directions.

Pages: 1 2 [3] 4 5 ... 49
OPNsense is an OSS project © Deciso B.V. 2015 - 2021 All rights reserved
  • SMF 2.0.18 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2