Messages

That would not be the best solution as the subnet is for a particular set of containerised workloads (using maclvan with docker) so both subnets do in fact reach the same physical interface and traffic is co-mingled on the receiving host. Since writing the initial post I have found that if I select "Dynamic Gateway Policy" on the interface and do not assign any static IPs to the interfaces then the static routes start to work. Presumably this is the correct way to do it - though if anyone could confirm if this is the correct way that would be great.

The documentation lacks clarity on configuring static routing for multiple subnets through a single interface. Specifically, I need to route traffic for two different IPv6 subnets (2401:xxxx:xxxx::/64 and fd1a:xxxx:xxxx::/64) via the same interface.

Currently, the interface has a static IP address within the 2401:xxxx:xxxx::/64 subnet. OPNsense automatically created an entry in the routing table for this subnet, so traffic is correctly routed here. For the fd1a:xxxx:xxxx::/64 subnet, I attempted to create a gateway on the same interface.

Creating the gateway required specifying an IP address. I tried both using the actual address and an address within the fd1a:xxxx:xxxx::/64 range. Afterward, I configured a static route for fd1a:xxxx:xxxx::/64, directing it to this newly created gateway.

Despite these steps, traffic destined for the fd1a:xxxx:xxxx::/64 subnet is not being routed correctly. Could someone provide guidance on how to properly configure this setup?

Any assistance would be greatly appreciated.

os-wauh-agent correctly connects to Wazuh and I can see logs from OPNsense in Wazuh. I can also send a test active-response from Wazuh and I can see that this is received by OPNsense. However the alias does not get updated. These are the logs:

Code Select Expand

2025-03-25T02:42:07 wazuh-execd[98236] execd.c 271 at ExecdRun(): DEBUG: Active response won't be added to timeout list. Message not received with alert keys from script 'active-response/bin/opnsense-fw'
2025-03-25T02:42:07 wazuh-execd[98236] execd.c 256 at ExecdRun(): DEBUG: Executing command 'active-response/bin/opnsense-fw {"version":1,"origin":{"name":null,"module":"wazuh-execd"},"command":"add","parameters":{"extra_args":[],"alert":{"data":{"srcip":"172.16.1.30"}},"program":"active-response/bin/opnsense-fw"}}'
2025-03-25T02:42:07 wazuh-execd[98236] execd.c 494 at ExecdStart(): DEBUG: Received message: '{"version": 1, "origin": {"name": null, "module": "API"}, "command": "!opnsense-fw", "parameters": {"extra_args": [], "alert": {"data": {"srcip": "172.16.1.30"}}}}'
2025-03-25T02:42:07 wazuh-agentd[1729] receiver.c 96 at receive_msg(): DEBUG: Received message: '#!-execd {"version": 1, "origin": {"name": null, "module": "API"}, "command": "!opnsense-fw", "parameters": {"extra_args": [], "alert": {"data": {"srcip": "172.16.1.30"}}}}'
The problem is that `active-response/bin/opnsense-fw` does not alter the alias. Has anyone got this working? I am using os-wazuh-agent 1.0_2

[on the switch]

Thanks Patrick and mimugmail. I think there may be a misunderstanding about my question. I am asking about the configuration on the switch. I had thought that the switch (or in my case switches in MLAG) should have no bonding between the ports that connect from the switch to the firewalls because I was under the impression that when a new CARP group master takes over it issues a Gratuitous ARP (GARP). This would mean that, in principle, the switch should see the GARP and update its MAC address table. However, this does not seem to be working - hence my question. For me, when the CARP master changes traffic gets dropped.

Hi mimugmail, I am not sure what you mean by "bond over both members". I don't understand how to get the switch LAGG to play with CARP. Here are the issues as I see them:

Active-backup
The challenge here is ensuring that the switch's active link aligns with the CARP master firewall. Without an automatic mechanism to align the active switch port with the CARP master, this setup could lead to misalignment where the active switch port is connected to the standby firewall.

Broadcast
This guarantees that the active CARP firewall always receives the traffic, regardless of which one is master, but if a firewall leaves the CARP group (say because CARP is disabled for maintenance) it will start handling duplicate traffic.

Here is my setup:

                       VIP (WAN)
                            |
         ------------------------------
         |                                     |
         |                                     |
  -------------     pfSync     -------------
| Firewall 1 | <---------> | Firewall 2 |
  -------------                    -------------
         |                                     |
         |                                     |
         |                                     |
  ------------       MLAG       ------------
| Switch 1 | <-----------> | Switch 2 |
  ------------                      ------------
         |                                     |
         ------------------------------
                            |
                      LACP (LAN)

I have 2 firewalls in a CARP group. Each firewall connects to a Mikrotik switch and these switches are in an MLAG configuration with their onward ports bonded in LACP.

Question: How should the switch ports to the firewalls be configured?

MLAG allows the switches to appear to external hardware as though they are connected to a single switch. Bonds are created across the physical switches (i.e. an LACP bond will have 1 port of the bond on each switch so that an entire switch can go down and the link survive). How should the ports connected to the firewalls be bonded? Clearly LACP is not correct because the firewalls will not negotiate this correctly on their end as the firewalls act independently of each other. My other options are:
- active-backup
- broadcast

Am I correct in assuming that if Switch 1 were to go down that Firewall 1 would detect a dead connection and demote itself and so Firewall 2 take over?