opnsese forwards packets not addressed to its own mac(s)

Started by ingof, February 24, 2021, 01:13:11 AM

Previous topic - Next topic
I have a HA setup with carp running 2 opnsense on a vmware exi5.5 cluster.
Side effect of esxi is, that promiscuous mode needs to be enabled at esxi  virtual switch.

I have following effect now:
Host "C" and "D" are at the same Wan network as the firewall "A"(active) and "B"(backup).
Host "D" and firewall "B" resides at the same esxi.

Host "C" sends a icmp packet to Host "D".
Firewall B also receives the packet (because of promiscuous) and forwards it to Host "D".
The packet firewall "B" accepted from host "C" has the mac address of host "D" in the destination (!) and forwards it then via wan interface to host "D" - with own source mac and destination mac of "D".

Why does the firewall accept a packet not intended for the firewall itself?
This should never ever happen.

please see attached log


Quote from: ingof on February 24, 2021, 01:13:11 AM
Why does the firewall accept a packet not intended for the firewall itself?
This should never ever happen.

What your complaining about is the exact meaning of promiscuous mode, that's what it does to a T.

You can try blocking icmp to your wan with source ip not equal to self.

I use Carp but don't want that the FW pickup and forward various traffic which is not intended for it.

Quote from: ingof on February 25, 2021, 04:27:46 PM
I use Carp but don't want that the FW pickup and forward various traffic which is not intended for it.

The firewall rule should stop that.  Just add both ip's the above suggested firewall rule.

In a carp/failover environment the backup firewall would still forward wrong packets and produce duplicate packets.

Quote from: ingof on February 25, 2021, 07:03:19 PM
In a carp/failover environment the backup firewall would still forward wrong packets and produce duplicate packets.
Not if there is a firewall rule blocking icmp with the correct exclusions as already described above.  Not sure how more clear i can explain it.

Traffic allowed from virtual IP A wan to lan (one-to-one-nat).
Firewall A (active) should forward to lan.
Firewall B (backup) would also forward the traffic also to lan in a "hub" ethernet environment.

Quote from: ingof on February 25, 2021, 07:09:00 PM
Traffic allowed from virtual IP A wan to lan (one-to-one-nat).
Firewall A (active) should forward to lan.
Firewall B (backup) would also forward the traffic also to lan in a "hub" ethernet environment.

That's a completely different scenario. 

#1 there's no hub, it's a switch. 

#2 Your trying to compare unicast tcp/udp traffic with icmp traffic, it's two completely different things, so firewall b would never do that.

#1 this is mentioned in first post
#2 icmp in kernel gets same forwarded as udp/tcp. Fun fact here is - there are also all udp/tcp states synced from the active one.

Quote from: ingof on February 25, 2021, 07:29:52 PM
#1 this is mentioned in first post
#2 icmp in kernel gets same forwarded as udp/tcp. Fun fact here is - there are also all udp/tcp states synced from the active one.

Do you have a pcap of this happening?

try this and see if it works, (this isn't a opnsense problem):

Quoteesxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1

See first post.
And I do a testsetup with opnsense and freebsd 12 now.

Quote from: smyers119 on February 25, 2021, 07:38:04 PM
try this and see if it works:

Quoteesxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1

been there - done that.
This affects broadcast/multicast only.
Without this option carp does not work at all as FW A gets their own carp multicast packets back.

Quote from: ingof on February 25, 2021, 07:38:26 PM
See first post.
And I do a testsetup with opnsense and freebsd 12 now.
#1 first post does not have a pcap.

#2 i posted the solution above

#3 i asked for pcap of unicast traffic duplication

Do you have

"Forged Transmits" and "Mac Address changes" enabled as well?