SonicOS 7.0 Rules and Policies for Classic Mode
- SonicOS 7.0 Rules and Policies
- Access Rules
- Setting Firewall Access Rules
- About Connection Limiting
- Using Bandwidth Management with Access Rules
- Creating Access Rules
- Configuring Access Rules for IPv6
- Enabling and Disabling Access Rules
- Editing Access Rules
- Deleting Access Rules
- Restoring Access Rules to Default Settings
- Displaying Access Rules
- Displaying Access Rule Traffic Statistics
- Configuring Access Rules for NAT64
- Configuring Access Rules for a Zone
- Access Rules for DNS Proxy
- User Priority for Access Rules
- Access Rule Configuration Examples
- Setting Firewall Access Rules
- NAT Rules
- About NAT in SonicOS
- About NAT Load Balancing
- About NAT64
- About FQDN-based NAT
- About Source MAC Address Override
- Viewing NAT Policy Entries
- Adding or Editing NAT or NAT64 Rule Policies
- Deleting NAT Policies
- Creating NAT Rule Policies: Examples
- Creating a One-to-One NAT Policy for Inbound Traffic
- Creating a One-to-One NAT Policy for Outbound Traffic
- Inbound Port Address Translation via One-to-One NAT Policy
- Inbound Port Address Translation via WAN IP Address
- Creating a Many-to-One NAT Policy
- Creating a Many-to-Many NAT Policy
- Creating a One-to-Many NAT Load Balancing Policy
- Creating a NAT Load Balancing Policy for Two Web Servers
- Creating a WAN-to-WAN Access Rule for a NAT64 Policy
- DNS Doctoring
- Routing
- Content Filter Rules
- App Rules
- About App Rules
- Rules and Policies > App Rules
- Verifying App Rules Configuration
- App Rules Use Cases
- Creating a Regular Expression in a Match Object
- Policy-based Application Rules
- Logging Application Signature-based Policies
- Compliance Enforcement
- Server Protection
- Hosted Email Environments
- Email Control
- Web Browser Control
- HTTP Post Control
- Forbidden File Type Control
- ActiveX Control
- FTP Control
- Bandwidth Management
- Bypass DPI
- Custom Signature
- Reverse Shell Exploit Prevention
- Endpoint Rules
- SonicWall Support
Drop Tunnel Interface
A drop tunnel interface prevents traffic from being sent out using an incorrect route when the configured route is down. Traffic sent to a drop tunnel interface does not leave the appliance, but is ostensibly dropped.
A drop tunnel interface should be used in conjunction with a VPN tunnel interface, although a drop tunnel interface can be used standalone. If a static route is bound to a tunnel interface, SonicWall recommends configuring a static route bound to a drop tunnel interface for the same network traffic. That way, if the tunnel interface goes down, the second static route is used and the traffic is effectively dropped. This prevents the data from being forwarded in the clear over another route.
When configuring a route over a VPN tunnel interface, if the tunnel is temporarily down, the corresponding route entry is disabled as well. SonicOS looks up a new route entry for the connections destined for the VPN protected network. In deployments that do not have a backup link for a remote VPN network, no other correct route entry is available. Traffic is sent to a wrong route entry, generally the default route, which causes security issues such as internal data sent without encryption.
For deployments without a backup link, consider configuring the route table as in this example:
route n: local VPN network(source), remote VPN network(destination), VPN TI(egress_if)
route n+1: local VPN network(source), remote VPN network(destination), Drop If(egress_if)
When the VPN tunnel interface configured as in this example, the traffic matches the drop interface and is not sent out. When the VPN tunnel interface resumes, traffic resumes also.
Was This Article Helpful?
Help us to improve our support portal