Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".


WLAN Access Rules

Trying to follow a best practice approach here. I have a SonicWall TZxxx and an (older) SonicPoint WAP connected and working together properly.

By default, SonicOS 7 puts WLAN WiFi clients on a separate sub-net from wired LAN clients and blocks traffic from the WLAN to the LAN to prevent potentially malicious WiFi clients from access to devices on the LAN. All good so far. SonicOS also blocks traffic between devices on the WLAN, presumably to prevent potentially malicious WiFi clients from gaining access to trusted WiFi clients. Traffic from the WLAN to the WAN is allowed as per normal. Again, all good so far.

However, I need several (trusted) WiFi devices on the WLAN to be able to communicate with each other over the same sub-net. I have several working solutions, but think that they are too permissive:

  1. Configure the SonicPoint or X4 interface in Layer 2 Bridge Mode, which simply makes the WLAN an extension of the LAN, putting both on the same sub-net. Too permissive I think. Potentially malicious WiFi clients would then have access to all devices on the LAN.
  2. Allow Interface Trust on the X4 Zone. Similar to Item 1 above, this "solution" is too permissive I think. It likewise allows potentially malicious WiFi clients access to all devices on the LAN.
  3. Set-up a custom Access Rule that allows those trusted WiFi devices on the WLAN that need to communicate with each other permission to do so. Firstly, create custom (Host/IP) Address Objects (Object->Match Objects->Addresses) for the trusted WiFi devices needing to talk to each other, and add them into a custom Address Group, call it "WLAN to WLAN Group." Next create a custom Access Rule (Policy->Rules and Policies->Access Policies) as follows:
    1. Zone Source: WLAN (X4)
    2. Zone Destination: WLAN (X4)
    3. Address Source: WLAN to WLAN Group
    4. Adress Destination: Any
    5. Service: Any
    6. User Include: All
    7. User Exclude: None
    8. Schedule: Always.

The solution in Item 3 above works, but again might be too permissive. Should I also restrict the Service in the Access Rule? If "yes, that would be a good idea," how do I do that?

I ran a packet capture designed to reveal just services used by (just) two trusted WiFi clients communicating via the WLAN, and the number of non-standard ports that those two WiFi devices used kept incrementing (52694, 52696, 52697, 52698, 52699, 52700, etc.). Note: the two devices also used a few standard ports to communicate with each other. However, it seemed to me that trying to restrict access based on Service (i.e., Ports used, right?) was not feasible if the ports just kept incrementing as they appeared to do during my packet capture.

What am I missing? Any thoughts or guidance greatly appreciated. Thanks!

Category: Entry Level Firewalls


  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭
  • Options
    wwhigginsjrwwhigginsjr Newbie ✭

    Thanks TKWITS.

    My concern is not so much in having WiFi available for guests as it is in locking down the access point from bad actors/malicious interlopers via WiFi. Should I be trying to define a Service Object/Service Group (that includes ephemeral ports) in order to include that Service Object/Service Group in the custom Access Rule detailed in Item 3 in my original post?

  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭

    If you feel your highest risk is around wireless than by all means add services to your access rule. But you can be doing other things to reduce your wireless risk (separate networks, 802.1x, zero-trust networking).

    The mention of a 'guest network' was less about providing Wifi to 'guests' and more towards introducing the idea of separate networks for different purposes and needs.

    What you should and shouldn't do isn't up to users in a forum. What are the companies policies on wireless? What do cybersecurity frameworks say?

  • Options
    wwhigginsjrwwhigginsjr Newbie ✭

    Thanks again TKWITS.

    I think I'll read up on some of those approaches you cited.

Sign In or Register to comment.