OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of meyergru »
  • 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 - meyergru

Pages: [1] 2 3 ... 118
1
German - Deutsch / Re: WLAN AP - Problem mit DHCP - Client bekommt keine IP
« on: Today at 07:21:59 pm »
Also zunächst mal benötigt man keine speziellen Regeln für DHCP in den (V)LANs, es ist auch kein DHCP Relay notwendig. Das macht man nur, wenn man mehrere geroutete Netze hat, weil DHCP-Requests per Broadcast gesendet werden und man dann einen "Stellvertreter" im entfernten Netz hat (eben das DHCP Relay).

In Deinem Fall hast Du mit den Switches einen Backbone, der an den LAGG-Ports und am Port für den AP eben Trunks mit allen (V)LANs hat. Für Endgeräte schaltet man auf den Port eben die entsprechenden VLANs untagged auf. So hast Du es ja auch eingezeichnet.

Die Switches sollten natürlich managebar sein. Ich kenne den WLAN-AP nicht, ich setze selbst Unifi-APs ein, auf denen das genau so funktioniert mit 1:1-Zuordnung von VLANs auf WLANs. Offenbar kann der Netgear verschiedene Modi, auch solche, in denen er selbst DHCP macht.

Wenn er 1:1-Zuordnung kann, sollten die DHCP-Requests und -Replies der OpnSense aber durchgehen - wenn nicht, ist das Problem dort zu suchen.

2
German - Deutsch / Re: PPPOE durch Update auf 27.7.10 gebrickt?
« on: Today at 06:22:29 pm »
Ich hatte auch keine Probleme damit.

3
German - Deutsch / Re: PPPOE durch Update auf 27.7.10 gebrickt?
« on: Today at 06:08:03 pm »
Rollback auf letzten Snapshot? Oder vergessen?

4
24.7 Production Series / Re: Is my WAN IPv6 different from my /48 fixed prefix?
« on: Today at 02:55:23 pm »
Quote from: JamesFrisch on Today at 01:47:19 pm
Quote
This may pose some problems for dynamic DNS, because when your OpnSense makes a request, it goes through the WAN interface, whereas your LAN clients will even have another prefix, such that masking the EUI-64 will not suffice.

I don't understand that part to be honest  :)

If your IPv6 ranges are not static, you will have to use dynamic DNS. To update that with your current IPv6, you usually use a cnetralised approach, in that OpnSense updates the DNS name to its IP. While that works fine with IPv4 behind NAT (because all devices use the same IP), it does not with IPv6, because all devices have different IPv6s. They share a common prefix, however, so you can strip off the lower (EUI-64) part from the sender IP and attach the EUI-64 to that.

However, that obviously does not work if even the prefix is different, as is the case with IA_NA and IA_PD. Therefore, it is best NEVER to to the IA_NA in such cases.

Quote from: JamesFrisch on Today at 01:47:19 pm
Sounds good! I trying to make sense of these options and to understand the implications.
The second option seems like the sleeker way to do it. I don't need a SLAAC nor a DHCPv6 IPv6 on my WAN interface. To only real downside I can see, is that maybe then OPNsense itself is not IPv6 ready anymore and can only check for updates over IPv4?

No, as I said, it uses one of its LAN IPv6 addresses for outbound connections.

5
24.7 Production Series / Re: Is my WAN IPv6 different from my /48 fixed prefix?
« on: Today at 11:53:36 am »
Yes, the WAN IPv6 is usually from another IPv6 range than your delegated prefix.

That is because with DHCPv6, you will usually get a /128 IA_NA for your WAN and a /56 (or /48) IA_PD for prefix delegation.

This may pose some problems for dynamic DNS, because when your OpnSense makes a request, it goes through the WAN interface, whereas your LAN clients will even have another prefix, such that masking the EUI-64 will not suffice.

However, since a few versions, OpnSense has the ability to use one of your IA_PD prefixes for the WAN instead of the IA_NA address. Just set "Request prefix only", and use some "Optional prefix ID" that is different from all of your "track interface" prefixes. This way, your WAN and LAN prefixes will be the same for your delegated prefix size (i.e. less than the first 64 bits).

Another alternative is to just use "request prefix only" and leave the WAN interface completely without any IPv6 assigned. In that case, one of the LAN interface IPv6 addresses will be used for outbound connections instead.

6
General Discussion / Re: radvd | prefix length should be 64 for ix0
« on: December 02, 2024, 06:45:41 pm »
No problem, it will work like that. Any subnet will have /64 then and each has a different prefix. You only have 16 prefixes with /60 instead of 256 with /56, but that should do.
 

7
German - Deutsch / Re: HTTPS Internal Services only - Caddy, ha proxy, nginx, internal ca?
« on: December 02, 2024, 06:11:50 pm »
Ein Reverse Proxy ist dafür sinnvoll, weil er die Verschlüsselung und die Abbildung von Namen auf IPs / Backends zentral übernimmt.

Es gibt zwei Überlegungen, die man dabei anstellen sollte:

1. Will man dafür eine "echte" DNS-Domain verwenden? Dann kann man die Erzeugung der Zertifikate per ACME machen, vorzugsweise mit Wildcards. Dadurch benötigt man nur ein einziges Zertifikat, unabhängig vom Namen. Die Alternative ist eine eigene CA - allerdings gehen dabei keine Wildcards, weil neuere Browser Wildcards nicht mehr für *.xyz, sondern nur noch für *.xyz.abc akzeptieren. Jeder neue Name benötigt also ein neues (oder erweitertes) Zertifikat - was man durch entsprechendes Skripting erreichen kann. Andererseits ist der Betrieb einer CA sowieso nicht jedermanns Sache.

2. Wo sitzt der Reverse Proxy? Egal, was man dafür verwendet, falls der Proxy auf der OpnSense liegt und gleichzeitig auch "extern" erreichbare Namen bedient, muss man dafür sorgen, dass die "internen" Services nicht aus Versehen exponiert werden.
Aus diesem Grund trenne ich die externen Dienste von den internen - letztere laufen über einen Traefik, der auf einem Docker-Host betrieben wird. Das ist auch deshalb praktisch, weil die meisten Services unter Docker laufen und somit nur Annotations brauchen, um mit HTTPS ausgestattet zu werden.

8
Hardware and Performance / Re: High CPU-load
« on: December 02, 2024, 03:09:28 pm »
You will most likely see the culprit when the situation arises.

9
Hardware and Performance / Re: High CPU-load
« on: December 02, 2024, 01:10:18 pm »
I meant processes going up in usage while you have that kind of situation. I would think that excessive logging and some process that uses logs like Zenarmor, crowdsec wil then take more CPU cycles. Thus, reducing logging might fix it.

10
German - Deutsch / Re: Firewall Einstellungen
« on: December 02, 2024, 12:34:24 pm »
Zum einen verstehe ich nicht, was "VLAN" in dem Kontext heißt? Davon steht nichts in Deinem Diagramm.

Wenn es sich um das VLAN für die PPPoE-Verbindung handeln sollte, ist das komplett unnötig. Du solltest ein WAN-Interface haben, dafür brauchst Du Port-Weiterleitungen (und outbound NAT).

Im LAN wird so etwas nicht benötigt, weil der lokale Traffic die Firewall überhaupt nicht passiert. Die Geräte im LAN sprechen direkt miteinander.

11
Hardware and Performance / Re: High CPU-load
« on: December 02, 2024, 11:48:56 am »
You should probably look at "top" to find the process that is causing this. I doubt that the plain routing would cause that high load. It could be some kind of secondary cause, like Zenarmor or suricata or probably even just logging of default firewall rules.

12
German - Deutsch / Re: Firewall Einstellungen
« on: December 02, 2024, 11:26:22 am »
Deine Port-Forwards definieren zunächst nur, wie ein Zugriff von außen nach innen weitergeleitet wird. Es gibt einen Trick, damit das auch von innen funktioniert, dazu musst Du für die jeweilige Port-Forward-Regel "NAT Reflection" einschalten. Es gibt auch eine globale Einstellung dazu.

13
German - Deutsch / Re: OPNsense nach Herunterfahren und Starten erreichbar, aber nicht bei Neustart
« on: December 02, 2024, 10:07:20 am »
Es ist offensichtlich, dass in manchen Situationen das LAN Deiner OpnSense keine IP zugewiesen bekommt und deshalb nichts funktioniert. Ich kann mir nicht vorstellen, dass das mit der Erkennungsreihenfolge von USB und SSD zu tun hat - es sei denn, dass Du z.B. einen USB-Netzwerkadapter nutzt.

Solche oder auch Realtek-Adapter laufen bekanntermaßen instabil. Was für eine Hardware ist das denn?

14
24.7 Production Series / Re: Temperature: Dashboard Temps differ massively from CLI
« on: December 01, 2024, 07:42:42 pm »
I did not want to sound rude, but sometimes I wished people would actually use the forum search or the tutorial section before asking questions. For obvious reasons, this particular topic has just made it into here, as point 17.

15
24.7 Production Series / Re: Temperature: Dashboard Temps differ massively from CLI
« on: December 01, 2024, 04:31:29 pm »
Use your google-fu and you will find a ton of threads about it.

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