Topics

Hi there,
after doing the Update my OpnSense is missing wireguard.

In Firmware -> Plugins it is shown as "missing".

os-wireguard (missing)   N/A   N/A   N/A   N/A   N/A

At the end of the Line there are two Icons "i" and "+". If I click the "+" for installing the package again it is not found:

***GOT REQUEST TO INSTALL***
Currently running OPNsense 24.1_1 at Fri Feb  2 16:55:50 CET 2024
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'os-wireguard' have been found in the repositories
Checking integrity... done (0 conflicting)
Nothing to do.
***DONE***

Any hints?

Hallo zusammen,

ich habe bei mit Suricata laufen und erhalte durch einen Windowsrechner dauernd "ET SHELLCODE Common 0a0a0a0a Heap Spray String"-Meldungen. Da ich mir die Meldungen per Mail senden lasse und die alle paar Minuten kommen ist das sehr nervig.
Wie mal liest handelt es sich dabei wohl um eine Regel die zu False Positives neigt und anscheinend gerade mit Windows-Updates gerne mal fälschlicherweise anschlägt. Da es auch kein konkretes Angriffspattern ist, sondern eben Heap Spraying würde ich die Regel gerne deaktivieren.

So habe ich die Regel nun unter "Rules" deaktiviert und auch Suricata neu gestartet. Leider bekomme ich dennoch, sobald der Windows-Rechner läuft, die Meldungen vom System.

Kann mir jemand einen Stoß geben, was ich hier so grundlegend falsch mache? Ich hatte ich in der Vergangenheit schon andere Meldungen deaktiviert (z.B. .cc-Domains, da ich gerne dict.cc nutze), was da immer funktionierte.

Vielen Dank

Hallo zusammen,

ich möchte gerne meine Sense als Mailrelay nutzen, so dass die Systeme im internen Netz Mails an die Sense senden können und diese die Mails dann über einen öffentlichen Mailserver versenden.

Hierzu gab es auch schonmal eine Unterhaltung mit dem Ergebnis, dass diese Funktion hinzugefügt wurde: https://forum.opnsense.org/index.php?topic=7538.0

Leider steht hier gar nicht dabei wie das nun umzusetzen ist.
Ich habe das Plugin os-postfix installiert und habe es so konfiguriert, dass ich nun ohne Authentifizierung Mails von internen VLients in die Welt senden kann.
Was mir jedoch fehlt ist eben eine Authentifizierung an der Sense. Ich habe einen neuen User angelegt, finde allerdings keine Option um hier ein sasl für den smtpd zu setzen.

Auch kann ich nicht über den Smartrelay (in meinem Fall posteo) senden, ich kann nur direkt von der Sense an den Zielserver zustellen (damit komme ich z.B. nicht auf gmail-Adressen).

Ich habe eine Reolink-IP-Kamera die Mails bei Bewegungserkennung versenden kann. Das Interface der Kamera verlangt allerdings zwingend die Angabe einer Mailadresse und eines Passworts zur Authentisierung. Lasse ich die Felder einfach leer, kann ich die Konfiguration nicht speichern da es Muss-Felder sind. Ich will die Kamera aber nicht direkt ins Internet lassen damit sie mit einem Mailserver reden kann. Daher würde ich auch hierfür gerne die Sense nutzen, aber brauche wohl eine Authentisierung.

Gibt es hier evtl. jemand der mir hier einen guten Tipp geben könnte?

Hallo zusammen,

ich habe auf der Opnsense einen VPN aktiviert mit dem ich meine Mobilgeräte ins interne Netzwerk hole. Zusätzlich verwende ich "UDP Broadcast Relay" um Multicast-Messages (wie MDNS und SSDP) zwischen den VLANs zu verteilen. Das funktioniert auch grundsätzlich gut, nur kann ich es nicht für die Teilnehmer im VPN verwenden, da das VPN bei den Relay-Interfaces nicht zur Auswahl steht.

Das ist sehr schade, da ich damit einige Funktionen nicht nutzen kann, die ich gerne nutzen würde. Habt ihr da eine Idee für mich wie ich das noch umsetzen könnte?

Dankeschön!

[und auf dem Smartphone]

Hallo zusammen,

ich habe mein Netzwerk zu Hause angepasst und stolpere leider über ein sehr nerviges Problem bzgl. mDNS und hoffe ihr könnt mir auf die Sprünge helfen.

Ich habe einen Raspberry im Netzwerk der mittels Raspotify als "Spotify-Connect" Lautsprecher Musik abspielen soll. Gesteuert wird das Ganze über die Spotify-App die entweder auf dem Smartphone oder auf dem Notebook läuft. Alle Geräte befinden sich in unterschiedlichen vlans. Spotify benötigt mDNS um den Lautsprecher zu finden. Leider funktioniert das nur vom Notebook aus und nicht vom Smartphone. Ich bin mittlerweile etwas hilflos...
Das schönste Phänomen ist allerdings das folgende:

• Der Rasperry ist gebootet
  
• Ich starte die App auf dem Handy
  
• Der Raspberry wird nicht gefunden (ich kann warten bis St. Nimmerlein)
  
• Ich starte die Spotify-App auf dem Notebook
  
• Der Raspberry erscheint sofort als Lautsprecher auf dem Notebook und auf dem Smartphone
  

Auf mich macht es also den Eindruck als kämen die mDNS-Anfragen aus dem WLAN-Netz nicht beim Raspberry an. Sobald das Notebook jedoch seine Anfrage losschickt bekommt das auch das Smartphone mit. Aber evtl liege ich auch völlig daneben.
Sobald ich das Notebook in das WLAN hänge findet es den Lautsprecher auch nicht mehr.

Im Anhang ist eine schematische Darstellung des Netzwerks.

• 3 vlans
  
  
  
  • vlan10: vertrauenswürdige Geräte die per Ethernet verbunden sind (mein Notebook)
    
  • vlan50: vertrauenswürdige Geräte die per WLAN verbunden sind (mein Smartphone)
    
  • vlan70: Lautsprecher. Hier ist der Raspotify verortet
    
• Die vlans werden durch eine OpnSense verbunden
  
• Spotify benötigt mDNS zum Discovery der Lautsprecher (224.0.0.251:5353)
  
• Auf der OpnSense ist das Plugin UDP Boradcast Relay konfiguriert um die mDNS-Pakete in die anderen Netze zu befördern.
  
  
  
  • Alle drei vlans sind eingetragen
    
  • Wie man am Notebook sieht scheint das ja auch grundsätzlich zu funktionieren
    
• Smartphone ist ein Android
  
• Notebook ist ein Linux mir Spotify-Linux-App
  
• Raspotify ist ein Raspbian
  
• WLAN AP ist ein Mikrotik, nachdem ich dachte, dass ich zu blöd bin das Ding zu konfigurieren habe ich es jedoch auch mit einem alten TP-Link mit OpenWRT versucht mit identischem Ergebnis.
  

Auch an den Firewall-Regeln auf der OpnSense könnte ich nun nicht erkennen wo da Problem liegen sollte:
Für das Lautsprecher-Netz

Code Select Expand


pass in quick on lagg0_vlan70 inet proto udp from (lagg0_vlan70:network) to 239.255.255.250 port = 1900 keep state
pass in quick on lagg0_vlan70 inet proto udp from (lagg0_vlan70:network) to 224.0.0.251 port = mdns keep state
pass in quick on lagg0_vlan70 inet proto tcp from (lagg0_vlan70:network) to <InterneDNS> port = domain flags S/SA keep state
pass in quick on lagg0_vlan70 inet proto udp from (lagg0_vlan70:network) to <InterneDNS> port = domain keep state
block drop in quick on lagg0_vlan70 inet from any to <InternetRouter>
block drop in quick on lagg0_vlan70 inet from any to (self)
pass in quick on lagg0_vlan70 route-to (igb0 192.168.1.1) inet from (lagg0_vlan70:network) to any flags S/SA keep state


Für das Trusted-Netz

Code Select Expand


pass in quick on lagg0_vlan10 inet proto icmp from (lagg0_vlan10:network) to any keep state
pass in quick on lagg0_vlan10 inet proto tcp from any to <InterneDNS> port = domain flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto udp from any to <InterneDNS> port = domain keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = lupa flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = 60006 flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = http flags S/SA keep state
pass in quick on lagg0_vlan10 inet proto udp from (lagg0_vlan10:network) to 224.0.0.251 port = mdns keep state
pass in quick on lagg0_vlan10 inet proto udp from (lagg0_vlan10:network) to 239.255.255.250 port = 1900 keep state
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to (lagg0_vlan70:network) port = ssh flags S/SA keep state
block drop in quick on lagg0_vlan10 inet from any to (self)
block drop in quick on lagg0_vlan10 inet from any to <InternetRouter>
pass in quick on lagg0_vlan10 route-to (igb0 192.168.1.1) inet from (lagg0_vlan10:network) to any flags S/SA keep state


Für das WLAN-Netz

Code Select Expand


pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to <InterneDNS> port = domain flags S/SA keep state
pass in quick on lagg0_vlan50 inet proto udp from (lagg0_vlan50:network) to <InterneDNS> port = domain keep state
pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = lupa flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = 60006 flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = http flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port = rtsp flags S/SA keep state
pass in log quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to (lagg0_vlan70:network) port 49152:49154 flags S/SA keep state
pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to 224.0.0.251 port = mdns flags S/SA keep state
pass in quick on lagg0_vlan50 inet proto tcp from (lagg0_vlan50:network) to 239.255.255.250 port = 1900 flags S/SA keep state
block drop in quick on lagg0_vlan50 inet from any to <InternetRouter>
block drop in quick on lagg0_vlan50 inet from any to (self)
pass in quick on lagg0_vlan50 route-to (igb0 192.168.1.1) inet from (lagg0_vlan50:network) to any flags S/SA keep state


Vielleicht kann mir jemand einen Tipp geben warum das über das WLAN nicht funktioniert. Vielen Dank!

Edit: Ich habe mal ein Packet Capture der drei Interfaces gezogen und in Wireshark geworfen. Vom vlan50 kommen definitiv keine mDNS-Pakete im vlan70 an. Vom vlan10 jedoch kommen die mDNS-Pakete

Hey there,
I deactivated the automatic anti-lockout-rules because they were put only on my IoT-VLAN-Interface (which doesn't make much sense). I have a seperate vlan for management-purpose (vlan90 and the OpnSense listens there on IP 10.10.90.1/24 for https and ssh). So I wanted to create my own anti-louckout-rules to allow my trusted network (vlan10 10.10.10.0/24) to connect there.
I created the following rules for my "Trusted" interface (see also attachment).

Code Select Expand


PASS in quick IPv4 TCP Trusted net * 10.10.90.1 443 (HTTPS) * * /!\ ANTI LOCKOUT /!\
PASS in quick IPv4 TCP Trusted net * 10.10.90.1 22 (SSH) * * /!\ ANTI LOCKOUT /!\


Well the rule for https is working, I can connect to the WebGui. But the rule for ssh is not working. That said I logged in to the OpnSense and did a

Code Select Expand

pfctl -s rules and found that the ssh-rule isn't even there. I only find the rule for https:

Code Select Expand

pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to 10.10.90.1 port = https flags S/SA keep state label "347979aabfc8b8e68a6b5c3fccb9ee7e" but no rule for the ssh traffic.

Code Select Expand

root@opnsense:~ # pfctl -s rules | grep 10.10.90.1
pass in quick on lagg0_vlan10 inet proto tcp from (lagg0_vlan10:network) to 10.10.90.1 port = https flags S/SA keep state label "347979aabfc8b8e68a6b5c3fccb9ee7e"

Could you give me a hint what  could do?! I already edited the rule several time, pushed it to different places in the ruleset and even did a reboot.

Thanks for your help, cause I feel not very confident.

Hey there,
I am currently dividing my network in several vlans. Doing this I created a vlan where I connected my Denon Heos speakers to, to separate them from the rest of my network. In another vlan I have my smartphone (and other trusted components) that should control the speakers.
It got it up and running, but am not that happy, and am not sure if I did it the right way.
I installed the service UDP Broadcast Relay and added a line for each multicast-call the speakers should need (see attachment).
After this I added a firewall-rule for every interface (controller-vlan and speaker-vlan) as "in"-rules to allow access to exactly those destinations (239.255.255.250:1900 and 224.0.0.251:5353).
But I am not sure if I have to allow the traffic in both directions (well it seems it only works this way). But as a side-effect, if I run mdns-scan in the speaker-vlan I can see services (smb, sftp) running in my "trusted" vlan, which sould not be visible to the speakers. Well, the speakers can not access those services due to firewall-rules but it feels wrong that those services are even found. Can I somehow control that those services are not seen?

Denon posted some informations which ports need to be opened to run those speakers, but there is no information in which direction this traffic is established, of what destination the traffic is send to (internet, controller, speaker). This makes it difficult to set the right firewall-rules: https://support-uk.denon.com/app/answers/detail/a_id/4717/~/network-requirements-for-heos

Hi there,

i have divided my network in several vlans. Its working well for typical usage, but I am running streaming speakers from Denon Heos which rely on multicast packets afaik. I don't get it how to set this up. Maybe someone can give me some hints, as I could not find much info.

I have speaker sitting in vlan70 and my smartphone which I need to control the speakers is in vlan 10. I already installed IGMP proxy, but I don't understand how to set it up?!

I the devices are conected by a cisco switch (small business 300), do I have to add there some settings too (igmp snooping)?

I'd really be happy if someone could give me some help.
Thanks

Well for the start I would be happy if I could use them with spotify (als spotify-connect speakers)

Hallo zusammen,

ich würde gerne eine Liste von IP-Adressen blocken. Es handelt sich dabei um folgende Liste: https://block.energized.pro/extensions/ips/formats/list.txt

Ich habe dazu unter Firewall->Aliases eine URL Table (IPs) angelegt und unter Content die URL zur Liste eingetragen.
Leider wird die Liste aber nicht aktuallisiert. Wenn ich unter Firewall->Diagnostics->pfTables den Alias auswähle ist er leer.

Was mich nur so wundert ist, dass ich das schonmal für eine andere IP-Liste gemacht hatte und das geht.
Liegt es daran, dass in der IP-List Kommentare enthalten sind?

Hallo zusammen,

ich setze OPNsense 20.7.7_1-amd64 ein und habe sie zwischen meiner Fritzbox und meinem internen Netzwerk hängen. Mal ein ein Versuch das ganze etwas darzustellen:

Code Select Expand


                    ----------------------        Zwischennetz      ----------------------------------------------------       Internes Netzwerk
( Internet )  ---- [ FritzBox 192.168.1.1 ] --- 192.168.1.0/24 --- [ 192.168.1.2 (igb0) - OpnSense - (igb1) 192.168.2.1 ] ----- 192.168.2.0/24
                    ----------------------                          ----------------------------------------------------


Ich habe aktuell kein NAT (mehr) aktiv.
Die Rules aus Firewall -> Diagnostics -> pfInfo -> Rules sehen so aus (ich habe mal nur die Rules an sich gepastet und die labels raus gelassen - da das nur IDs sind helfen die wohl nicht viel):

Code Select Expand


@0 scrub on lo0 all fragment reassemble
@1 scrub on igb1 all fragment reassemble
@2 scrub on igb0 all fragment reassemble
@0 block drop in log on ! igb1 inet from 192.168.2.0/24 to any
@1 block drop in log inet from 192.168.2.1 to any
@2 block drop in log on ! igb0 inet from 192.168.1.0/24 to any
@3 block drop in log inet from 192.168.1.2 to any
@4 block drop in log on igb1 inet6 from fe80::20d:b9ff:fe43:4bf5 to any
@5 block drop in log on igb0 inet6 from fe80::20d:b9ff:fe43:4bf4 to any
@6 pass in log quick on lo0 inet6 all flags S/SA keep state
@7 block drop in log quick inet6 all
@8 block drop in log inet all
@9 block drop in log inet6 all
@10 pass in log quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
@11 pass in log quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
@12 pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
@13 pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
@14 pass out log quick inet6 proto ipv6-icmp from (self:5) to fe80::/10 icmp6-type echorep keep state
@15 pass out log quick inet6 proto ipv6-icmp from (self:5) to ff02::/16 icmp6-type echorep keep state
@16 pass out log quick inet6 proto ipv6-icmp from (self:5) to fe80::/10 icmp6-type routersol keep state
@17 pass out log quick inet6 proto ipv6-icmp from (self:5) to ff02::/16 icmp6-type routersol keep state
@18 pass out log quick inet6 proto ipv6-icmp from (self:5) to fe80::/10 icmp6-type routeradv keep state
@19 pass out log quick inet6 proto ipv6-icmp from (self:5) to ff02::/16 icmp6-type routeradv keep state
@20 pass out log quick inet6 proto ipv6-icmp from (self:5) to fe80::/10 icmp6-type neighbrsol keep state
@21 pass out log quick inet6 proto ipv6-icmp from (self:5) to ff02::/16 icmp6-type neighbrsol keep state
@22 pass out log quick inet6 proto ipv6-icmp from (self:5) to fe80::/10 icmp6-type neighbradv keep state
@23 pass out log quick inet6 proto ipv6-icmp from (self:5) to ff02::/16 icmp6-type neighbradv keep state
@24 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state
@25 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state
@26 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
@27 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
@28 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
@29 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
@30 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
@31 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
@32 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
@33 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
@34 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state
@35 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state
@36 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state
@37 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state
@38 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state
@39 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type echoreq keep state
@40 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routersol keep state
@41 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routeradv keep state
@42 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbrsol keep state
@43 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbradv keep state
@44 block drop in log quick inet proto tcp from any port = 0 to any
@45 block drop in log quick inet proto udp from any port = 0 to any
@46 block drop in log quick inet6 proto tcp from any port = 0 to any
@47 block drop in log quick inet6 proto udp from any port = 0 to any
@48 block drop in log quick inet proto tcp from any to any port = 0
@49 block drop in log quick inet proto udp from any to any port = 0
@50 block drop in log quick inet6 proto tcp from any to any port = 0
@51 block drop in log quick inet6 proto udp from any to any port = 0
@52 block drop in log quick proto carp from (self:9) to any
@53 pass log quick proto carp all keep state
@54 block drop in log quick proto tcp from <sshlockout:0> to (self:9) port = ssh
@55 block drop in log quick proto tcp from <sshlockout:0> to (self:9) port = https
@56 block drop in log quick from <virusprot:0> to any
@57 block drop in log quick on igb0 inet from <bogons:1294> to any
@58 pass in log quick on lo0 all flags S/SA keep state
@59 pass out log all flags S/SA keep state allow-opts
@60 pass in log quick on igb1 proto tcp from any to (self:9) port = ssh flags S/SA keep state
@61 pass in log quick on igb1 proto tcp from any to (self:9) port = http flags S/SA keep state
@62 pass in log quick on igb1 proto tcp from any to (self:9) port = https flags S/SA keep state
@63 pass out log route-to (igb0 192.168.1.1) inet from 192.168.1.2 to ! (igb0:network:1) flags S/SA keep state allow-opts
@64 block drop log quick on igb1 inet from any to <blocklist_de:31888>
@65 block drop log quick on igb0 inet from any to <blocklist_de:31888>
@66 block drop log quick on igb1 inet from <blocklist_de:31888> to any
@67 block drop log quick on igb0 inet from <blocklist_de:31888> to any
@68 pass in quick on openvpn inet from 10.10.0.0/24 to any flags S/SA keep state
@69 pass in quick on igb0 reply-to (igb0 192.168.1.1) inet proto udp from any to any port = openvpn keep state
@70 pass in quick on igb1 inet from (igb1:network:1) to any flags S/SA keep state
@71 pass in quick on igb1 inet6 from (igb1:network:*) to any flags S/SA keep state

Die Regeln hat OpnSense so erzeugt (bzw die Blocklist_de habe ich als Floating hinzugefügt), daher sind die z.T. etwas redundant.

IPv6 habe ich deaktiviert.
10.10.0.0/24 ist das Netz für mein OpenVPN.

Wenn ich nun aber unter Firewall -> Log Files -> Live View sehe finde ich unter Anderem folgende blocks (die xxx.xxx.xxx.xxxx habe ich mal anonymisiert. Die Services unter der IP kann ich aber ganz normal erreichen):

Code Select Expand


lan -> Dec 31 14:14:03 192.168.2.250:39080 xxx.xxx.xxx.xxx:443 tcp Default deny rule


Mir ist kein Funktionseinschränkung aufgefallen (unter Anderem war hier auch bereits mein Mailserver gelistet - aber mein Mailer funktioniert astrein) und betreibe das Ganze nun auch schon einige Monate. Ich verstehe aber nicht wo diese Blocks herrühren, denn nach dem Regelwerk müssten die Pakete meiner Meinung nach durchgehen (entsprechend Regel 70). Und die Tatsache, dass ja alles Services funktionieren sagen ja auch, dass es eigentlich gehen müsste. Die 192.168.2.250 ist übrigens mein Notebook, aber ähnliche Blocks habe ich auch von anderen Clients im Netz schon gesehen.


Vielen Dank für eure Hilfe.

Hey there,

I have the following setup:

[public IP - Router from ISP - 192.168.1.1] --- 192.168.1.0/24 --- [192.168.1.2 - OPNsense - 192.168.2.1] --- 192.168.2.0/24 internal LAN

So the interface WAN in my OPNsense has the IP 192.168.1.2 and the interface LAN has the IP 192.168.2.1.
I activated NetFlow listening on both interfaces. As WAN-Interface it set my WAN-Interface (and I also tried setting both there).

But when I see the detailed log of Insight and filter for the Interface LAN I can see connections with source-IP 192.168.1.2 (the IP-adress of my WAN-Interface) and destination-adresses in the internet. This are connections that are present from devices from my local LAN (192.168.2.0/24) into the internet, so this traffic looks ok to me. But why do I see traffic filtered to the LAN-Interface with source-IP of the WAN-side connecting to the internet?!

Can you give me a hint?!

Thanks a lot