UTM: Connectivity timeout issues related to more secure SonicWALL ARP behavior. (SW7587)

  • Title

    UTM: Connectivity timeout issues related to more secure SonicWALL ARP behavior.
  • Resolution

    Article Applies To: 

    Affected SonicWALL Security Appliance Platforms:

    Gen6 SM E10000 series: NSA E10800, NSA E10400, NSA E10200, NSA E10100
    Gen6 SM 9000 series: NSA 9600, NSA 9400, NSA 9200

    Gen6 NSA Series: NSA 6600, NSA 5600, NSA 4600, NSA 3600, NSA 2600

    Gen5: NSA E8510, E8500, E7500, NSA E6500, NSA E5500, NSA 5000, NSA 4500, NSA 3500, NSA 2400, NSA 2400MX, NSA 220, NSA 220W NSA 240, NSA 250M, NSA250MW
    Gen5 TZ series: TZ 100, TZ 100W, TZ 105, TZ 105W TZ 200, TZ 200W, TZ 205, TZ 205W TZ 210, TZ 210W,TZ 215, TZ 215W.

    Firmware/Software Version: SonicOS Enhanced 5.0 and above
    Services: ARP, Static ROute

    Problem Definition:

    The connectivity issues with the ISP are related to the new ARP behavior of the NSA units.  The issue at hand is that many ISPs perform insecure probing to either identify unused IP addresses or to manage blocks of static IP addresses for their customers.  The way many ISPs perform these “probes” are by using the modems or gateways connecting you to the internet.  The technical issue with “internet disconnects” from behind the SonicWALL, with an interval of about 15 minutes or even as much as every 6 hours is the ARP requests the ISP sends to the SonicWALL to publish is own ARP cache are coming from an address outside the SonicWALL’s WAN interface and gateway subnet. 

    The SonicWALL, being a security appliance, has recognized this behavior as a potential security risk and drops these packets.  The result is, the gateway device (usually located at the ISP) sending these requests does not have ARP cache telling it the MAC address of the SonicWALL WAN interface that is associated with your public IP or entire block of IP addresses if applicable.  When incoming requests from the internet say for a “Web Server” “FTP Server” etc... hit your gateway router, the ISP doesn't know where to send them, or sends them to another client that did respond to the ARP requests (if using DHCP on the WAN). 

    The recommended way to verify you are experiencing this issue, due to the described behavior change in combination with your ISP’s method of public address management and identification, is to have the SonicWALL send out gratuitous (Grat) ARPs. This can be done by going to the internal settings of the diag page (http(s)://<SNWL addr.>/diag.html) and hit the ‘Send System ARPs’ button. Alternatively you can edit or disable/ re-enable the related NAT policy, which will only send out a GratARP for the public address defined in this policy. When after this, connectivity is restored for the previously seen connectivity timeout period (e.g. 15 min.), you are likely experiencing the described. A final verification would be to take captures on the WAN interface filtered on ARP as described below. With this data you can request your ISP to add or adjust the upstream route(s) for your public addresses.

    Please note that when ARP requests for addresses other then the SonicWALL’s WAN interface IP are received, this indicates the ISP does not have (the proper) route defined to route the additional addresses to the SonicWALL.

    Resolution or Workaround:

    Step 1. Identify the source IP address for the ARP requests
    Step 2. Create a static route to tell the SonicWALL that the source IP address is trusted to receive ARP requests from.

    Step 1. Identifying the source IP address for the ARP requests

    • Login to the Sonicwall Management interface.
    • Navigate to System > Packet Capture and click on the Configure button.
    • Click on the Default button at the bottom to clear any previous configuration.
    • Enter “arp” as the Ether Type
    • Check the two boxes Capture Firewall Generated Packets and Capture Intermediate Packets under the Advanced tab.
    • Click on OK to save.




     After you have setup the capture, click OK then Start.  Look for the ARP packets by selecting Refresh (oldest on top, latest at bottom).


    After you have identified the source IP address of the ARP requests, you need to create a static route. 

    Step 2. Creating a static route to tell the SonicWALL that the source IP address is trusted to receive ARP requests from.

    • Create an address object for the gateway under Network > Address Objects.
    • Create a static route under Network > Routing as Illustrated.



    The static route created should look like this in the routing table.

     Now run the packet capture again and verify the Sonicwall is responding to the ARP requests sent from the “Secondary Gateway”.


    Please note that in the ARP cache of the SonicWALL, under Network > ARP, this source IP address may or may not be the same device as your actual gateway; or may be the same device just on a different physical port.  See below; this example shows them to be the same device and the same physical port.



Feedback submitted.

Did this article help?

[Select Rating]

Thank you for your rating!


Request or Create a KB Article »

SonicWALL NSA Series
4500, 3500, 250MW, 250M, 2400, 220W
SonicWALL E-Class NSA Series
E8510, E8500, E7500, E6500, E5500
SonicWALL TZ Series
215W, 215, 210W, 210, 205, 200W, 200, 105, 100W, 100

Technical Solutions

Article History:
Created on: 1/7/2010
Last Update on: 9/12/2014