# A Secure Internet of Things Smart Home Network: Design and Configuration
## 3 Network Design and Configuration
The configuration commands for DHCP and routing protocol are shown in Figure 3.  
With the given network design, we outline our configuration goals as follows. 1. Allows all hosts on the home network outbound access to connect to the Internet. 2. Allows authorized hosts on the Internet inbound access to IoT server. 3. Does not allow any hosts on the Internet inbound access to other hosts in the home network. 4. Does not allow the IoT server inbound access to other hosts in the inside-subnet except for essential hosts such as the IoT devices or the DNS server. Since each host in the home network has a non-routable private IP address, we first need to carry out a Network Address Translation (NAT) with a Port Address Translation (PAT) and Access Control List (ACL) configuration on the home gateway. The NAT rule translates the non-routable private IP address to a public IP address, which is routable on the Internet. In our case, the home gateway translates the private IP addresses of the hosts in the inside-subnet to the home gateway's outside interface IP address Serial0/0/0. Owing to the NAT rule, all hosts in the inside-subnet can initiate their communications to the external network with a shared routable public IP address. To handle the returning packets from the external network, the PAT rule is applied with \"overload\" for the home gateway to decide a specific destination hosts on the inside-subnet. If the same NAT/PAT rule is applied to the IoT-subnet, the IoT server on the IoT-subnet can access the Internet. However, the communication cannot be initiated from the external network because the NAT/PAT itself does not have a bidirectional property. It means the authorized IoT clients located in external network cannot access to the IoT server because they have no way to initiate a communication to the IoT server. Therefore, we need to explicitly configure the NAT/PAT rule so that IoT clients on the Internet can reach  
Figure 3: DHCP setup on the home gateway. the IoT server by accessing 20.20.20.1 on TCP port 80 in the case of the HTTP server and port 1883 in the case of the MQTT broker. This is possible because the initiation request destined to the public IP address 20.20.20.1:80 is statically translated to the private IP address 192.168.1.2:80. Using the configuration in Figure 4, our goal (1) is achieved. Now, we set an extended ACL policy, named \"access-list 100\", to be applied to the external interface Serial0/0/0 of the home gateway to control access from external network considering our goal (2) and (3). At first, we need to explicitly permit traffic from the external network to the IoT-subnet provided the traffic is destined to the HTTP server. However, other traffic destined to the inside-subnet is denied access by the home gateway. Even though traffic from the external network is permitted by default without access-list creation, we need to note that once the access-list on the gateway is created, it implicitly denies any traffic except for the previously permitted traffic on the same access-list. Therefore, to allow the returning packets as a response of the initiated packets from the hosts on the inside-subnet to pass through the home gateway, we explicitly permit other traffic. This ACL configuration policy is shown in Figure 5. Additionally, when this policy is applied to the external interface of the home gateway as shown in Figure 2, our goals (2) and (3) are achieved while still satisfying goal (1) by controlling the inbound traffic at the home gateway. For our goal (4), we need to define traffic control between the inside-subnet and the IoT-subnet. In our configuration, we located the DNS server (192.168.0.53) and the IoT devices on the inside-subnet, which are essential hosts to the IoT server for external Internet access with domain name and providing IoT service to the external network.