Messages

1

24.1 Legacy Series / Re: Bridge Looping Issue: Need Help with STP Activation

« on: February 19, 2024, 02:22:35 pm »

this shown schema is just a small part of the big picture, so i need to handle this with VLANs. i will refactor this problem with access ports only and will give you a feedback. but in the end, i should resolve it with VLAN instead.

mybe you have another tool for me to debug STP that will show why it will not work? some missing packages or what ever?

2

24.1 Legacy Series / Re: Bridge Looping Issue: Need Help with STP Activation

« on: February 19, 2024, 01:33:37 pm »

for now, i have active "private VLAN" on switch0, it is working just now, but not really what i want. The layer 2 traffic is still being forwarded to switch0 as a result, which I would like to avoid.

what do you mean with "untagged interface" ? i have create an VLAN Interface (vlan0.0.50 - parent eth0), this will bring the vlan already as untagged packages into the bride, or i'm wrong?

3

24.1 Legacy Series / Re: Bridge Looping Issue: Need Help with STP Activation

« on: February 19, 2024, 11:21:49 am »

hmmm, i'm wrong, the issue is still there. STP isnt working and setting up the bridges up and down seems to be more complicated as first seen i have to write a more complex script to reattach all members back to bridge. sad

4

24.1 Legacy Series / Re: Bridge Looping Issue: Need Help with STP Activation

« on: February 16, 2024, 01:09:10 pm »

Oh, sorry! It's the usual "rubber duck" thing. Thank you for talking about it. After I double-checked all the settings and realized that I hadn't correctly specified the STP interfaces in full, I couldn't detect any loop problems after the correction. Now it's working! Many thanks!

5

24.1 Legacy Series / Bridge Looping Issue: Need Help with STP Activation

« on: February 15, 2024, 03:55:52 pm »

Code: [Select]

┌───────────────────────────────────┐
│ Firewall 1                        │
│            ┌───────────┐          │
│     ┌──────┤ vlan0.0.50├──┐  ┌────┤
│     │      └───────────┘  └──┤eth0├────────────────────────┐
│ ┌───┴───┐                    └────┤                        │
│ │       │                         │                        │
│ │bridge0│                         │                        │
│ │       │                         │                        │
│ └───┬───┘                    ┌────┤                        │
│     │      ┌───────────┐  ┌──┤eth1├──────────┐             │
│     └──────┤ vlan0.1.50├──┘  └────┤          │             │
│            └───────────┘          │          │             │
│                                   │     ┌────┴─────┐  ┌────┴─────┐
└───────────────────────────────────┘     │          │  │          │
                                          │  switch1 │  │  switch0 │
┌───────────────────────────────────┐     │          │  │          │
│ Firewall 2                        │     └────┬─────┘  └────┬─────┘
│            ┌───────────┐          │          │             │
│     ┌──────┤ vlan0.0.50├──┐  ┌────┤          │             │
│     │      └───────────┘  └──┤eth0├──────────┼─────────────┘
│ ┌───┴───┐                    └────┤          │
│ │       │                         │          │
│ │bridge0│                         │          │
│ │       │                         │          │
│ └───┬───┘                    ┌────┤          │
│     │      ┌───────────┐  ┌──┤eth1├──────────┘
│     └──────┤ vlan0.1.50├──┘  └────┤
│            └───────────┘          │
│                                   │
└───────────────────────────────────┘

Hello, I have a problem with a loop that I get with an HA configuration over two OPNsense firewalls. I have a bridge on each firewall, and each bridge is bridged to a VLAN via two paths. As can be seen from the diagram, a loop must occur here, unfortunately I need this setup exactly like this. As soon as I set up the setup like this, I have a loop and everything comes to a standstill. Even various attempts to activate STP have not clue, which I also don't really understand.
In terms of HA, I have built myself a sys hook: /usr/local/etc/rc.syshook.d/carp/10-handle-briges.
This script does an ifconfig bridge0 up/down according to the CARP status (MASTER or not MASTER). Basically, this works quite well, but unfortunately not when I restart the firewall. When booting up, CARP takes effect and the bridge is shut down, unfortunately in the following boot process it is detected that the bridge has dependencies, it is configured and thereby brought back up, and I am back to my loop.

Ideally, I should be able to counteract all of this with STP, but it's not working. Does anyone have any idea why not? The attempt to bypass the whole thing using a hook and bringing the bridge up and down is just a workaround; here, I would still need an idea of how to immediately bring the bridge back down in case it is brought back up, depending on the CARP status. My current approach is to write a file (/tmp/carp-status.flag) to check in another script whether the bridge should be up or down, and then to correct this immediately if necessary. Unfortunately, I haven't found a hook yet that I could use as soon as the bridge is brought back up. Maybe with the devd stuff? But I haven't figured out yet how to register for an event here, maybe somewhere in /usr/local/etc/inc/plugins.inc.d/?

Perhaps someone can give me an idea or question everything again and guide me in the right direction?

Greetings, Volker

6

High availability / Issue with CARP and Source Address on WAN Interface

« on: November 21, 2023, 04:03:17 pm »

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

7

23.7 Legacy Series / Re: Filter DHCP Requests on Bridge

« on: October 30, 2023, 11:15:01 am »

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

8

23.7 Legacy Series / Re: Filter DHCP Requests on Bridge

« on: October 30, 2023, 09:21:22 am »

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.

9

23.7 Legacy Series / Re: Filter DHCP Requests on Bridge

« on: October 27, 2023, 01:17:39 pm »

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]

# 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?)

10

23.7 Legacy Series / Re: Filter DHCP Requests on Bridge

« on: October 27, 2023, 11:59:30 am »

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

11

23.7 Legacy Series / Filter DHCP Requests on Bridge

« on: October 27, 2023, 11:28:24 am »

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]

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


12

23.1 Legacy Series / Re: Update from 22.7 to 23.1 prevents Web GUI from listening on Wireguard interface

« on: August 08, 2023, 12:56:55 am »

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]

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

Code: [Select]

#!/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]

chmod +x /usr/local/etc/rc.syshook.d/start/51-wireguard-ext
reboot your system and you are fine

13

German - Deutsch / WAN PPPoE IPv6 only

« on: June 22, 2023, 12:31:08 am »

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?

14

General Discussion / Re: OPNsense Rewrite Discussion

« on: June 13, 2023, 03:49:15 pm »

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).

15

General Discussion / Re: OPNsense Rewrite Discussion

« on: June 13, 2023, 02:57:13 pm »

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?