Messages

... i cant ... i havent changed ANYTHING... now everything is working as before and as intended... my isp never detected an error, and i made no changes...
i used the modem directly on my pc for 1.5 days, plugged it back and everything was fine...
wtf is going on here :-(

Why did you create a floating rule? There should be no need to create any rules - there should be default rules on the LAN interface to allow IPv4 and IPv6 to "any".

Deleted it, nothing changed. So the rule doesn't matter
As I said, tried a lot

Don't know what I am doing wrong.
Performed a baremetall fresh installation of opnsense, kept basic settings, one wan dhcp fullstack and one lan. Created a floating rule to allow all.
Dashboard shows v4 and v6 ip.
Updates are working, plug ins are laoding, installed a dark theme, PC connected to lan shows Internet activity
Dns Lookups are working.
But
Ipv4 pages can't load, and pinging those isn't possible either
Ipv6 is fine, I can google around but opening this forum found on Google isn't possible. I.e.

Fun fact, I had this issue before using my fritzbox on bridge, switched to a bought heavily expensive used cable modem and it worked for 2 weeks now without any problem and suddenly the $hit started over again.
So I started witha clean baremtal installation... my isp checked everything twice and sent over a technician to check for errors... no problem on their side
Another fun fact: plugging the pc directly to the modem works perfectly..
Any clue?

ok ... i need to check that. but yeah, the isp provides WAN via DHCP and expects most probably untagged traffic ...
maybe i have time to test it on the weekend.
thank you so much for the help!

as far as i know, they dont require anything like that. ISP -> Modem -> Router.
at the moment i am using the WAN directly plugged into the 2nd port of the zimaboard.

my isp is vodafone in germany, using cable

OK ... got a omada switch, controlled by omada software.
Zimaboard for baremetall opnsense
and like to set it up as one nic router (as i have 2 wans) but for the moment, a simple connection would be great ;-)

Switch Setup
1 -> Default (Interface)
5 -> LAN (VLAN)
100 -> WAN 1 (VLAN)

Port 1 -> WAN. Native 100 + Untagged 100
Port 2 -> LAN Trunk. Native 1, Tagged 5+100, Untagged 4
Port 3 -> LAN. Native 4, Untagged 5

Opnsense configured on re0
LAN re0_vlan5
WAN re0_vlan100

i thought i understood, tried to replicate tutorials , but it seems as if i havent understood (un)tagging...

but i dont get a WAN IP :-/

Can you pls help me out, finding the problem (for that, tell me pls what you need to know :-) ) ? most probably its easy, but i am too stupid for days now...

Hello, i posted the same problem on the international forum, but maybe ... bigger hive, bigger hivemind ;-)

i am fighting this problem since i started using my FB in bridge mode (germany, Vodafone, Cable, DualStack)
this problem occurs suddenly and unpredictably.
Last 3 days i had no issues (havent even opened the Opnsense UI the last 24 hours), everything worked finde (including admistration via wireguard from outside) but today, something striked back.

Affected is every device, no matter if its a physical computer (os independend), a VM/LXC/IOT ... even Opnsense itself (which gets the WAN directly over PCI passthrough)
DNSlookup works fine.
Ping, traceroot, opening internetpages or connecting to services on IPv4 dont work, IPv6 work perfectly.

i am owning a FritzBox 6660 and tested with an 6690 as well. Same issues on bridgemode.
FB in regular Routermode had no problems (never had before, or happened while i tested it the last weeks)...

any idea ?

imho it is a problem in front of opnsense ... either FB (it occurs on non bridge as well) or its an ISP problem, as sometimes reconnecting solves the issue temporarly...

any ideas ? i am willing to provide any screenshot that might help you , figuring out the cause of the problem.

thxia

[Long Story Short:]

Long Story Short:
Hatte nun 3 Tage oder so Ruhe, alles lief perfekt (inkl Wireguard) ... nun gings wieder los:

Folgendes gilt für ALLE Clients (egal ob PC, VM, LXC, IOTs usw. .. und es ist egal in welchem VLAN sie sind...)  selbst für die OpnSense-Instanz an sich, bei der ja das Inet direkt physisch - über PCI passthrough - reingeht, ohne bridge/bond/vlan)
DNS Lookup gehen überall,
Ping, traceroute und Aufrufen von IPv4 Adressen/Seiten geht nicht, IPv6 geht allerdings stets problemlos.


----
Ausführlicher Teil
So, hatte ja wirklich nochmal bei 0 angefangen und ... bis vor 4 Stunden lief es auch echt absolut perfekt.
Habe Sonntag den ganzen Tag über Wireguard - von außerhalb - in dem Testlan Server eingerichtet, die VLANs fertig gestaltet usw. VOllkommen problemlos, dieses mal auch alles schön gebackuped.
Heute kam ich heim und auf der ToDoListe stand Homeassistant. Bei der Installation habe ich dann nebenher noch das "Proxmox PVE postinstallscript" von TTECK gefunden und installiert. Danach  (10-15min) ging das Internet nicht mehr.
Hatte - glaube ich - seit ca 24 Stunden die Opnsense GUI nicht mehr öffnen müssen.

Dachte mir, fck, habe mir wieder alles zerschossen oder so. Erstmal die Firewall gläsern gemacht und alles ausgehende erlaubt (die Regeln waren vorher etwas eingeschränkter), keine Besserung, egal, Backups - welche sicher funktionieren aufgespielt... ohne Erfolg. Proxmox neu installiert, Backups wiederhergestellt , nichts.

Dann ist mir wieder aufgefallen, dass es das gleiche Problem ist wie ich zuvor immer wieder hatte. Aber mit 3 Tagen Pause, hatte ich die Möglichkeit des Wiederauftretens verdrängt.



Also aktuelles Problem wieder, Config wie sie auch funktionierte (änderte ja nichts daran)

WAN wird von der Opnsense richtig erkannt (IPv4 und IPv6) bei echten Dualstack.
im WAN Interface sind Block private und Block bogon geblocked. Entblocken ändert nichts, weshalb auch , ist keine DoubleNAT

Folgendes gilt für ALLE Clients (egal ob PC, VM, LXC, IOTs usw. .. und es ist egal in welchem VLAN sie sind...)  selbst für die OpnSense-Instanz an sich, bei der ja das Inet direkt physisch - über PCI passthrough - reingeht, ohne bridge/bond/vlan)
DNS Lookup gehen überall,
Ping, traceroute und Aufrufen von IPv4 Adressen/Seiten geht nicht, IPv6 geht allerdings stets problemlos.

Hatte die Idee mal zu schauen was passiert, wenn ich Surfshark anmache... naja kann nicht verbinden (herunterladen geht, dank IPv6)

----------

Fazit:

FB im Routermodus geht es auch nicht musste ich soeben feststellen...

Also ich werde das Gefühl nicht los, dass das Problem VOR der Opnsense und nicht in meiner Macht liegt. Das TC4400-EU kommt am Mittwoch... also entweder ist es ein irgendwie geartetes FB Problem (... auf 6660 und 6690  ????!) oder doch ein Vodafone-Problem...

Wenn ihr noch Lösungsvorschläge habt, lasst es mich gerne Wissen. Beschere euch jeden Screenshot den ihr wollt....

p.s. werde das problem auch mal im englischen Forum posten und auf Schwarmintelligenz/Publikumsjoker hoffen

p.p.s. Fritzbox antwortete auf dem Proxmox des Routers, weil die resolv.conf falsch eingestellt war.

ja ich weiß, war von meine PC aus ohne bridge-mode... dieses Problem tritt leider in nicht absehbaren abständen auf. Aktuell läuft es mal wieder ... natürlich (-:
Wenn es wieder kommt, werde ich entsprechendes von dem Testnetwerk aus liefern ...

Wie ist Dein WAN in der OPNsense eingerichtet?

Es sollte für IPV4 idealerweise auf DHCP stehen. Sofern die Fritzbox DHCP an hat.
Dann sollte "Block private networks" aus sein.

Ist DHCP, warum sollte block private aus sein wenn die fb im bridge Mode ist? Ist ja kein double nat.
Der Fehler tritt aber auch im nicht bridge Modus auf

Nun -

Kommt den eine IPV4 an der OPNsense an. Eine öffentliche?

Ja kommt sie, wird auch in der FB angezeigt. Aber ich kann keine ipv4 Seiten aufrufen, oder Hosts pingen.

hatte  von Vodafone mal den Auftragt tracert zu machen ...



Tracert einmal mit funktionierender IPv4 Verbindung und dann nach Ausfall.
Ping 2x funktionierend, allerdings hatte ich beim 2. auch irgendwie Packetloss. der 3. Ping ist dann nach Ausfall.

Ich kann in der Fritzbox "neu verbinden" dann ist der Fehler meistens vorübergehend behoben.

Hauptproblem sind leider immer noch verbindungsabbrüche auf der ipv4 Seite (seiten die nur ipv4 anbieten gehen nicht, alles über ipv6 ist problemlos). Für mich ist nich zu differenzieren ob es ein fritzbox bridge Mode Problem ist ( der fehler tritt sowohl 6660 u 6690 auf) oder ein irgendwie gearteten vodafone problem ist. Beide verneinen, dass die Probleme dort zu finden seien. Demnach kann ich bei Problemen im LAN auch ein userfehler nicht ausschließen...
Habe mir deshalb überlegt , ein tc4400eu zuzulegen und das als Modem vor die opnsense zu setzen, ein interface für das jetzt bestehende Netzwerk, quasi exposed, einzurichten um da die fb als reinen Router das jetzige lan hinzustellen.

So müsste ich doch nebenher das neue Netzwerk ganz langsam und Schritt für Schritt aufbauen können ohne die Funktionalität des bestehenden zu verändern... oder?

Habe ein echtes dualstack

[100]

Also Proxmox und Omada liegen im VLAN10, ebenso wie PC1, und natürlich hat auch OPNsense da ein Interface.
Zugriffe zwischen Geräten innerhalb dieses Subnetzes passieren nicht die OPNsense. Wenn du vom PC1 auf Proxmox oder Omada zugreifst, geht das über den Switch und die Bridge am Host direkt da hin. Das kann keine Regel auf OPNsense verhindern. Zugriffe von jedem anderen Subnetz kannst du aber sehr wohl blockieren.

tut mir leid für die Verwirrung, mein Fehler. liegt auf VLAN100 = 10.10.10.0/24. VLAN10 ist die 192.168.10 ... didaktisch natürlich die dümmste Stelle einen Fehler zu machen :-D

Muss sie von da her auch nicht.

Das ist ein DNS Request. Proxmox hat vermutlich noch die alte Gateway IP als DNS Server eingestellt und richtet ihre Anfrage da hin.
Welche Regel den Zugriff erlaubt, zeigt dir das Log: WAN ja, Intranet Block   
Das alte LAN ist nicht Teil des Aliases "Internal Networks", und damit erlaubt die Regel den Zugriff.

Hm , muss ich mal auf Suche gehen wo das Standardgateway stehen könnte.

Naja eigentlich sollte ja jeder dieser Pings/Zugriffe innerhalb des Subnetzes stattfinden und so dachte ich zumindestens auch den gleichen Regeln unterworfen sein. Deshalb ist ja die Frage, weshalb kann ich von 10.10.10.10 (dem Omadacontroller) die Proxmox VE auf 10.10.10.3 pingen, aber nicht das Gateway des selben VLANs auf 10.10.10.1...

Bedenke, dass auf jedem Zielgerät eine eigene Firewall laufen kann. Für OPNsense trifft das wohl zu und die Regel funktioniert auch. Auf Proxmox ist die Firewall vielleicht nicht aktiviert. Die kannst du aber in der GUI konfigurieren.

Zugriffe von allen anderen Subnetzen auf das Management-Subnetz kannst du auf der OPNsense blockieren.

habe mir jetzt auf nem übrigen Zimablade nochmal ein Proxmox installiert und auf DHCP gestellt... werde da mal etwas herumtesten (-:

Vielen Dank für deine Antwort

Was ist in der Grafik dieses VLAN10 vom Switch auf Proxmox #4? Ist das eine Schnittstellennummer?)
Wenn, dann ist irgendwas daran falsch, entweder "VLAN10" oder die Omada IP, denn VLAN10 sollte ja das Asguard Subnetz 192.168.10.0/24 sein.

Ja das ist ein Fehler, das sollte natürlich VLAN100 sein, #4 ja ist der 4. lanausgang des MiniPCs. 1+2 für Opnsense, 3 ungenutzt, 4 für Proxmox + Omada
Habe das Bild korrigiert ;-)

Wäre an und für sich normal, allerdings zeigt der Regel-Screenshot die des MGMT Interfaces, während das Log zur Verwirrung Zugriff auf dem Asguard Interface zeigt.

So soll es geschehen. Regeln sind dupliziert und nur die entsprechenden Parts geändert, von daher dachte ich, könnte ich es mir sparen ;-) Sorry für die Faulheit

Kein Zugriff auf das WAN, der Ping geht zwar raus, aber mit Destination 192.168.0.1:53 !... wtf EIGENTLICH dürfte die Proxmoxbox ja überhaupt nichts von dem 192.168.0.0/24 wissen ;-)

Das ist wohl ein DNS Request auf Port 53. Pings gehen auf keine Ports.

Ja, aber der Punkt ist, dass es an die Fritzbox gerichtet ist, genauer gesagt eigentlich an das Gateway des an der FB hängenden ursprünglichen LANs und nicht wie aus dem Asgard-VLAN an die OpnSense ;-)... das VLAN100 sollte von 192.168.0.1 gar nichts wissen.

Ping auf 10.10.10.1 ist verboten
Ping auf 10.10.10.3 geht durch, wird von der FW aber nicht registriert
Zur Erinnerung 10.10.10.3 ist die ProxVE, über welche der Omada-Controller läuft.

Ja, so funktioniert Netzwerk und Firewall. Zugriffe innerhalb eines Subnetzes passieren normalerweise nicht die Firewall (den Router) und werden damit weder blockiert noch geloggt.

Naja eigentlich sollte ja jeder dieser Pings/Zugriffe innerhalb des Subnetzes stattfinden und so dachte ich zumindestens auch den gleichen Regeln unterworfen sein. Deshalb ist ja die Frage, weshalb kann ich von 10.10.10.10 (dem Omadacontroller) die Proxmox VE auf 10.10.10.3 pingen, aber nicht das Gateway des selben VLANs auf 10.10.10.1...

Hallo liebe Community, bin gerade am basteln für das neue Heimnetzwerk und die Herausforderung war größer als gedacht ;-) und bin etwas am verzweifeln.

Hier ein Überblick, ich hoffe ich habe alle wichtigen Informationen hineingepackt. Wenn nicht, bitte fragen, ergänze es natürlich sehr gerne.


WAN ist ein Vodafone echtes Dual Stack, Modem ist meine FB6660, an Port 1 nach wie vor mein jetziges LAN, an port 2 gebridged das neue Testsetup.

Die ProxmoxBox enthält zum einen OpnSense (Port 1 (WAN) und 2 (Trunk für Testsetup) sind durchgeschleift, werden also nicht von Proxmox angerührt) und zum anderen den Omada Controller (Verbunden über die Proxmox Bridge mit ner festen IP, als Static ARP eingetragen)

Opnsense erkennt die richtige WAN IP, updates usw funktionieren

Vlans+LAN in der Opnsense sind u.a. wie auf dem Bild zu sehen, VLAN100 = MGMT, sind im Switch und AEP auch so hinterlegt

IP Vergabe über den L2+ Switch geht für PCs wunderbar. Port Tagged -> passende IP vom dem OPNsense VLAN DHCP

Test-PC1+2 agieren auch im normalen Rahmen, werden auch auf die regulären Gatways .1 weitergeleitet, haben zugriff auf DNS, können WAN Pingen (nicht LAN, das ist aber sofern ich das Verstanden habe normal weil ich ICMP noch nicht freigegeben habe), aber lokal nur innerhalb des VLANs agieren und die Server aufrufen. Also sowohl VLAN10 als auch 100 agieren wie die Regeln vorschreiben.

hier die Regeln:
   
Allerdings wundere ich mich, das ich auf Prox und Omada normal zugreifen kann, aber auf die OpnSense nur komme, wenn die untere Regel an ist... ist das normal ? kommt mir auch etwas spanisch vor


und hier das Ergebnis aus der Live-View


Problem besteht allerdings bei dem ProxVE.
Auf der Konsole der Omada-VM gehts so zu:

Code Select Expand

mich@Omada-ubuntu:~# ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
^C
--- 10.10.10.1 ping statistics ---
27 packets transmitted, 0 received, 100% packet loss, time 26659ms

mich@Omada-ubuntu:~# ping web.de
ping: web.de: Temporary failure in name resolution
mich@Omada-ubuntu:~# ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
^C
--- 10.10.10.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5110ms

mich@Omada-ubuntu:~# ping 10.10.10.3
PING 10.10.10.3 (10.10.10.3) 56(84) bytes of data.
64 bytes from 10.10.10.3: icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from 10.10.10.3: icmp_seq=2 ttl=64 time=0.045 ms
64 bytes from 10.10.10.3: icmp_seq=3 ttl=64 time=0.054 ms
^C
--- 10.10.10.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2071ms
rtt min/avg/max/mdev = 0.042/0.047/0.054/0.005 ms
mich@Omada-ubuntu:~#

Kein Zugriff auf das WAN, der Ping geht zwar raus, aber mit Destination 192.168.0.1:53 !... wtf EIGENTLICH dürfte die Proxmoxbox ja überhaupt nichts von dem 192.168.0.0/24 wissen ;-)
Ping auf 10.10.10.1 ist verboten
Ping auf 10.10.10.3 geht durch, wird von der FW aber nicht registriert
Zur Erinnerung 10.10.10.3 ist die ProxVE, über welche der Omada-Controller läuft.

Code Select Expand


MGMT 2024-10-20T15:51:56 10.10.10.10 10.10.10.1 icmp Default deny / state violation rule
MGMT 2024-10-20T15:51:56 10.10.10.10 10.10.10.1 icmp Default deny / state violation rule
MGMT 2024-10-20T15:42:42 10.10.10.10:56232 192.168.0.1:53 udp WAN ja, Intranet Block
MGMT 2024-10-20T15:42:37 10.10.10.10:48944 192.168.0.1:53 udp WAN ja, Intranet Block


Wenn ich das nun das gleiche über die Prox-Console Starte, sieht es genauso aus. Ping an die 10.10.10.10 geht, wird nicht registriert, Ping an OpnSense wird geblockt, Ping web.de kein DNS resolve, obwohl die FW sagt jupp, lass ich durch, schicke es aber unsinniger Weise an die 192.168.0.1


Die Gleichen Tests über die Opnsense Console gehen natürlich wunderbar ;-)

Bin mir nicht sicher, rätsel da jetzt schon einige Stunden und komme nicht voran. Hatte die Vermutung, dass der ProxVE irgendwie nicht richtig im VLAN angenommen wurde (weil die ProxVE IP ja von mir händisch vergeben wurde) und deshalb auch der Omada Controller nicht richtig agiert... auf der anderen Seite hat eben jener zuerst ne DHCP vom MGMT bekommen, welche ich dann die als static eingetragen habe...

Keine Ahnung :-/ bitte helft mir...

Noch ein paar Infos (habe nur den mMn wichtigen Teil gepostet)
-ip a vom Omada-Controller, habe hier kein VLAN eingestellt

Code Select Expand

eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:dc:76:95 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.10.10.10/24 metric 1024 brd 10.10.10.255 scope global dynamic eth0
       valid_lft 3799sec preferred_lft 3799sec
    inet6 fe80::be24:11ff:fedc:7695/64 scope link
       valid_lft forever preferred_lft forever

-ip a vom Prox VE Host, hier ist übrigens die Bridge auch auf VLAN aware gesetzt

Code Select Expand

vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:d0:b4:01:95:c3 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.3/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::2d0:b4ff:fe01:95c3/64 scope link
       valid_lft forever preferred_lft forever