Messages

I apologise, I don't speak Chinese and that's why I write in English. But I wanted to test pfTop and gave your addon/tool a go (I did do a quick translation of your tool to English otherwise I would have been lost :) ).

After going to the page (pfTop) for the first time and no filter set:
You cannot view this attachment.

... and in pfTop if I set a filter the upper part of the dialog disappears and I can't press anything in the menu on the left.
You cannot view this attachment.

Btw: after installing it with install.sh you don't have to reboot. Delete the files /tmp/opnsense_acl_cache.json and /tmp/opnsense_menu_cache.xml and reload the webpage.

I can't see that I have such rule or am I missing something here? What description do you see for the rule you're referring to here?
The Port Forward looks a bit what you referring to.
To my understanding this should Port Forward traffic that is not from my internal DNS and not having a destination to any internal address.

I'm not making myself clear, no worries and your forwarding rules is probalby correct. What I meant is, does your port forwarding rule look similar to the following, second entry (interface would be different, of course)?

You cannot view this attachment.

Port Forward rule
from: !hosts_lan_DNS (from everything that is not a DNS-server)
to: !net_IP_rfc1918 (not destined for a local network)
dest: 192.168.32.1
port: 53
Linked rule: ...

Maybe first another question: what is the point of this forwarding rule, you want to redirect external UDP/DNS queries to .32.1?

You have set no source proto & port, or are they set to UPD/53 for source and destination? (Sorry it's early) What I meant is you have set destination to !net_IP_rfc1918, port 53 and forward it to .32.1, port 53 - and proto for this rule is set to UDP, on what interface is this rule?

Addition: I see that in the first post, the blocked rule has the DF (dont-fragment) bit set. What is your setting in Firewall:Settings:Normalization IP Do-Not-Fragment ? DNS query is tiny, can't be.

I really don't know either, it turns out.

The order of the rules would be:
1) rdr/port forwarding (can you enable logging there to see the target the client tries to reach)
2) floating rule allowing (in theory) access to the DNS server .32.1

The port forwarding seem to work and at the second rules something goes wrong. The rule matches but it get blocked. For me that usually means that something with the state of the connection is not ok, asymmentric routing or similiar.

Did you change the floating rule from block to pass? Or do you have another rule with the same name?

A pass rule would not block, it eithers match and allows what it is supposed to allow. Or not match and not do anything.

DUID is supposed to be unique per device, not per interface. DUID + IAID is for identifing a single interface (See https://datatracker.ietf.org/doc/html/rfc3315#section-10).

Did you try to set different interface IDs in the DHCPv6 client config for the WANs (Configuration Mode 'Advanced') and see if you get different prefixes for the two WANs?

There are ISP who don't do IPv6 well but not sure that dhcp6c will be changed to violate RFCs.

Das hab ich ja auch gemacht,

Da komme ich nicht mehr mit.

Sein LAN ist 192.168.1.0/24. Nach der Installation - wo die Sense _nur_ mit einem PC verbunden ist - ist das LAN der neu installierten Sense, 192.168.1.1. Dann stellt er LAN auf der Sense auf 192.168.2.1/24 um, weil es mit seinem eigenen LAN kollidieren würde und er das MGMT Interface in seinem LAN haben will.

Wie Du von OPNsense LAN 192.168.1.1 umstellen auf 192.168._2_.1 in seinem Video, auf die Idee kommst es auf die Dein LAN 192.168.178.3/24 um zu stellen, mit aktivem DHCP Server auf der OPNsense - I don't know. Solange Du nur das MGMT Interface mit dem Deinem LAN verbindest, spielt nicht mal das eine Rolle.

Wieso Du drauf bestehst, das OPNsense LAN mit Deinem LAN zu verbinden obwohl in dem Video davon nirgends die Rede, kannst auch nur Du wissen (ist schon Vollmond?).

Für heute bin ich raus.

as LAN hat .178.3 und die MGMT.178.99

Wie gesagt, ich würde nochmals von vorne anfangen. Ziemlich früh stellt er LAN von .1.1 auf .2.1 um, damit er das MGMT später auf .1.1 stellen kann. Warum Du Dich entschieden hast, das nicht zu machen, kannst nur Du wissen.

Wenn ich am LAN und MGMT Port hänge komme ich mit beiden IP .3 und .99 auf die OPNsense.
Ziehe ich LAN ab und nur über MGMT komme ich nicht mehr auf die OPNsense.
Wollte jetzt Bridg einstellen.

Wieso hat das LAN noch eine 178.3 Adresse? Und zieh MGMT auch nochmals aus und steck es (nur das MGMT) wieder ein, dann geht es wahrscheinlich wieder.

Ich glaub nochmals anfangen und dem Video genau folgen, scheint mir die grössten Erfolgschancen zu haben. Er verbindet die Sense nur mit einem PC, bis er das MGMT Interface konfiguriert hat - nicht ans LAN. Und dann _nur_ das MGMT Interface verbinden, vorher hat auch noch Firewall Regeln erstellt, etc.

I also added a screen shot showing the tens of thousands of bogon IPs slipping through to my OpenVPN Access server and being trapped by fail2ban. Many of thesea are already in the tony_bogons list.

If you press the 'Inspect' in the NAT and WAN firewall rules, do you see them matching?
NAT rules come before the firewall rule, I assume that was already mentioned in the thread. When I try that out, no rule on the WAN interface is necessary, on in the NAT port forwarding (and that creates one automagically).

You did press 'Apply' after changing the alias, yes?

Du meinst wenn ich die Bridge erstelle darf ich nur an der MGMT Port hängen?

Ja genau, macht er im Video auch so. Erst wenn die Bridge erstellt wurde, soll man die beiden Ports wieder mit der Fritzbox und dem Switch verbinden.

Jetzt klappt es auf einmal, warum gestern denn nicht.

Wichtig ist, dass keine der beiden anderen Ports zu dem Zeitpunkt am Switch hängen dürfen, nur das MGMT Interface.

Kommt die Anfrage auf Port 25 überhaupt am WAN an? Es gibt ISPs die den Port von ihrer Seite her Port sperren.

Ihr meint also erst die Bridge erstellen dann die MGMT?

Nein, überhaupt nicht.

Hast Du die IP des MGMT nun mal auf 192.168.178.99 gesetzt und das MGMT Interface an den LAN Switch gehängt? Kurz gesagt, genau wie im Video erklärt, ich kann es nicht anders sagen.

Seine LAN war 192.168.1.0/24, Deins 192.168.178.0/24.

Aber nochmal, dasselbe Subnetz auf mehreren Interfaces geht nicht ohne Bridge. => Kein Routing möglich, und das braucht es auch, um nur auf die Web GUI zu verbinden.

Yep, stimme Dir voll zu. Im Video verbindet er darum nur das MGMT Interface mit dem LAN Switch, bevor er die Bridge erstellt.

Im Video hat er die IP 192.168.2.1, als die MGMT fertig ist stellt er sie auf 192.168.1.99
Das sind für mich zwei verschieden Subnetze.
Auch in der Firewall Rules: MGMT, stellt er die Source auf 192.168.1.0/24 mit der Destination auf MGMT Adresse.
Weil die MGMT Adresse 192.168.1.99 ist

MGMT die Schnittstelle 192.168.1.99
Bridge Schnittstelle 192.168.2.1

Oder verstehe ich da was nicht richtig?

Er hat leider nicht erklärt wie sein bestehendes Netz IP-technisch aussieht (meine ich).

Er hat am Anfang LAN auf .2.1 gewechselt, damit er im nächsten Schritt das MGMT Interface auf .1.99 setzen konnte, in seinem bestehenden LAN.

Die Bridge hat keine IP bekommen, siehe 21:27, es wird keine benötigt.
Damit Du die OPNsense verwalten kannst, ist das MGMT Interface über Dein normales LAN - also .178.99 - erreichbar.