NSA 2700 drops ARP requests for IP address it's NAT'ing Firmware bug?
We have a pair of SonicWall 2700’s in a very simple HA configuration. Here’s the problem. The WAN interface (X1) has IP address 10.5.1.2 Our internal router’s interface is 10.5.1.1. We have a single NAT policy that for the WAN interface that maps the source IP for all egress traffic on the WAN interface to 184.108.40.206. To the outside world, everyone on our LAN appears to be at 220.127.116.11. That’s great. Should work fine. Has for years with Cisco ASAs. However, via packet capture on the SonicWall I notice that the router at 10.5.1.1 sends an ARP request to the SonicWall for 18.104.22.168 The SonicWall drops the ARP request. The router can’t get a MAC address for 22.214.171.124 so it can’t send traffic to the WAN interface on the SonicWall and our connectivity goes away. There is an internal settings page (/settings/diag.html) on the SonicWall that has a button to send gratuitous ARPs. Hit that button and the router is happy…until it’s cache times out…about 4 hrs. Then the router sends another ARP request for 126.96.36.199 and it’s dropped by the SonicWall. There is another setting in the internal settings page to repeated send gratuitous ARP responses every 60 minutes. That works for days…until the thread on the SonicWall’s OS dies or an HA failover happens. So that workaround is no good. I configured a Static ARP entry for 188.8.131.52 on the SonicWall and set it to publish. Didn’t help. SonicWall support has pretty much given up.
It’s probably as simple as the SonicWall has a (hard-coded) security policy that rejects ARP requests for hosts (184.108.40.206 in our case) that it thinks are not on it’s subset. It doesn’t seem to consider NAT policies !! Anyway, perhaps some sort of static route would work around the problem or some overriding security policy. Not sure.