Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

IP Spoof, that's not an IP spoof

We have an NSA 3600 (In HA mode). We also have 2 Zevenet Load Balancers configured for HA.

The Load Balancers are attached to 2 networks, one connected to X0 and the other a private vlan that has no connection to the SonicWall.

Each back end server that is using the load balancer also has 2 network adapters with the same configuration. The Network Adapters on the Load balancer vlan has the gateway IP set to the load balancer. The lan has the gateway set to the SonciWall. We have configured the Nic connected to the Sonicwall as the Higher priority so that regular internet traffic is using this, while traffic sourced from the load balancers are returned through the load balancer.

The issue we are facing is that at regular intervals our exchange servers are sending outbound emails through the adapter connected through the load balancer, when this occurs the sonicwall flags a IP spoof and the message sits in queue until the exchange server sends using the adapter on X0

Looking that the IP Spoof drop log it shows the IP of the Exchange server with the Mac address of the Load Balancers nic connected on X0.

My Question is How do I let the Sonicwall know that this traffic is not an IP Spoof?

Category: Mid Range Firewalls
Reply

Answers

  • Hello @OCComputer,

    Welcome to SonicWall community.

    There are two ways to do this and I would suggest option 1.

    Option 1: Create a static route on the firewall that shows that the other network (load balancer VLAN) is reachable on X0 with the gateway being the load balancer IP address. With this route, the SonicWall knows that when traffic comes with that IP address, it is in fact present behind the X0 interface and how it can be reached.

    Option 2: Disable IP Spoof in the diag page. Unfortunately, this will disable this entire feature for all the IP addresses which I will not recommend.

    Thanks!

    Shipra Sahu

    Technical Support Advisor, Premier Services

  • OCComputerOCComputer Newbie ✭

    So I under stand with Option 1 I want to set a new route policy with these settings:

    Source: LB vLan

    Destination: Any

    Service: Any

    Interface: X0

    Gateway: X0 IP of the Load Balancer. There is one IP for each farm so Not sure which, or should this be the IP of the Load Balancers vLan?

    Metric: Higher or lower or the same as 20?

  • @OCComputer,

    This is how the route should look like:

    Source: Any

    Destination: Load balancer VLAN

    Service: Any

    Interface: X0

    Gateway: Load balancer IP (The IP that is in the same subnet as X0)

    Metric: 1

    Thanks!

    Shipra Sahu

    Technical Support Advisor, Premier Services

  • gwesleyrgwesleyr Newbie ✭
    edited December 2020

    I'm having a similar issue. I have a subnet behind a load balancer, and though I have a static route on the SonicWALL pointing to the LB X0/LAN interface IP as the next hop, it is still dropping traffic sourced from the LB subnet bound for the WAN. I can route to the LB subnet as long as it's to/from something on the LAN side, so my route is working. I'd rather not disable spoofing, but not sure what else to do. The devices on the subnet behind the LB are VMs, and I found this KB: https://www.sonicwall.com/support/knowledge-base/ipspoof-dropped-messages-in-the-sonicwall-log-with-video-and-kb-article/170505528391975/#Virtual__e.g._VMware__interfaces___adapters

    Nodes with Virtual Machines connected to virtual adapters with an IP address not in the same subnet as the host physical adapter may also cause IP Spoof when the virtual adapters try to access the internet through the SonicWall. Workaround is to disable the virtual adapters or create a route policy on the SonicWall for those networks.

  • gwesleyrgwesleyr Newbie ✭

    After chasing down some MAC addresses, I discovered an errant route that was causing an asymmetric flow to/from the LB network. Once I resolved that, traffic from the network behind the LB was able to route to services in the WAN.

Sign In or Register to comment.