Connectivity timeout issues related to more secure SonicWall ARP behavior

12/20/2019 73 People found this article helpful 501,637 Views

Description

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 Grat ARP 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.

NOTE: 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

Identifying the source IP address for the ARP requests

Login to the SonicWall management interface.
Navigate to System | Packet Capture and click Configure button.
Click 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 OK .

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.

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.
NOTE: 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. and the same physical port.
EXAMPLE: See below; this example shows them to be the same device.