This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RED60 VLAN bridged - blocked because of invalid traffic IP SPOOF

Hello,

we have set this up for a remote location:

So the same VLAN ID on both sides: behind XG and behind RED, same IP Subnet.

Bridge Members, same Zone:

This is already in production and working. the RED60 Users can work on internal ressources and connect to WAN via our central XG.

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.

But the firewall is blocking traffic because of invalid traffic, IP SPOOF - seen in GUI packet capture. No logs in IPS by the way...!

Why is this not working?

How can we get this working?



This thread was automatically locked due to age.
  • 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 , 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 ,

    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 for tracking, so we can figure out, if this is intended and needs to be documented or the IPS false positive strikes those packets. 

    __________________________________________________________________________________________________________________