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 188.8.131.52. To the outside world, everyone on our LAN appears to be at 184.108.40.206. 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 220.127.116.11 The SonicWall drops the ARP request. The router can’t get a MAC address for 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 (188.8.131.52 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.