1

I'm trying to enable https management of our Sonicwall NSA 220 wireless-N from the LAN interface, but browsing to the WAN IP. This is because:

  • we also need WAN side management
  • we don't have VPN set up
  • we don't have internal private DNS, and so the public DNS entry for the device needs to reflect the WAN IP

For the moment, I'm unwilling to accept the workaround of having two DNS entries, one for the public IP and one for the private IP.

WAN side https management works fine from the public internet. LAN side https management works fine when going to the X0 IP address. When attempting to do anything to the X2 (WAN interface) IP address from the lan, the packets are dropped. The packet monitor is reporting:

DROPPED, Drop Code: 39, Module Id: 26, (Ref.Id: _4740_uyHtJcpfngKrRmv) 1:1)

Checking what documentation I have been able to find, this appears to be "Enforced firewall rule", but I cannot seem to find the firewall rule that might be enforcing it. The only LAN -> WAN firewall rule appears to support all outbound traffic.

  • Have you tried explicitly adding a firewall rule allowing LAN traffic -> firewall WAN IP ? Or even from firewall WAN -> firewall WAN might be worth a try. I'm thinking this sounds similar to loopback/hairpin NAT, although you don't have a server behind the firewall to access so I'm not sure if that applies, but the sonicwall is NATting your LAN traffic on the way out, so by the time it gets to the WAN interface it might be "from" the WAN IP already. e.g. a variation on this https://support.software.dell.com/kb/sw11481 (random sonicwall find, you didn't mention a model / firmware) – TessellatingHeckler Jun 06 '15 at 03:49

1 Answers1

1

The key appears to be that HTTP/S Management needs to be explicitly whitelisted, even if you have a firewall rule that permits regular traffic. So the entries required were:

LAN > WAN
Source: Any
Destination: All X2 Management IP
Service: HTTPS Management

A second rule for HTTP Management allowed the non-secure site to redirect to the secure one.

Thanks to TessellatingHeckler for reminding me to look harder at LAN > WAN rules.