Restricting Everything but RDP
If you're thinking we're right back where we started, you're almost correct. The difference is that we can now use ACLs on the router to limit access to and from the lab network. Cisco ACLs are similar in concept to the ACLs that NTFS uses, but instead of limiting access to files, they limit which packets traverse a router interface.
LabBox is running Microsoft Terminal Services, so the first ACL rules we'll configure will let users from the corporate subnet use Remote Desktop Client to access the lab subnet. Remote Desktop Client and Terminal Services use the RDP protocol to communicate. RDP operates on TCP port 3389.
To allow RDP, we must configure access lists to permit inbound traffic destined for port 3389 on the lab subnet. Cisco IOS supports two types of ACLs to control traffic that uses the IP protocol: standard IP ACLs and extended IP ACLs. Both let you control traffic by using information such as the IP address, but extended ACLs also let you use information from protocols that rely on IP, such as TCP. Because we need to limit traffic by TCP port, we'll use an extended IP ACL. You must use a unique number to identify each ACL you create. The type of ACL determines the numbers from which you can choose. Extended IP ACLs can be numbered 100 to 199 or 2000 to 2699. For my tests, I arbitrarily used extended IP ACL 110, which hadn't yet been assigned to an ACL on my router. The first Access-List command that Figure 7 shows permits TCP traffic from any source IP address to destination IP addresses on the subnet 192.168.1.0/24 if the destination TCP port is 3389.
Notice that the number after the subnet's IP address is like a subnet mask, but inverted. Cisco calls this number a wildcard, and it specifies bits to ignore when comparing the ACL's IP address with each packet's IP address. We want it to ignore the last octet of the IP address, so the last octet of the wildcard is 255—or eight 1s. You can read more about the Access-List command in the IOS documentation's IP Application Services section.
In addition to permitting inbound RDP, we have to permit hosts on the lab subnet to respond to that traffic. The second Access-List configured in Figure 7 permits TCP traffic with a source IP address on the lab subnet to any destination IP address for established connections. This ACL will let hosts on the lab subnet respond to TCP connection requests, but it will deny packets (called SYN packets) that originated on the lab subnet and are seeking to establish a TCP connection.
Cisco IOS processes ACLs on traffic as it enters or leaves a router interface, so before your ACL can do anything, you must tell IOS which interface the ACL should apply to and whether it should apply to traffic entering the router by that interface or traffic leaving the router by that interface. We'll assign the ACLs we configured to interface Ethernet 1 on the router since they were designed to limit traffic to the lab network connected to interface Ethernet 1. Each router interface can have—in Cisco terminology—an outgoing and an inbound ACL. Remember that the direction refers to how a packet travels through the router interface, not how it travels through the network. Therefore, the ACL we assign to the outbound direction of interface Ethernet 1 will apply to packets traveling from some other subnet, such as the corporate subnet or the Internet, into the lab subnet. After an ACL is assigned, the router will implicitly deny any traffic the ACL doesn't permit, so in addition to permitting RDP, we have denied all other traffic. Figure 7 shows how to use the IP Access-Group command from config-if mode to assign ACLs 110 and 120 to the outgoing and inbound directions of interface Ethernet 1. You can read more about the IP Access-Group command in the IOS documentation's IP Application Services section.
To test that the ACLs are working correctly, open the Remote Desktop Client on CorpBox and connect to LabBox. RDP should succeed. Next, try pinging LabBox from CorpBox and vice versa. (You'll have to ping by IP address because the lab subnet doesn't yet have a DNS server.) The ping will fail because our ACLs don't permit Internet Control Message Protocol (ICMP) echo traffic. To troubleshoot the configuration on the router, you can use the commands Show Access-Lists (to view the ACL definitions) and Show IP Interface Ethernet 1 (to view the assignment of the ACLs to the interface).
Allowing Internet Access from the Lab
To allow Internet access but continue to deny all non-RDP traffic between the lab and corporate subnets, enter ACL rules C through F from Table 1 on the router. (We configured A and B in the previous steps.) Order matters, so enter them in the order shown.
The router will now let hosts on the lab subnet access the Internet, but not the corporate subnet. Because your DNS servers are probably on your corporate subnet, devices on the lab subnet won't be able to resolve domain names by using the corporate DNS servers. You can solve this problem by either configuring hosts on the lab network to use your ISP's DNS server or setting up a DNS server on the lab network.
Segregated Lab Network
Figure 8 shows how traffic flows to and from the lab network. This simple configuration isn't a true firewall and might not keep out malicious attackers. However, it will give users a sandbox environment from which they can't access your other internal networks. With this configuration, you can strictly limit access to production information systems and set up alternative systems on the lab subnet for testing, development, and general-purpose use—without worrying how they might affect your corporate systems. Best of all, your network closet probably already contains all the equipment you need.
End of Article
