In the place where I work, we have a main network plus some industrial equipment networks. Most of these networks consist of a single switch connecting sensors, actuators and a central PLC. For the most part, these networks have an air-gap between them and are in relatively secure rooms. Due to this isolation, issues such as security and I.P. overlap are rather easy concerns to address. However, there are occasions when some pieces of equipment need to communicate with the rest of the corporate network in a relatively secure way.
For example, a PLC may need to write information to a file server. In other cases, it's to allow remote management of items in the machine network. In order to do this, we need a way to address the I.P. overlap issue plus control security. Fortunately, this isn't a project that needs to be particularly expensive. List price on Ebay for used routers capable of this can sometimes be as low as $100. In some cases, the cost of electricity will be more than the equipment!
We'll demonstrate how this can work by using a GNS3 simulator. Not only can the the design be validated without using physical equipment, but the software also makes nice diagrams too. There are three example network sections that we'll be concerned with. First, a VPN section of the network. This whole range should be able to reach the IOT (Internet of things) network. Then, there's the desktop network. None of these should be able to reach the IOT network. Finally, in the server section of the network, that is the 10.10.40.x range, one specific server in that network should be allowed to communicate with the IOT network. Below is an image of that setup. Note, in a real world scenario, the IOT network would have more than one IOT device. The other IOT devices, not shown, have addresses 192.168.50.3, 192.168.50.4 and 192.168.50.5.
Since commands are rather basic, most any Cisco router should be able to use these configurations. The configuration runs on GNS3 but could just as easily run on Cisco Packet Tracer and of course on real equipment. Note, any IOT device in the IOT network also needs a NM of 255.255.255.0 and gateway of 192.168.50.1
Simulated 1921 router
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco-Nat-1921
!
boot-start-marker
boot-end-marker
!
logging console alerts
!
no aaa new-model
memory-size iomem 5
clock timezone EST -5
clock summer-time NYCDST recurring
no ip icmp rate-limit unreachable
ip cef
!
no ip domain lookup
ip domain name example.net
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
username MyUserName privilege 15 password 0 MyPassword
!
!
ip tcp synwait-time 5
!
interface FastEthernet0/0
ip address 192.168.50.1 255.255.255.0
ip nat inside
no ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.10.84.20 255.255.255.0
ip access-group 1 in
ip nat outside
no ip virtual-reassembly
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.84.1
!
no ip http server
no ip http secure-server
ip nat inside source static 192.168.50.176 10.10.84.19
ip nat inside source static 192.168.50.3 10.10.84.21
ip nat inside source static 192.168.50.4 10.10.84.22
ip nat inside source static 192.168.50.5 10.10.84.23
!
access-list 1 permit 10.10.40.10
access-list 1 permit 10.10.254.0 0.0.0.255
access-list 1 deny any
no cdp log mismatch duplex
!
control-plane
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
line vty 0 4
login
!
!
end
Simulated Core switch
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Core-Simulator
!
boot-start-marker
boot-end-marker
!
no logging console
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
username MyUsername privilege 15 password 0 MyPassword
!
ip tcp synwait-time 5
!
interface FastEthernet0/0
description Automation network 84
ip address 10.10.84.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.10.254.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.10.44.1 255.255.254.0
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.10.40.1 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
no cdp log mismatch duplex
!
control-plane
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
line vty 0 4
timeout login response 120
login
length 0
transport input all
transport output all
!
end
By
default, connected interfaces pass traffic to each other.
Spine-Leaf-Simulator#sh
ip route
Codes:
C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O -
OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 -
OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF
external type 2
i - IS-IS, su - IS-IS summary, L1 -
IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate
default, U - per-user static route
o - ODR, P - periodic downloaded static
route
Gateway
of last resort is not set
10.0.0.0/8 is variably subnetted, 4
subnets, 2 masks
C 10.10.40.0/24 is directly connected,
FastEthernet2/0
C 10.10.44.0/23 is directly connected,
FastEthernet1/0
C 10.10.84.0/24 is directly connected,
FastEthernet0/0
C 10.10.254.0/24 is directly connected,
FastEthernet0/1
Spine-Leaf-Simulator#
Trying PINGs from each (VPC)Virtual Personal Computer will also show traffic is being permitted and denied as specified. (results not shown)
Here’s why the
NAT statements work
In this scenario, the Local Host (LH) [192.168.50.176] needs to communicate with the
outside world. Since that host has a default gateway assigned, and router has a
default route, technically LH can communicate with Remote Host (RH)[10.10.254.10] already. A better way to phrase this then might be to
say RH needs to communicate back to LH. RH will receive
a ping sent from LH, but will not know how
to reach LH’s private IP address to send the
reply. The configuration below enables bidirectional communication:
Local_Router(config)#
ip nat inside source static 192.168.50.176 10.10.84.19
This configuration makes it so that hosts on the outside network can communicate with LH 192.168.50.176 by referring to it as 10.10.84.19.
TIP:
keep in mind the Cisco NAT order of operations. When moving from the inside interface to the
outside, routing is done first, then translation. From the outside interface to
the inside, translation occurs first, then routing.
Here's what's really neat though. There's no reason that you can't have more than one NAT device on the 10.10.84.x network. If a second NAT device is used, the addresses on inside of that second router can overlap with a neighboring router's inside addresses. You can even have a 3rd, 4th or 5th NAT device on that network section. As long as the outside addresses are unique and within the constraints of the network size, each IOT thing can be managed in a convenient and secure way.
