Recent posts

#1

26.1, 26,4 Series / Re: 2 WAN Uplinks split routin...

Last post by pfry - Today at 06:17:18 AM

[...]the firewall will not determine which circuit the inbound packets come from[...]

For inbound traffic I would differentiate by interface and destination address; destination alone should be fine. I haven't set it up myself (I avoid hinky routing), but I wouldn't expect it to be a problem (could be a bad assumption). But what advantage would an additional L3 device have?

(Heh: My Internet link died right in the middle of posting this. Trying to sell me on a backup?)

#2

French - Français / intégré un DUERP en Direct dan...

Last post by LorcanVale - Today at 05:47:15 AM

Salut tout le monde, Je travaille depuis quelques mois sur la mise en conformité de notre SI avec ISO 27001 et une question revient régulièrement dans les échanges internes: comment articuler l'évaluation des risques sécurité réseau avec le Document Unique d'Évaluation des Risques Professionnels surtout dans sa version dynamique, donc le DUERP en Direct.
Pour ceux qui ne voient pas de quoi je parle, le principe c'est de ne plus traiter le DUERP comme un document qu'on sort du tiroir une fois par an, mais de l'alimenter en continu, au fil des événements. Changement d'infrastructure, déploiement d'un nouvel outil, reconfiguration réseau... chaque modification peut théoriquement déclencher une mise à jour du document.
Et c'est là que ça devient intéressant (ou compliqué, selon le point de vue). Dans notre contexte, on a eu un incident il y a environ trois semaines: une reconfiguration de nos VLANs a été faite un peu vite, et ça a exposé temporairement un segment qui n'aurait pas dû l'être. Rien de catastrophique, les logs ont capturé l'anomalie, mais ça a mis en lumière le fait qu'on n'avait aucun mécanisme pour remonter automatiquement ce type de changement vers le document de gestion des risques RH/opérationnels. est-ce que des équipes sécurité réseau ici ont réussi à connecter leurs outils de monitoring (SIEM, SOAR ou autre) à une plateforme de gestion du DUERP, de façon à avoir quelque chose qui ressemble vraiment à du temps réel ? Ou est-ce qu'on est encore majoritairement dans du manuel, avec un responsable qui fait le lien à la main entre les tickets d'incident et la mise à jour du document ?

#3

26.1, 26,4 Series / Re: WAN interface passing to p...

Last post by glenb2 - Today at 05:22:45 AM

I have a pretty simple setup. I have LAN, WAN, WG0(Wireguard), and IOT interfaces. My IOT network prevents internal communication using a rule that only allows internet access, by using an alias that describes RFC1918 ranges and a rule that allows traffic excluding the alias ranges using the invert option in the rule. Mu LAN interface runs on 192.168.10.X. My WG0 interface runs on 10.14.x.x. WAN interface has block private and bogon networks enabled.

I use a destination NAT rule to force all DNS requests to use pihole, then I use OPNsense unbound as the upstream server.

OPNsense runs on top of Proxmox (forbidden router I know)

I looked up port 7000, and while I do use MacOS and Apple products, I don't have any devices at these addresses. They are all in the LAN interface range. I have pinged these addresses and there is no response.

Thanks again for the response!

#4

26.1, 26,4 Series / Re: WAN interface passing to p...

Last post by wincent - Today at 04:55:47 AM

This should be a default rule. Can you provide more information? Interfaces or directions

#5

26.1, 26,4 Series / Re: WAN interface passing to p...

Last post by glenb2 - Today at 04:29:41 AM

Thanks for the response. Yes, my WAN ip has a public address ending in .235

#6

26.1, 26,4 Series / Re: WAN interface passing to p...

Last post by wincent - Today at 04:11:46 AM

Is your WAN interface bound to a public IP address? x.x.x.235?

#7

26.1, 26,4 Series / Re: 2 WAN Uplinks split routin...

Last post by wincent - Today at 04:01:15 AM

The firewall only handles the outbound load balancing, for inbound traffic, if PBR is not deployed in your front-end, the firewall will not determine which circuit the inbound packets come from. For example, packets from circuit 1 can be replied to through circuit 1 without any problem, but packets from circuit 2 are also replied to through circuit 1 by default, which may cause not be reachable and time out.

#8

Virtual private networks / OSPFv2 through GRE link

Last post by tbk49 - Today at 03:20:43 AM

I need to run OSPF in a little scenario where I am using GRE over IPSec.

I am using FRR plugin and did a simple test by following the first example in the docs (https://docs.opnsense.org/manual/how-tos/dynamic_routing_ospf.html#setup-ospf-between-routers). The other device is not another OPNSense firewall. Yes, I also set the tunable as advised (https://docs.opnsense.org/manual/dynamic_routing.html) and I have set an interface firewall rule allowing ospf protocol traffic input on gre1 interface (I turned off the automatic firewall rule option per the referenced doc).

The problem is there is no communication from the firewall. To verify, I run tcpdump from the firewall cli to sniff the gre1 interface and I can only see the neighbor's hello packets. I am noticing a lot of warnings in FRR log file (Routing | Diagnostics | Log) such as the following:

Code Select Expand

ospfd - interface gre1: 172.16.3.1: ospf_read network address is not same [172.16.3.2]
The GRE interface is on 172.16.3.0/30. The firewall is *.1 and neighbor *.2.

#9

26.1, 26,4 Series / WAN interface passing to priva...

Last post by glenb2 - Today at 03:00:03 AM

Hello,

Sorry if this is a dumb question, but could someone explain why my WAN interface is passing outward traffic to these networks? These are not even ranges that exist in my internal network.

#10

General Discussion / Re: How do predefined net alia...

Last post by OPNenthu - June 29, 2026, 11:19:50 PM

[...] if I put in any predefined interface net alias into a rule it will allow all the networks from the interfaces in the rules. So if I have a floating rule with interfaceA and interfaceB, sources as exact-host-from-interfaceA-network and the predefined interfaceB net alias, then the rule will still match traffic from interfaceA from any host in that network, instead of just the exact-host-from-interfaceA-network.

A test rule like you describe expands like this on the back end:

You cannot view this attachment.

Code Select Expand

# [prio: 200000]
pass in quick on vlan0.1030 inet from $HOSTS_MGMT to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test
pass in quick on vlan0.1040 inet from $HOSTS_MGMT to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test
pass in quick on vlan0.1030 inet from {(vlan0.1040:network)} to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test
pass in quick on vlan0.1040 inet from {(vlan0.1040:network)} to {any} keep state label "e92ba5aa-e088-4435-8244-1410fd42334b" # test

I can see that using multiple sources in a rule creates a potential hole where any of the sources will pass on either interface.  Maybe two rules would be better than a single rule here to avoid the spoofed source IP problem but then they can't stay in Floating and would change to interface level rules.

I don't see that other sources from vlan0.1030 (the source network for hosts defined in HOSTS_MGMT alias) would pass, unless either the HOSTS_MGMT alias contained a netmask (which they can't) as Patrick suggested, or, the hosts alias contained an incorrect entry.

Another possibility: did you have an active state from a prior rule change?  Maybe it would clear up after a reset.

They have, in pfSense.

Yeah, that's an important distinction too.  It's not safe to read pfSense docs/tutorials and assume floating works the same here.