"Recent posts
#1
German - Deutsch / Re: Neues setup - Fragen zur S...
Last post by meyergru - Today at 11:54:45 AMMit der geringen Info, die Du geliefert hast, sind nur prinzipielle Antworten möglich, nichts konkretes:
1. Natürlich kannst Du das getan haben, das meiste spielt sich allerdings im Firewall-Bereich ab.
2. Jein. Es sind nicht nur WAN-Regeln, sondern z.B. auch NAT.
3. Ja, absolut und ja. Da IPv6 kein NAT benötigt, reicht ein falsches "Allow Any" in den WAN- (oder Floating-) Regeln aus.
4. Ja, sollten sie, sonst brauchst Du ja keine VLANs. Und genau da spielt ggf. auch IPv6 rein, denn jetzt müssen die Pakete eben nicht mehr über das WAN reinkommen.
5. Richtig. Das gilt für die übliche "Allow Any"-Regeln bei IPv4.
6. Ob man das mit einer Regel und invertiertem Ziel oder mit zwei Regeln (eine mit Block RFC1918 und eine mit Allow Any) macht, ist Geschmackssache. Über VLAN-Abschottung auf Ebene IPv6 habe ich noch nicht nachgedacht, denn den Bereich ist zu groß, um ihn zu scannen. Das bedeutet: Das schlimmste, was Dir passieren könnte, ist, dass ein Client in einem VLAN einen anderen in einem anderen VLAN erreichen kann - nur: wie soll er ihn finden?
1. Natürlich kannst Du das getan haben, das meiste spielt sich allerdings im Firewall-Bereich ab.
2. Jein. Es sind nicht nur WAN-Regeln, sondern z.B. auch NAT.
3. Ja, absolut und ja. Da IPv6 kein NAT benötigt, reicht ein falsches "Allow Any" in den WAN- (oder Floating-) Regeln aus.
4. Ja, sollten sie, sonst brauchst Du ja keine VLANs. Und genau da spielt ggf. auch IPv6 rein, denn jetzt müssen die Pakete eben nicht mehr über das WAN reinkommen.
5. Richtig. Das gilt für die übliche "Allow Any"-Regeln bei IPv4.
6. Ob man das mit einer Regel und invertiertem Ziel oder mit zwei Regeln (eine mit Block RFC1918 und eine mit Allow Any) macht, ist Geschmackssache. Über VLAN-Abschottung auf Ebene IPv6 habe ich noch nicht nachgedacht, denn den Bereich ist zu groß, um ihn zu scannen. Das bedeutet: Das schlimmste, was Dir passieren könnte, ist, dass ein Client in einem VLAN einen anderen in einem anderen VLAN erreichen kann - nur: wie soll er ihn finden?
#2
26.7 Series / Re: Renewed server certificate...
Last post by newsense - Today at 11:42:12 AMYeah then I'm not sure what's going on, sorry.
You couldn't possibly have the CA pk unless you were that CA...so I'm not sure what's triggering that error message about the CA key
You couldn't possibly have the CA pk unless you were that CA...so I'm not sure what's triggering that error message about the CA key
#3
General Discussion / Re: Roku DNS storm is impactin...
Last post by newsense - Today at 11:37:04 AMA few comments on the latest posts.
The GH ticket is not about caching for RRsets.
The Rokus won't be silenced internally, that's not the goal. They can only be silenced by the devs - and clearly the every second telemetry is more important than anything for them.
If the Rokus work without sending logs then dropping the traffic is fine. Caching would only be useful if you still want that traffic to go through but instead of doing dns queries over the internet every second you'd get the replies from the cache and then unbound would refresh the dns information to serve from cache once the cached information is about to expire.
Also there's no need to have cached values for dropped traffic, it's not like those clients obey anything.
The GH ticket is not about caching for RRsets.
The Rokus won't be silenced internally, that's not the goal. They can only be silenced by the devs - and clearly the every second telemetry is more important than anything for them.
If the Rokus work without sending logs then dropping the traffic is fine. Caching would only be useful if you still want that traffic to go through but instead of doing dns queries over the internet every second you'd get the replies from the cache and then unbound would refresh the dns information to serve from cache once the cached information is about to expire.
Also there's no need to have cached values for dropped traffic, it's not like those clients obey anything.
#4
German - Deutsch / Neues setup - Fragen zur Siche...
Last post by name89214 - Today at 11:35:24 AMHallo zusammen,
vorab schon mal besten Dank für euren Support!
Ausgangssituation:
OPNsense 26.7.1_1-amd64
FreeBSD 15.1-RELEASE-p1
OpenSSL 3.5.7
WAN / Internet
:
: Telekom VDSL
:
.-----+-----.
| Gateway | Vigor 167
'-----+-----'
|
WAN | IP or Protocol
|
.-----+------.
| OPNsense |
'-----+------'
|
LAN ; VLAN10 192.168.10.0 ; VLAN20 192.168.20.0 ; VLAN30 192.168.30.0
|
.-----+------.
| LAN-Switch | OpenWRT
'-----+------'
|
...-----+------... VLAN10 192.168.10.11 (client1)
|
...-----+------... VLAN10 192.168.10.12 (client2)
|
...-----+------... VLAN10 192.168.10.13 (client3)
|
...-----+------... VLAN20 192.168.20.21 (client4)
...
Erstellung und Nutzung von firewall rules ist bekannt. Internetzugriff via VLANs hat funktioniert, Wireguard VPN hat funktioniert. Das setup funktioniert generell sehr gut. Ich möchte lediglich Sicherheitsbedenken ausräumen:
Meine Ziele:
1) VLANs sollen nicht auf LAN zugreifen dürfen
2) VLANs sollen getrennt voneinander sein (bis auf rules)
3) VLANs sollen Internetzugriff haben
4) Mein setup soll sicher und nicht von außen angreifbar sein
Herzlichen Dank!! Ich weiß euren Support sehr zu schätzen :)
vorab schon mal besten Dank für euren Support!
Ausgangssituation:
OPNsense 26.7.1_1-amd64
FreeBSD 15.1-RELEASE-p1
OpenSSL 3.5.7
WAN / Internet
:
: Telekom VDSL
:
.-----+-----.
| Gateway | Vigor 167
'-----+-----'
|
WAN | IP or Protocol
|
.-----+------.
| OPNsense |
'-----+------'
|
LAN ; VLAN10 192.168.10.0 ; VLAN20 192.168.20.0 ; VLAN30 192.168.30.0
|
.-----+------.
| LAN-Switch | OpenWRT
'-----+------'
|
...-----+------... VLAN10 192.168.10.11 (client1)
|
...-----+------... VLAN10 192.168.10.12 (client2)
|
...-----+------... VLAN10 192.168.10.13 (client3)
|
...-----+------... VLAN20 192.168.20.21 (client4)
...
Erstellung und Nutzung von firewall rules ist bekannt. Internetzugriff via VLANs hat funktioniert, Wireguard VPN hat funktioniert. Das setup funktioniert generell sehr gut. Ich möchte lediglich Sicherheitsbedenken ausräumen:
- Jetzt frage ich mich, ob ich kritische Einstellungen gesetzt haben könnte, die mich gegenüber dem "Auslieferungszustand" von OPNsense angreifbar machen? Lieber nochmal alles auf null?
- Oder spielen sich sämtliche "gefährliche" Einstellungen bei Firewall>Rules ab, weil ausschließlich hier zB inbound traffic aufs WAN gesetzt wird?
- Kann man sich mit "falschen" IPv6 configs angreifbar machen – außerhalb Firewall>Rules? Oder müssten hierfür auch immer inbound traffic Regeln auf WAN eingestellt sein?
- Die VLANs sollen untereinander getrennt sein – bis auf Regeln natürlich, etwa dass client4 in VLAN20 nach client1 in VLAN10 ruft.
- Viele empfehlen hierfür einen RFC1918 alias zu erstellen für die privaten IP ranges und den dann mit destination invert zu versehen. Sprich, allow traffic überall hin außer local networks.
- Ist das denn best practice? Oder lieber block rule? Wie kann ich beim selbstgeschriebenen Alias sichergehen, dass ich auch alle IPv6 erwische? IPv4 ist ja recht einfach, aber bei dynamischen IPv6 Adressen (Telekom VDSL consumer Vertrag) müsste ich doch bei jeder neuen IPv6 Adresse den alias neu anpassen, oder nicht?
Meine Ziele:
1) VLANs sollen nicht auf LAN zugreifen dürfen
2) VLANs sollen getrennt voneinander sein (bis auf rules)
3) VLANs sollen Internetzugriff haben
4) Mein setup soll sicher und nicht von außen angreifbar sein
Herzlichen Dank!! Ich weiß euren Support sehr zu schätzen :)
#5
26.7 Series / Re: OpenVPN CLient Export fail...
Last post by SchengFui - Today at 11:30:42 AMCould someone please help me with the certificate-storage-paths ?
i found the root certs in /usr/local/share/certs, but i have no idea where to look for the leaf certificates.
i found the root certs in /usr/local/share/certs, but i have no idea where to look for the leaf certificates.
#6
Hardware and Performance / Re: [solved] Intel i226 Firmwa...
Last post by and - Today at 10:19:57 AMQuote from: BrandyWine on Today at 04:23:51 AM@and,This one?
Please list your cfg file.
Code Select
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 1462
SUBDEVICE: b0b1
NVM IMAGE: FXVL_125C_V_2MB_2.32.bin
EEPID: 80000422
RESET TYPE: REBOOT
REPLACES: 80000397
END DEVICE #7
26.7 Series / Re: VLAN devices are on LAN IP...
Last post by dseven - Today at 09:13:34 AMHave you reboot (opnsense) since eliminating the bridge? There may be some artifact from it lurking somewhere.
Otherwise try this tcpdump to see "what's happening on the wire":
Substitute the MAC address of a Guest or IoT device (in two places), and make it (re)connect.
Otherwise try this tcpdump to see "what's happening on the wire":
Code Select
tcpdump -nnvvei igc0 '(ether host aa:bb:cc:dd:ee:ff and port 67) or (vlan and ether host aa:bb:cc:dd:ee:ff and port 67)'
Substitute the MAC address of a Guest or IoT device (in two places), and make it (re)connect.
#8
26.7 Series / Re: os-frr bgp and the web-gui...
Last post by Monviech (Cedrik) - Today at 09:12:42 AMHow do you use BGP, do you have a full internet routing table installed?
If yes, these python scripts are looping over all routes, and that can take quite some time.
If yes, these python scripts are looping over all routes, and that can take quite some time.
#9
26.7 Series / os-frr bgp and the web-gui -> ...
Last post by ednt - Today at 08:59:02 AMHi,
only for information:
I use os-frr for bgp
When I'm inside of the web-gui, I see with 'top' 4 to 6 processes of python combined with netstat running at nearly 100% cpu load.
I think this comes from the dashboard widgets.
But even if I change, for example, to the rules tap, the processes keeps running.
When I logged out from the web-gui, the processes removes.
only for information:
I use os-frr for bgp
When I'm inside of the web-gui, I see with 'top' 4 to 6 processes of python combined with netstat running at nearly 100% cpu load.
I think this comes from the dashboard widgets.
But even if I change, for example, to the rules tap, the processes keeps running.
When I logged out from the web-gui, the processes removes.
#10
26.1, 26,4 Series / Re: VPN: IPsec: Connections [n...
Last post by Monviech (Cedrik) - Today at 08:17:57 AMOpnsense has a default allow rule (Let out anything from firewall itself).
That means initiated connections always succeed.
But you will have issues if the other peer tries to communicate with your Ipsec Daemon (eg send a command to tear the tunnel down and reauthenticate) so I would suggest creating inbound allow rules for Phase 1 as well.
That means initiated connections always succeed.
But you will have issues if the other peer tries to communicate with your Ipsec Daemon (eg send a command to tear the tunnel down and reauthenticate) so I would suggest creating inbound allow rules for Phase 1 as well.
