Not allow private addresses on WAN interfaces

A_Elliott

This happens with all TZ/NSa units, but since you have to select a trim level to post, I'm posting it here.

How to stop routing to private addresses on WAN interfaces/Zones?

Example issue:

Using a basic network test like ping, and a VPN tunnel goes down, we still get responses from the private address (Example: 10.20.5.x) as it is also used for the ISP's equipment. Frustrating when monitoring systems show a device is UP, when in reality the entire VPN tunnel is down.

This happens on giant ranges of private subnets, so I believe it would be easier for us to STOP the traffic on our end. This is fairly simple in other firewall brands, but for the life of me, I can't find where to disable that in all of our SonicWalls. (mostly Gen 7, some Gen6's)

BWC

@A_Elliott if you're using VPN Tunnel Interfaces you can add a new rule covering all your remote networks and use the Drop_TunnelIf as the Interface for that route. Use a higher metric for that then your original route, this will drop any VPN remote network related traffic and it will not show up on your WAN interface.

For example:

SRC: 192.168.1..0/24 - DST: 10.20.5.0/24 - Interface:: MyVPNTunnel - Metric: 1

SRC: 192.168.1.0/24 - DST: 10.20.5.0/24 - Interface: Drop_TunnelIf - Metric 9

--Michael@BWC

A_Elliott

That would be a nightmare to keep up with, considering there's a dozen or so different subnets across each site to site VPN tunnel.

Basically the entire 10.0.0.0/8 subnet and 172.16.0.0/16 subnets will respond from every address in those subnets from my WAN connections on this one ISP. It's all their equipment. I've hit iDRAC logins, datacenter cameras, "inside" interfaces to cable modems.....it's a nightmare. I'm afraid one of my tunnels will drop and a device will send sensitive information to one of these hosts when I should be able to lock it down. Kind of pointless to make access rules when the Address Object could come back as a completely different entity/device/vulnerability.

BWC

@A_Elliott that's the way I'am doing VPN Tunnel Interface Routing.

• Creating two Address Group Objects, one with the local subnets and one with the Remote networks
• Create one or more routing rules, which routes the traffic from Local to Remote VPN Group via VPN Interface
• Create another Route with a higher Metric (usually 9) for these Address Groups pointing to the Drop_TunnelIf

Therefore no VPN related traffic will ever leave the WAN interface when the Tunnel Interfaces are down.

Another approach might be to Route 10.0.0.0/8 and 172.16.0.0/12 to the TunnelIf with a higher Metric, but you should be careful how this will be sorted into the Routing List because of the Priority. For the worst case you should have access via serial console or another interface not part of these two network blocks.

I guess the same effect would have an Access Rule from ANY to WAN Drop Traffic to these two mentioned network blocks.

--Michael@BWC

A_Elliott

Ugh. This is going to take weeks, and honestly isn't the best resolution. I mentioned VPNs, but even if I scan locally (10.10.10.1-10.10.10.254 for example), I will get a return for every IP in that subnet, even though there's no inside device with that IP leased.

What a pain! Other vendors have a "Block RFC1918 on WAN interface" check box or command. Too bad SonicWall doesn't seem to.

BWC

@A_Elliott did you read what I wrote in length above? Either use a Route to Drop_TunnelIf or (a simpler solution) an Access Rule from ANY to WAN rejecting any Traffic to the RFC1918 Objects Group which your have to create by yourself, but we're talking about 3 Objects (+ 1 Group) here, nothing fancy.

"Block RFC1918 on WAN interface" is not an one-click option, but not much trouble to implement.

--Michael@BWC