Filter
Top Products
3
What does ‘Allow Interface Trust’ mean for a zone?
When this box is checked, all interfaces added to the zone will automatically have security policy written to allow all
systems connected to each interface to talk to each other – if checked, you will see these policies show up in the
firewall access rules policy intersection for that zone (for example: ‘LAN > LAN’). These polices can be adjusted as
needed, or deleted completely.
I created some zones, but they do not show up in the rules matrix – why?
Zones will not display in the access rules matrix unless an interface has been explicitly bound to the zone. Once an
interface has been added to a zone, it will then show up in the matrix, and you can then write rules to/from this zone.
How many SonicPoints can I add to a TZ 170 SP?
You can add up to two SonicPoints to the OPT interface, once the OPT interface is added to a Wireless zone.
Please note that the TZ 170 SP must be running SonicOS 2.6 Enhanced or newer to support SonicPoints.
Can I put SonicPoints in the LAN or WAN zone?
No, you cannot. In order for SonicPoints to be acquired, provisioned, and controlled by the TZ 170 SP, they must
be placed into a Wireless zone. The WAN and LAN zones also do not have the WiFiSec and WGS enforcement
tabs, as the Wireless zones do. While a SonicPoint can be configured to run in standalone mode and could
conceivably be hand-programmed and attached to the LAN zone, you’d lose WiFiSec and WGS capabilities for the
wireless users associating with that SonicPoint.
Can I connect a third-party wireless access point to the TZ 170 SP?
Yes and no – it’s not possible to connect a non-SonicWALL access point to a Wireless zone, as the TZ 170 SP will
not communicate with third-party access points, and will block all wireless traffic attempting to connect through it
from that access point. However, it is possible to hook a third-party access point to any zone not marked as a
wireless zone, but you will not be able to enforce WiFiSec or WGS for any wireless user connecting through that
access point.
What is ‘Consistent NAT’?
This is a new feature in SonicOS 2.5 Enhanced and newer. The control for this feature, which is located on the
‘Firewall > VoIP’ page, should be left unchecked by default. The Consistent NAT option modifies the SonicWALL's
standard NAT behavior when handling outbound UDP traffic in order to provide higher levels of compatibility with a
small handful of certain peer-to-peer applications such as some online games and Apple's ‘iChat’
application. Consistent NAT uses an MD5 hashing method to consistently assign the same remapped (i.e. Network
Address Translated) public IP address and public UDP port pair to each internal private IP address and private
UDP port pair. For example:
Private (LAN) IP: 192.168.168.10 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167
Private (LAN) UDP Port: 50650 --> Consistent Remapped Public (WAN) UDP Port: 40004
Private (LAN) IP: 192.168.168.10 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167
Private (LAN) UDP Port: 50655 --> Consistent Remapped Public (WAN) UDP Port: 40745
Private (LAN) IP: 192.168.168.20 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167
Private (LAN) UDP Port: 50650 --> Consistent Remapped Public (WAN) UDP Port: 54621
Private (LAN) IP: 192.168.168.10 --> Consistent Remapped Public (WAN) IP Address: 64.41.140.167
Private (LAN) UDP Port: 50650 --> Consistent Remapped Public (WAN) UDP Port: 49724
With Consistent NAT, all subsequent requests from either host 192.168.168.10 or 192.168.168.20 using the same
Private UDP ports as illustrated above would result in the use of the same, predictable remapped Private UDP
ports. Without Consistent NAT, the remapped port would change with every subsequent request, providing no
consistency, and no predictability. Most UDP based applications are perfectly compatible with the latter, and do not
require Consistent NAT.