"Recent posts
#1
German - Deutsch / Re: Netzwerkproblem
Last post by viragomann - Today at 06:58:52 PMD.h. vermeintlich alles in Ordnung.
Warum dann Traceroute als erstes eine IP im anderen Subnetz hinter dem Router ausgibt, ist mir nicht klar.
Wenn nur TCP erlaubt ist, kommen Pings (ICMP) nicht drüber.
Auch würde ich Source und Destination zur Fehlersuche auf any setzen. Wenn du bspw. eine falsche Subnetzmaske gesetzt hättest, könnte Quelle oder Ziel aus dem Netzwerk fallen.
Wenn dann immer noch nichts geht, mach ein Packet Capture, erst am eingehenden Interface, wenn ok, am ausgehenden. Kommt da schon gar nichts rein oder auch das Richtige raus, kannst du OPNsense als Fehlerursache ausschließen.
Warum dann Traceroute als erstes eine IP im anderen Subnetz hinter dem Router ausgibt, ist mir nicht klar.
Quote from: uwe-beach on Today at 04:27:24 PMFür das Interface Backup gibt es eine Regel, mit Source 'Backup Network', Destination 'LAN-Network', Protocol TCP, alle Ports auf ANY.Okay, bevor du weitersuchst, mache erst mal die Regel weiter auf. Erlaube alle Protokolle, dann versuch es mit einem Ping oder Traceroute.
Wenn nur TCP erlaubt ist, kommen Pings (ICMP) nicht drüber.
Auch würde ich Source und Destination zur Fehlersuche auf any setzen. Wenn du bspw. eine falsche Subnetzmaske gesetzt hättest, könnte Quelle oder Ziel aus dem Netzwerk fallen.
Wenn dann immer noch nichts geht, mach ein Packet Capture, erst am eingehenden Interface, wenn ok, am ausgehenden. Kommt da schon gar nichts rein oder auch das Richtige raus, kannst du OPNsense als Fehlerursache ausschließen.
#2
26.7 Series / Re: Renewed server certificate...
Last post by Ed V. - Today at 06:15:32 PMCorrect.
I've tried both "Import an existing Certificate" as well as editing the in-place (active) certificate to update the certificate data (aka "Reissue and replace").
I've tried both "Import an existing Certificate" as well as editing the in-place (active) certificate to update the certificate data (aka "Reissue and replace").
#3
German - Deutsch / Re: Netzwerkproblem
Last post by uwe-beach - Today at 05:57:49 PMDas NAS ist nur im Netz 192.168.180.0/24.
Die Arp-Tabelle sieht so aus :
arp -a
? (192.168.180.2) at c4:00:ad:ba:27:55 [ether] on enp1s0
Die Arp-Tabelle sieht so aus :
arp -a
? (192.168.180.2) at c4:00:ad:ba:27:55 [ether] on enp1s0
#4
General Discussion / Re: Clients on VLANs not recei...
Last post by Smoky020 - Today at 05:57:18 PMThank you for your detailed explanation and your identical conclusion as mine.
I have been going through the discussion on github and I can only agree with your motivations.
Primary selection = global unicast address and secondary IF primary is not available = link-local
And not just link-local, as you correctly justify; only if a GUA is NOT available which in this case it is present.
I have been going through the discussion on github and I can only agree with your motivations.
Primary selection = global unicast address and secondary IF primary is not available = link-local
And not just link-local, as you correctly justify; only if a GUA is NOT available which in this case it is present.
#5
German - Deutsch / Re: Netzwerkproblem
Last post by viragomann - Today at 05:27:22 PMHallo,
Eigentlich würde ich mir erwarten hier als ersten Hop die Gateway IP des NAS zu sehen, also 92.168.180.2.
Ein anderer möglicher Grund könnte ein Layer 2-Leck zwischen den beiden Netzwerksegmenten sein.
Einfach nachzuweisen, indem du am NAS die ARP-Tabelle anzeigst. 192.168.178.1 dürfte da nicht aufscheinen, wenn es in Ordnung ist.
Quote from: uwe-beach on Today at 04:27:24 PMAusgabe eines traceroute auf dem Truenas :Könnte es sein, dass du dein NAS multi-homed betreibst? Also dass es in beiden Subnetzen eine IP hat.
traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
1 192.168.178.1 (192.168.178.1) 0.133 ms 0.102 ms 0.054 ms
Eigentlich würde ich mir erwarten hier als ersten Hop die Gateway IP des NAS zu sehen, also 92.168.180.2.
Ein anderer möglicher Grund könnte ein Layer 2-Leck zwischen den beiden Netzwerksegmenten sein.
Einfach nachzuweisen, indem du am NAS die ARP-Tabelle anzeigst. 192.168.178.1 dürfte da nicht aufscheinen, wenn es in Ordnung ist.
#6
26.7 Series / nfSensei ( fork pfsense )
Last post by yeraycito - Today at 05:11:44 PM #7
General Discussion / Re: UK Specific - YourFibre Co...
Last post by V3G4NC4MP3R - Today at 05:09:23 PMThank you @nero355 - managed to get it working - now need to switch it back so don't upset the wife while I sort out the rules 🤭 Have a wonderful weekend 🤞
#8
German - Deutsch / Netzwerkproblem
Last post by uwe-beach - Today at 04:27:24 PMHallo,
ich nutze OPNSense 26.7.1 mit folgender Netz-Konfig :
Fritzbox (192.168.177.1) --> OPNSense WAN (192.168.177.2) --> OPNSense LAN (192.168.178.1)
In der OPNSense ist ein weiteres Interface mit Namen Backup (192.168.180.2) definiert.
Von einem TrueNas-Gerät (192.168.180.10) komme ich nicht auf das LAN-Interface und dadurch auch nicht auf Geräte im LAN.
Für das Interface Backup gibt es eine Regel, mit Source 'Backup Network', Destination 'LAN-Network', Protocol TCP, alle Ports auf ANY.
Ausgabe eines traceroute auf dem Truenas :
traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
1 192.168.178.1 (192.168.178.1) 0.133 ms 0.102 ms 0.054 ms
traceroute 192.168.178.100
traceroute to 192.168.178.100 (192.168.178.100), 30 hops max, 60 byte packets
1 192.168.180.2 (192.168.180.2) 0.120 ms 0.095 ms 0.100 ms
Ein ping, ausgeführt auf dem OPNSense-Interface Backup (192.168.180.2), auf eine IP aus dem LAN funktioniert.
Ein ping vom Truenas auf das LAN-Interface funktioniert nicht.
Von der Truenas kommt man ins Internet.
Hat jemand eine Idee ?
ich nutze OPNSense 26.7.1 mit folgender Netz-Konfig :
Fritzbox (192.168.177.1) --> OPNSense WAN (192.168.177.2) --> OPNSense LAN (192.168.178.1)
In der OPNSense ist ein weiteres Interface mit Namen Backup (192.168.180.2) definiert.
Von einem TrueNas-Gerät (192.168.180.10) komme ich nicht auf das LAN-Interface und dadurch auch nicht auf Geräte im LAN.
Für das Interface Backup gibt es eine Regel, mit Source 'Backup Network', Destination 'LAN-Network', Protocol TCP, alle Ports auf ANY.
Ausgabe eines traceroute auf dem Truenas :
traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
1 192.168.178.1 (192.168.178.1) 0.133 ms 0.102 ms 0.054 ms
traceroute 192.168.178.100
traceroute to 192.168.178.100 (192.168.178.100), 30 hops max, 60 byte packets
1 192.168.180.2 (192.168.180.2) 0.120 ms 0.095 ms 0.100 ms
Ein ping, ausgeführt auf dem OPNSense-Interface Backup (192.168.180.2), auf eine IP aus dem LAN funktioniert.
Ein ping vom Truenas auf das LAN-Interface funktioniert nicht.
Von der Truenas kommt man ins Internet.
Hat jemand eine Idee ?
#9
General Discussion / Re: Clients on VLANs not recei...
Last post by jchnnz - Today at 04:18:29 PMI've also reproduced this. The problem is in the dhcrelay6 implementation
The relevant OPNsense interface has both:
2406:xxxx:xxxx:b170::1/64
fe80::250:56ff:feaa:bb70
but the Relay-Forward sent to the DHCPv6 server contains:
Link-address: fe80::250:56ff:feaa:bb70
My Windows DHCP server receives the Relay-Forward but can't associate that link-local address with the 2406:xxxx:xxxx:b170::/64 scope, so it sends no reply. For comparison, a Dell switch relaying to the same DHCPv6 server correctly uses its client facing GUA as link-address and Windows immediately returns a Relay-Reply.
I vibe reviewed the dhcrelay source code and dhcrelay6.c explicitly does:
In other words, when building the Relay-Forward dhcrelay6 explicitly populates link-address from the interfaces link-local IPv6 address. That matches exactly what appears in the packet capture.
dispatch.c only records that a non-link-local IPv6 address exists:
The actual GUA/ULA isn't stored, so relay6_pushrelaymsg() has no GUA/ULA available to use for link-address.
I've raised a bug here: https://github.com/opnsense/core/issues/10686
This also looks related to #10623, where Relay-Replies are sent to the wrong VLAN. Different symptom, but likely wrapped up in the same underlying link-address handling.
In any case, I can confirm from packet captures that the endpoint sends a correctly formatted Solicit, OPNsense receives it and generates a Relay-Forward, and that Relay-Forward arrives at the DHCPv6 server successfully over a properly routed, GUA based IPv6 network. The relay and server are on different routed subnets, and the outer IPv6 packet is delivered correctly. I can also rule out the DHCPv6 server itself. A separate Dell switch relays DHCPv6 for other subnets to the same Windows DHCP server successfully. The problem is the embedded DHCPv6 link-address in the OPNsense Relay-Forward. OPNsense uses the client-facing interface's link-local address instead of its GUA, so the DHCP server can't associate the request with the correct scope.
TL;DR: DHCPv6 Solicit is valid → OPNsense receives it → DHCPv6 Relay-Forward is generated → DHCP server receives it → DHCP server itself works with another relay → embedded link-address supplied by OPNsense in the Relay-Forward is wrong.
The relevant OPNsense interface has both:
2406:xxxx:xxxx:b170::1/64
fe80::250:56ff:feaa:bb70
but the Relay-Forward sent to the DHCPv6 server contains:
Link-address: fe80::250:56ff:feaa:bb70
My Windows DHCP server receives the Relay-Forward but can't associate that link-local address with the 2406:xxxx:xxxx:b170::/64 scope, so it sends no reply. For comparison, a Dell switch relaying to the same DHCPv6 server correctly uses its client facing GUA as link-address and Windows immediately returns a Relay-Reply.
I vibe reviewed the dhcrelay source code and dhcrelay6.c explicitly does:
Code Select
dsr->dsr_linkaddr = intf->linklocal;In other words, when building the Relay-Forward dhcrelay6 explicitly populates link-address from the interfaces link-local IPv6 address. That matches exactly what appears in the packet capture.
dispatch.c only records that a non-link-local IPv6 address exists:
Code Select
intf->gipv6 = 1;The actual GUA/ULA isn't stored, so relay6_pushrelaymsg() has no GUA/ULA available to use for link-address.
I've raised a bug here: https://github.com/opnsense/core/issues/10686
This also looks related to #10623, where Relay-Replies are sent to the wrong VLAN. Different symptom, but likely wrapped up in the same underlying link-address handling.
In any case, I can confirm from packet captures that the endpoint sends a correctly formatted Solicit, OPNsense receives it and generates a Relay-Forward, and that Relay-Forward arrives at the DHCPv6 server successfully over a properly routed, GUA based IPv6 network. The relay and server are on different routed subnets, and the outer IPv6 packet is delivered correctly. I can also rule out the DHCPv6 server itself. A separate Dell switch relays DHCPv6 for other subnets to the same Windows DHCP server successfully. The problem is the embedded DHCPv6 link-address in the OPNsense Relay-Forward. OPNsense uses the client-facing interface's link-local address instead of its GUA, so the DHCP server can't associate the request with the correct scope.
TL;DR: DHCPv6 Solicit is valid → OPNsense receives it → DHCPv6 Relay-Forward is generated → DHCP server receives it → DHCP server itself works with another relay → embedded link-address supplied by OPNsense in the Relay-Forward is wrong.
#10
General Discussion / Re: UK Specific - YourFibre Co...
Last post by nero355 - Today at 03:52:09 PMQuote from: V3G4NC4MP3R on Today at 03:41:36 PMThanks for replying. I should have made clear that I have a public static IP as part of my service.Then you need to Manually tell OPNsense that because the Automatic Gateway stuff won't work !!
You can find the explanation @ https://docs.opnsense.org/ ;)
(I don't use the setting so I can't remember anymore what you need to do exactly... sorry!)
