This is probably of less interest than most of my blog postings about Cisco routers, as it concerns something less commonly configured in the way I have done it – specifically a WAN link with a single IPv4 address and NATting to that address. However writing up my notes here is convenient to me, so you’ll have to put up with it. It is also very definitely worth bearing in mind the disclaimer here.
Basic NAT
First of all the “outside” interface needs to be configured as such from the NAT point of view :-
router#configure terminal router(config)#interface fastethernet 4 router(config-if)#ip nat outside
This marks the interface in a way that lets the router know how addresses need to be NATted. Of course it is also necessary to configure the “inside” interfaces too :-
router#configure terminal router(config)#interface vlan 101 router(config-if)#ip nat inside
And repeat for each VLAN of course.
In most instructions you will see that it is normal to create a pool of addresses for use by NAT which is perfectly valid for a number of addresses to NAT to, and even when there is a single address. But there is an easier way … NAT to the address of the interface.
router#configure terminal router(config)#ip nat inside source list 7 interface FasterEthernet4 overload
The next task is to specify an access list to match the addresses that need to be NATted.
router#configure terminal router(config)#access-list 7 permit 10.0.0.0 /8
Port Forwarding or Static NAT (for Servers)
If you run your own servers you will need to arrange for incoming connections to certain tcp or udp ports to be ‘forwarded’ to a specified address. This is known in the domestic router scene as “port forwarding” which is as good a term for anything – given that the concept of NAT is fundamentally broken.
This is done quite simply by the following :-
router#configure terminal router(config)#ip nat inside source static tcp 10.0.0.14 80 interface FastEthernet4 80
This of course says that there should be a static rule to map tcp/80 (http for the web) on the server with the address 10.0.0.14 to tcp/80 on the ‘outside’.
A Basic Firewall
Next task is to bring up the WAN connection to check it works ? Not at all; whilst it may be somewhat unhelpful to connect things up after having made multiple changes, it is important to have some kind of firewall running. If you happen to have the IOS firewall feature, there is little point in bothering with the ordinary ACL feature – it sucks in comparison.
But strangely it seems we do need a basic ACL in place to :-
- Allow server traffic into the network.
- Deny all other traffic.
- And to allow the inspect engine to extend the ACL to allow session specific rules.
router#configure terminal router(config)#ip access-list extended AllowIn router(config-ext-nacl)#permit tcp any any eq www router(config-ext-nacl)#deny ip any any log DenyIn
The use of a named ACL here is to allow for greater self-documentation – it is easier to see what an ACL should be used for when it is named. This becomes more important the more ACLs are in use.
We then need to create a set of inspect rules to allow traffic out. This is a very open set of rules, and will dynamically create temporary rules to allow the inbound replies to the allowed outbound traffic. The ordering of this is very important as we need to most specific inspections first – so “inspect tcp”, etc should appear at the end.
router(config)#ip inspect name allow-out bittorrent router(config)#ip inspect name allow-out ftp router(config)#ip inspect name allow-out ftps router(config)#ip inspect name allow-out gnutella router(config)#ip inspect name allow-out h323 router(config)#ip inspect name allow-out http audit-trail on router(config)#ip inspect name allow-out https audit-trail on router(config)#ip inspect name allow-out icmp router-traffic router(config)#ip inspect name allow-out tcp router(config)#ip inspect name allow-out udp
The ‘router-traffic’ on the icmp rule is to allow the router to send ICMP traffic to the outside interface and for it to be inspected. For some strange reason, Cisco configured the default to not allow it – leading to any number of network administrators having a nasty panic attack. Perhaps Cisco have a nasty sense of humour?
Next, because it’s fun to see what people may be doing, we need to log whatever the inspection engine drops :-
router(config)#ip inspect log drop-pkt
Finally we apply the new rules to the WAN interface :-
router#(config)#interface fastethernet 4 router#(config-if)#ip access-group AllowIn in router#(config-if)#ip inspect allow-out out router#(config-if)#end
This just touches on the capabilities of firewalling with a Cisco and is well worth checking in greater depth. For instance, it is clearly possible to inspect incoming traffic as well as outgoing traffic, but if you do the obvious you end up with a non-working firewall
Bringing Up The WAN
Fortunately I am in the situation where my ADSL line is bridged to Ethernet using an ADSL ‘modem’ so that I merely have to configure the external WAN interface on my router with an external address, a netmask, etc. This is so trivial it seems strange to include it here, but …
router#configure terminal router(config)#interface FastEthernet4 router(config-if)#ip address 192.168.1.1 255.255.248.0 router(config-if)#ip nat outside router(config-if)#ip virtual-reassembly router(config-if)#duplex auto router(config-if)#speed auto router(config-if)#end
Perhaps the only oddity there is the use of ‘ip virtual-reassembly’ which is essentially used to protect the router (and in effect the rest of the network) from fragmented packet attacks. And if you prefer to leave CDP enabled, you may also want to stop that on the external interface with “no cdp enable” as well.