Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

MAC Address Access rules

Hi

I've got an TZ300 which is used to filter client computers (from wan interface subnet) to reach ressources behind the firewall (in the lan interface).

So I created an access rule to enabling access from mac address and I nat traffic to only one ressource behind the firewall.

Everything works well but sometimes clients computers trames are dropped by the firewall without any reason, and I don't know why. Mac addresses are well registered but for an unknown reason the access is denied.

any idea ?

Regards

Category: Entry Level Firewalls
Reply

Answers

  • SaravananSaravanan Moderator

    Hi @CLIENT,

    Thank you for visiting SonicWall Community.

    Looks like the configuration is built from WAN to LAN for external users to access internal resources. The rule is allowed on the SonicWall purely based on source address as MAC address. If this is the setup, the MAC address keep changes between every hops and the firewall always sees the ISP router's MAC address at its end whenever there is a communication from WAN to LAN. So, its gonna be same Source and Destination MAC addresses always in the packets sent from ISP router to the firewall direction.

    It is always advisable that the rule has to be built using IP address when the traffic flow is from one subnet to another subnet.

    Hope this clarifies.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • ClientClient Newbie ✭

    Hi Saravanan

    Thanks for your answer.

    Basically the configuration is built from WAN to LAN that's exact, but this is inside a LAN network of my Office.

    For example :

    Lan office (for clients) is 10.100.144.0 /23

    WAN interface of the sonic' : 10.100.144.5

    LAN subnet for the LAN zone : 192.168.0.0 /24

    As the clients are in the DHCP scope of my office, I didn't want to make IP reservation for those computers on my DHCP and so, use IP filtering. That's why I used MAC ADDRESS because packets are not coming from my ISP router.

  • SaravananSaravanan Moderator

    Hi @CLIENT,

    Thanks for explaining.

    Please try doing packet capture on the SonicWall to understand the reason for the packet drop.


    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • ClientClient Newbie ✭

    Yes I started an capture.

    I've found this record during dropped capture:

    [Expert Info (Comment/Comment): in:X0*(interface),out:--,DROPPED, Drop Code: 736(Packet dropped - cache add cleanup drop the pkt), Module Id: 25(network), (Ref.Id: _2228_dbdifBeeDmfbovq),1:1) ]

  • SaravananSaravanan Moderator

    Hi @CLIENT,

    Yes, you have found the right article. You should be looking for any reasonable drop packets with reasons as access rule, content filter, etc,., otherwise we are good. Possibly, if you need more help on this part, I would suggest to take help from our support team.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • ClientClient Newbie ✭

    I edit the default TCP Connection timeout for TCP flooding to higher value than 15 minutes

    Here a part of my capture.

    Could you confirm with this sample if the TCP session was closed earlier?

    5   8.150000   10.100.145.21   192.168.59.3   SMB2   212   Create Request File:

    6   8.350000   10.100.145.21   192.168.59.3   TCP   68   62699 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

    7   8.850000   10.100.145.21   192.168.59.3   TCP   68   [TCP Retransmission] 62699 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

    8   9.350000   10.100.145.21   192.168.59.3   TCP   68   [TCP Retransmission] 62699 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

    9   9.850000   10.100.145.21   192.168.59.3   TCP   68   [TCP Retransmission] 62699 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

    10   10.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    11   10.350000   10.100.145.21   192.168.59.3   TCP   68   [TCP Retransmission] 62699 → 445 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

    12   11.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    13   15.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    14   16.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    15   20.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    16   21.533333   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    17   25.050000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    18   26.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    19   30.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    20   31.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    21   35.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    22   36.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    23   38.133333   Mitel_93:b2:b1   Broadcast   ARP   20   [Malformed Packet]

    24   40.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    25   41.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    26   45.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    27   46.516666   ArubaaHe_5c:61:e9   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003

    28   47.683333   192.168.59.3   10.100.145.21   NBSS   56   [TCP Spurious Retransmission] NBSS Continuation Message

    29   47.950000   Mitel_93:b2:b1   Broadcast   ARP   20   [Malformed Packet]

    30   50.000000   ArubaaHe_4a:79:e8   HewlettP_09:13:a6   IEEE802a   60   OUI 08:00:09 (Hewlett Packard), PID 0x0003




    Also what is the best practice for TCP timeout setting in the advanced settings of my Access rules which allow traffic between WAN to LAN ? I had 15 min too (default), maybe I have to extend this value?

  • SaravananSaravanan Moderator

    @CLIENT - Please leave the value for TCP timeout to the default 15 mins. You can only change this value after a recommendation from our support team for any scenario. Changing this value may result in WAN to LAN connections opened on the firewall for more than 15 minutes.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

Sign In or Register to comment.