Article Applies To: 

Affected SonicWALL Security Appliance Platforms:

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 there 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.