Traffic not passing through the site-to-site VPN tunnel

03/09/2021 2879 42237

DESCRIPTION:

In this scenario, the customer has a site to site IPSec VPN tunnel between two SonicWall appliances. The tunnel status shows up and running but the traffic cannot pass through the VPN.

RESOLUTION:

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

1. To check the Log Monitor, Navigate to Monitor | Logs | System Logs, see if any error/prevention/block/failed logs related to the traffic. 
   
    EXAMPLE: IP spoof dropped alert in the log. Then try to find out why the icmp packets is dropped as IP spoof.
   
   
2. To capture packets on the WAN interface, Navigate to Monitor | Tools and Monitors | Packet Monitor. Click General at the top of the page to configure the packet capture monitoring and displaying settings. In this case, while pinging from LAN side of SonicWall to the remote gateway, the SonicWall is generating an ICMP redirect packet. So it looks like a routing issue rather than a site to site VPN one.
   
                      
   
   
         
   
   

3. Then on SonicWall firewall GUI navigate to Policy| Rules and Policies | Routing Rules , and check the route policies.
   
   
   
   
   

4. From the route policy entry, check for see the Remote Address Object which has a 31-Bit subnet mask. Actually this is the root cause of the issue. The 31-Bit subnet mask is not supported by SonicOS yet.  So the firewall appliance does not recognize the traffic from the specific network.  

Background

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. Note that a point-to-point link in which only one end supports the use of 31- bit prefixes may not operate correctly.

RFC 3021 specifies an exception to this rule for 31-bit subnet masks, which means the host identifier is only one bit long for two permissible addresses. In such networks, usually point-to-point links, only two hosts (the end points) may be connected and a specification of network and broadcast addresses is not necessary.

Workaround 1

• Change the subnet mask of the address objects.

1. Navigate to Objects|Match Objects |Addresses.
2. Click Configure button next to the address object of the remote networks.
3. Change the Netmask/Prefix Length from 255.255.255.254 to 255.255.255.0(or other subnet mask), then click OK.
   
   

Workaround 2

• Change the type of the address objects from Network to Range. 

1. Navigate to Objects|Match Objects |Addresses
2. Click Configure button next to the address object of the remote networks.
3. Change the Type from Network to Range.
4. Set the Starting and Ending IP Addresses and then click OK.
   
   
   

How to Test

• Ping from the local network behind SonicWall appliance to the Remote 31-Bit subnet IP. And the traffic should be pass through the tunnel.

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

1. To check the Log Monitor, Navigate to Investigate | Logs | Event Logs, see if any error/prevention/block/failed logs related to the traffic. 
   

   EXAMPLE: IP spoof dropped alert in the log. Then try to find out why the icmp packets is dropped as IP spoof.

2. To capture packets on the WAN interface, Navigate to Investigate | Tools | Packet Monitor. Click Configure at the bottom of the page. In this case, while pinging from LAN side of SonicWall to the remote gateway, the SonicWall is generating an ICMP redirect packet. So it looks like a routing issue rather than a site to site VPN one.
   
   
3. Then on SonicWall firewall GUI navigate to Manage | Network | Routing, and check the route policies.
   
   
4. From the route policy entry, check for see the Remote Address Object which has a 31-Bit subnet mask. Actually this is the root cause of the issue. The 31-Bit subnet mask is not supported by SonicOS yet.  So the firewall appliance does not recognize the traffic from the specific network.  

Background

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. Note that a point-to-point link in which only one end supports the use of 31- bit prefixes may not operate correctly.

RFC 3021 specifies an exception to this rule for 31-bit subnet masks, which means the host identifier is only one bit long for two permissible addresses. In such networks, usually point-to-point links, only two hosts (the end points) may be connected and a specification of network and broadcast addresses is not necessary.

Workaround 1

•  Change the subnet mask of the address objects.

1.  Navigate to Manage | Policies | Objects | Address Objects.
2. Click Configure button next to the address object of the remote networks.
3. Change the Netmask/Prefix Length from 255.255.255.254 to 255.255.255.0(or other subnet mask), then click OK.
   

Workaround 2

• Change the type of the address objects from  Network to Range. 

1. Navigate to Manage | Policies | Objects | Address Objects.
2. Click Configure button next to the address object of the remote networks.
3. Change the Type from Network to Range.
4.  Set the Starting and Ending IP Addresses and then click OK.
   

How to Test

• Ping from the local network behind SonicWall appliance to the Remote 31-Bit subnet IP. And the traffic should be pass through the tunnel.

See Also:

Site To Site VPN Tunnel Is Up But Only Passing Traffic In One Direction