RED60 VLAN bridged - blocked because of invalid traffic IP SPOOF

I read in manual:

Spoof protection general settings

Specify the type of spoof prevention and the zones that you want to protect.

IP spoofing

If the source IP address of a packet does not match any entry on the firewall’s routing table or if the packet is not from a direct subnet, the firewall drops the packet.

.

I would think that a bridge is a direct subnet to the XG but I will test with a dummy FW rule matching this traffic.

I read in manual:

Spoof protection general settings

Specify the type of spoof prevention and the zones that you want to protect.

IP spoofing

If the source IP address of a packet does not match any entry on the firewall’s routing table or if the packet is not from a direct subnet, the firewall drops the packet.

.

I would think that a bridge is a direct subnet to the XG but I will test with a dummy FW rule matching this traffic.

well a default dummy rule within the same net 192.168.xxx.xxx to 192.168.xxx.xxx on any service does not work and is not even processed or logged in fw log. But the traffic is still blocked as IP SPOOF.

Even creating a trusted MAC entry does not work. Has a RED VLAN bridge ever been tested?

Here you can see, connection is still blocked. There are 2 Packets in the following screenshot, the one with the violation has no MAC Address shown.

I must admit, compared to other cases I received a relatively quick response from support about this case 03334873.

But the quality of the answer is really poor:

"If your device is showing as ip spoof and you're sure. that there's nothing wrong with your device. 

Then Please make a exception for it."

Thats all! Not even a human name was written in the signature so I think this is a bot answer.

What's going on there? I wrote that there is a trusted MAC entry that does'nt work and also referenced to this forums thread.

Has anybody an idea how to deal with IP SPOOF false positive on a RED bridge?

well, looks like this RED setup is the bridge to a lonely island no-one ever put a foot on.

Support does'nt seem to know this island , too. That's what I think due to it's obsolescence.

Now we wanted them to connect from PC2 to PC1 behind XG in the same VLAN. Thougt - no problem - no firewall rules because same subnet - easy task.

Thats the problem. You need a firewall rule for bridges.

See: https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/NetworkBridgeInterfaces.html?hl=bridge

Hi LuCar Toni, thanks for your answer!

I wrote above that a dummy rule for that traffic was not working either.

"To allow traffic between bridged interfaces, you must create a firewall rule allowing traffic between the zones assigned to the interfaces. For example, for bridged interfaces configured with LAN zones, create a firewall rule to allow traffic from LAN to LAN."

If you disable the IP Spoof option, does it work?

Can you show us the Bridge as a screenshot? 

Hi LuCar Toni,

I disabled IP Spoof completely and the traffic was then no longer blocked. Communication over the bridge was possible.

In GUI Packet capture Screenshot (export to Excel) you can see a before and after comparison of IP Spoof enabled/disabled  and see that there exist a FW rule (ID 14) for ICMP and a NAT roule is also not present. So from Sophos' documentation, this should have worked even with IP Spoof enabled or am I wrong?

Screenshots of the bridge:

This could be a edge case, if the Spoof Protection working together with a VLAN bridge. Could be a Bug or a non documented feature (Works as designed). 

Would recommend to open a Case and link this to emmosophos for tracking, so we can figure out, if this is intended and needs to be documented or the IPS false positive strikes those packets. 

Hello emmosophos, can you please initiate some progress on this case: 03334873

I have not heard anything from support since 12 days ago (Nov 13th 2020).