Messages

Hello Community,

I'm facing a problem with OPNsense configuration, and I'm hoping someone in the community can help me out.

Here's my setup:

- OPNsense with a WAN interface without a fixed IP address.
- Multiple virtual IPs from a /29 subnet are bound to the WAN interface using CARP.

The problem arises when more than one IP is bound to the WAN interface. Packets originating directly from the firewall have an "0.0.0.0" source address. Since the firewall no longer knows which IP to use for internet communication (as the default route only defines the interface), confusion arises.

I attempted to address this by creating an outbound NAT rule, specifying "any" to "!bougen" via the WAN interface. However, this rule only takes effect when "any" is selected as the source. When I set the source as "this firewall," the NATing doesn't work.

Does anyone have a solution or the correct approach to address this issue?

Thank you in advance for your assistance!

Best regards,
volker

Certainly, the Wi-Fi network is provided externally and is not under the control of OPNsense. I have multiple remote locations connected via VXLAN and terminated on a bridge (I can control traffic between these locations through private ports). However, within this bridge, there is an additional port connected to an external NAC system and another remote location with numerous Wi-Fi devices. My predicament arises from the fact that this traffic is inundating my VXLAN external locations. So, as we discuss these issues, I've come to realize that I am inadvertently overwhelming the other external Wi-Fi network with my VXLAN traffic (facepalm). The only proper solution to this problem is to connect the external Wi-Fi network to my bridge as a private port and then redirect all the traffic to the external NAC through the only non-private bridge port.

thx, to be my rubberduck ;)

What concern are you attempting to address by blocking DHCP traffic?  Perhaps a bridge is not the right solution for what you're attempting to do.

If you don't use a bridge then you can separate each group into their own subnet and they won't see any traffic that you don't expressly allow.

In the end, I am operating a Wi-Fi network with a central Network Access Control (NAC). As a result, I need to utilize a Layer 2 network to transmit client MAC addresses. I am contemplating the creation of a new dedicated Linux-based gateway to manage these tasks. Initially, I will attempt to address certain issues by forcibly converting some broadcasts into unicast traffic directly to my NAC. However, I currently lack a concrete plan for handling ARP-related matters.

so opnsense can not handle broadcast traffic? what about L2 traffic? i also want to limit some ARP traffic. befor switchging to opnsense, i have already done this with linux (ubuntu). here are some of my rules to handle all this stuff:

Code Select Expand


# isolate bridge - preventing to breakout from the bridge
ip link set dev br100 type bridge vlan_filtering 1

# supress trash traffic
bridge link set dev vxlan100.2 mcast_flood off
ebtables -A FORWARD -i cw100 -o vxlan100.2 -d ff:ff:ff:ff:ff:ff -j DROP

#isolate remote-gateways tunnels
bridge link set dev vxlan100.2 isolated on


can i do this also with opnsense (with or without GUI?)

thx, but i can not see any auto-generated rules on my bridge? and also not on intf1 ...

Hi,
I want to ensure that the DHCP traffic from clients 1 and 2 doesn't get forwarded to clients 3 and 4. I've created a rule on the bridge to block everything with a destination port of 67, but this rule is being ignored, and it's not exactly what I want. Ideally, I would like to apply this only to packets coming in on interface 1. Does anyone have an idea on how I could achieve this?

Code Select Expand


             +-----------------------+
             |Third-Party DHCP Server|
             +-------------+---------+
+--------+                 |
|Client 1+--------------+  |
+--------+              |  |
                      +-+--+-+
                      |Switch|
                      +-+--+-+
+--------+              |  |
|Client 2+--------------+  |
+--------+                 |
                           |
                           |
     +---------------------+---------+
     |OpnSense             |         |
     |          +-------+--+--+---+  |
     |          |       |Intf1|   |  |
     |          |       +-----+   |  |
     |          |                 |  |
     |          |Bridge 1   +-----+  |
     |          |           |Intf2+--+----+
     |          +-----------+-----+  |    |
     |                               |    |
     +-------------------------------+    |
                                          |
                                          |
              +--------+                  |
              |Client 3+------+        +--+---+
              +--------+      +--------+Switch|
                                       +--+---+
                                          |
              +--------+                  |
              |Client 4+------------------+
              +--------+


hmmm, i was running also in this pitfall :( i want to listen the web gui on my wireguard interface, here is my current work around:

configre your system to listen on all interfaces or dedicated to e.g. LAN + WG0

create a new file:

Code Select Expand

/usr/local/etc/rc.syshook.d/start/51-wireguard-ext
paste this content into it:

Code Select Expand

#!/bin/sh

# restart web ui in hope to listen also on wireguard interface
/usr/local/etc/rc.restart_webgui

# restart ssh to also listen on wireguard interface
configctl openssh restart

and also set the execution flag to this file:

Code Select Expand

chmod +x /usr/local/etc/rc.syshook.d/start/51-wireguard-ext

reboot your system and you are fine ;)

Moin!
Ich habe ein Internetanschluss der IPv6 only ist und über PPPoE die Einwahl erfolgt. Bisher konnte ich diesen Zugang noch nicht wirklich zum fliegen bekommen. Habe etliche kombinationen am WAN Interface versucht, die PPPoE Einwahl ist erfolgreich, aber irgendwie bekommen ich keine IPv6 kram der von der opnsense sinnvoll verarbeitet werden kann.

anbei mein aktuelles setting, beim WAN interface habe ich schon alle kombinationen für "DHCPv6 client configuration" versucht. interessant ist, wenn ich "Use IPv4 connectivity" nutze, kommt der "DHCP:  DHCPv6" nicht "up" (siehe bild1.png).

ist alles recht seltsam. natürlich funzt das ganze mit der mitgelieferten fritzbox. gleicher ISP mit anderen zugangsdaten die IPv4 zugangsdaten sind läuft alles problemlos.

noch jemand eine idee für mich?

So, actually, I wanted to initiate a discussion about whether OPNsense should be rebuilt in a "better" way. As I have now learned, there are already efforts underway to do so, and I have already seen them and assessed them as improvable based on my standards. Therefore, it seems that a "rewrite" is already in progress from the core OPNsense developers, and my original intention to give it a push is essentially unnecessary.

I actually think your idea of using Linux as the basis for a firewall is not a bad idea at all. Of course, it would require rewriting everything, which was also my main idea. The thing is, I'm a big fan of OPNsense and use it whenever I can—it's truly a great achievement! However, the underlying code hasn't fully convinced me so far. But that's okay, as long as I don't make it better myself and just talk about it, it remains the best code there is ;)

Currently, I'm in the preparations of writing a NAC (Network Access Control) system, and I briefly considered using OPNsense as a base. However, since I'm not entirely satisfied with the technical implementation, I'll probably end up rewriting everything from scratch. Since I have no qualms about starting anew, I'm reimplementing various protocols/services in PHP completely from scratch. For example, I've already done RADIUS (https://github.com/skydiablo/SkyRadius) and DHCP (not yet released), and I'm also working on DNS (not public yet). Now, my remaining challenge is to implement the firewall part. I can either use OPNsense as the firewall and utilize its API, or I can build my own firewall (essentially just an interface for iptables/nftables).

You're right, there's a lack of a Linux firewall! So, if I understand correctly, you're suggesting that the opportunity to write a "new" firewall could be taken as a chance to use Linux instead of BSD, since the train for OPNsense has already left the station, so to speak?

I really don't want to bash anyone here, and at the end of the day, the one who takes action is the one who is right, not the one who just talks about it. The current MVC approach is certainly a good path, but when I look at the current code, it doesn't feel like an enterprise web application to me. Hence, my initial statement: Wouldn't a "greenfield" approach be worth considering?

Okay, so the current system will be migrated to a different codebase "on the fly." What about the challenge of bridging the old and new worlds? Wouldn't a complete rewrite free us from a lot of technical debt?

Hello, has there been any recent attempt to rewrite OPNsense? I wanted to enable the addition of gateways to the Gateway API and therefore took a closer look at the source code of OPNsense. I don't want to say that it's bad, but it does seem quite dated. Not that I want to open a "yet-another-open-source-firewall" fork of OPNsense right away, but at least discussing whether it would make sense?

this is an accepted issue and already fixed in BSD main-line: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261711

is this already merged into the current opnsense kernel? my current tests arent working yet, so i asking.

I was able to help myself! First, I extended my desktop DHCP client config to request DHCP option 125. To do this, I simply added the number 125 to the "request" field in the "/etc/dhcp/dhclient.conf" file.
Then, I queried the already configured ICS DHCP server using the command "sudo dhclient -i eth0". At the same time, in a separate terminal, I ran the tool "dhcpdump -i eth0". As a result, the specific response was displayed, which I was able to adopt 1-to-1.

I hope that this could help someone who may have a similar topic as I did.

regards, volker.