Let’s assume the following for this example:

• We have 2 public IP addresses (192.168.1.1 & 192.168.1.2)
• The IP address on the outside interface has been configured to use PAT for all internal IP addresses for Internet access (192.168.1.1)
• I have a DMZ with 3 servers, FTP, E-mail, and Web Server (10.0.1.1, 10.0.1.2 & 10.0.1.3 respectively)
• I need my 3 DMZ servers to be reachable from the Internet.

The above scenario poses a slight problem. If I have already used one of my public addresses for PAT to allow all internal hosts to access the Internet, I only have one IP address left but I require 3 static NAT entries to be created. In my post on Static NAT we saw that we configure NAT to map on a one-to-one basis, so in this scenario I would require 3 IP addresses, one for each of my DMZ servers.

The nice thing about the above scenario, is that each of the three servers is hosting a totally different service and therefore each requires different ports to be accessible from the Internet. This allows me to create static NAT’s that specify the ports, a type of overload function.

FTP would require ports 20,21 to be allowed
E-mail would require port 25 to be opened, and possibly 143 and 110 if you are using IMAP or POP
Web Server will require port 80, and possibly 443 if there is any SSL been used (https).

The above can be configured in the following way (interfaces would need to be configured as inside and outside as well, as seen here)

AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.1 192.168.1.2 20
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.1 192.168.1.2 21

AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.2 192.168.1.2 25
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.2 192.168.1.2 143
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.2 192.168.1.2 110

AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.3 192.168.1.2 80
AOIP.ORG (config) # ip nat inside source static tcp 10.0.1.3 192.168.1.2 443

The post Static NAT overloaded??? appeared first on AO!P.

PAT or otherwise known as NAT overload, allows you to translate IP addresses in a many-to-one method.

In my previous post on Configuring Dynamic NAT we saw that we can NAT many-to-many  but this was limited by the amount of public addresses that you have available. In cases such as home ADSL, your ISP will only issue you with a single public IP address but you might have 2 or more devices that need to access the Internet at any given time. This is where PAT takes over and makes this all possible.

As with any NAT configuration we need to first define our inside and outside interfaces. In this example I’ll use FastEthernet 0/0 as my inside, and Serial 0 as my outside.

AOIP.ORG (config) # interface FastEthernet 0/0
AOIP.ORG (config-if) # ip nat inside
AOIP.ORG (config-if) # interface Serial 0
AOIP.ORG (config-if) # ip nat outside

The next step is to define which addresses in my inside network I want to allow to be translated. Let’s assume my inside IP address range is 10.0.1.0 /24

AOIP.ORG (config) # access-list 1 permit 10.0.1.0 0.0.0.255

(Using a standard access-list is the easiest way to achieve this)

Then I need to configure the address that will be used by my internal IP addresses for accessing the outside interface. This can be done in 2 ways:

Option 1:
If I only have 1 public IP address, which is the case with home ADSL, the router will already have that IP address allocated to it by your ISP. The only thing I can do is tell the router to share that address with my internal hosts.

AOIP.ORG (config) # ip nat inside source list 1 Serial 0 overload

(This defines my access-list 1 as the source addresses, and tell them to be translated into the same IP address that is configured on Serial 0. The overload command tells the router that it needs to keep track of all the source and destination ports so the IP address can be used multiple times, overloaded)

Option 2:
If I have a second public IP address that I would like to use for Internet browsing, I can configure PAT for that IP address.

AOIP.ORG (config) # ip nat inside source list 1 192.168.1.1 overload

(Same as the above command, but I’ve specifically told the router which IP address to translate my internal hosts into)

This option is fantastic if you have multiple public addresses and you want to segment your Internet browsing based on departments or geographic locations. For example:

Marketing – 10.1.0.0 /24
Sales – 10.2.0.0 /24
Technical – 10.3.0.0 /24

I can have each of the above departments using their own public IP address, which will make log files easier to read when tracking Internet use and for troubleshooting connection errors.

access-list 2 permit 10.1.0.0 0.0.0.255
access-list 3 permit 10.2.0.0 0.0.0.255
access-list 4 permit 10.3.0.0 0.0.0.255
ip nat inside source list 2 192.168.1.2 overload
ip nat inside source list 3 192.168.1.3 overload
ip nat inside source list 4 192.168.1.4 overload

The post Configuring PAT on Cisco Routers (NAT Overload) appeared first on AO!P.

Dynamic NAT allows us to translate many IP addresses into a pool of many IP addresses. The big thing to realize here is that the pool does not need to contain enough IP addresses to translate all the internal addresses at the same time, as would be the case if we used Static NAT. Dynamic NAT allows internal hosts to be translated into an IP address in the pool when it requires a connection. Once the internal host has finished it’s session the NAT entry is removed from the NAT table allowing another internal host to use the external IP address for it’s session.

Assume we have 50 hosts in our inside network but only have 5 public IP addresses available to use. With Dynamic NAT we can allow all 50 internal addresses to share the 5 public addresses as and when they need them. This of course does impose a limit of only 5 simultaneous connections to the outside world and that is where PAT would come in and solve that problem.

On of the benefits of using Dynamic NAT vs Static NAT, is that Dynamic NAT requires the session to originate from the inside network. No outside connections can be established to the inside network. This is obviously a more secure solution as connections from the outside won’t work; only traffic originating from the inside will be translated. Static NAT is different in the fact that the entry is added to the NAT table on a permanent basis and will allow connections in either direction.

Here are the steps to configure Dynamic NAT on a Cisco Router.

Step 1 : I need to define the IP address range that will be translated (my inside IP addresses). I can do this with a standard access-list

AOIP.ORG (config)# access-list 1 permit 10.0.1.0 0.0.0.255

(don’t forget, access-lists use wildcard masks, not subnet masks)

Step 2 : I need to configure the range of addresses that my internal network will be translated into by using a NAT pool.

AOIP.ORG (config) # ip nat pool MY_POOL 10.50.1.1 10.50.1.5 netmask 255.255.255.0

(There are 5 IP addresses that can be used for translation in this example)

Step3 : Define inside and outside interfaces

AOIP.ORG (config) # interface FastEthernet 0/0
AOIP.ORG (config-if) # ip nat inside
AOIP.ORG (config-if) # interface Serial 0
AOIP.ORG (config-if) # ip nat outside

Step 4 : Configure the translation to take place.

AOIP.ORG (config) # ip nat inside source list 1 pool MY_POOL

(List 1 is my access-list that defined my inside IP addresses, MY_POOL defined the IP addresses to be used for the translation)

The post Configuring Dynamic NAT on Cisco Routers appeared first on AO!P.

Static NAT is a one-to-one mapping. It allows us to translate a single IP address into a different single IP address. This is most commonly found when you have a server inside your DMZ that you would like to allow the outside world (The Internet) to connect to, such as E-mail servers, FTP servers and Web servers (if you’re hosting your own).

The first step in configuration static NAT, is to define which interfaces on your router are involved in the NAT process and then configuring your Cisco router to know which interface is on which side of the network. Your Cisco router needs to know which interface is the inside interface and which is the outside interface to allow the translation to take place.

For example purposes let’s assume that FastEthernet 0/0 is the inside interface, and Serial 0 is my outside.

AOIP.ORG
AOIP.ORG # conf t
AOIP.ORG (config)# interface FastEthernet 0/0
AOIP.ORG (config-if)# ip nat inside
AOIP.ORG (config-if)# interface Serial 0
AOIP.ORG (config-if)# ip nat outside

So we have just informed our Cisco router of the inside and the outside, the next step is to tell your Router how to translate and what to translate.

Let’s assume that I have a server in my DMZ that has an IP address of 10.0.1.1 and I have a public IP address of 192.168.1.1 (yes I know this a private range part of RFC 1918, but for example purposes, let’s assume it’s not).

AOIP.ORG (config)# ip nat inside source static 10.0.1.1 192.168.1.1

That’s it, your done. When your server 10.0.1.1 connects to anything on Serial 0 and beyond, the source IP address will be translated into 192.168.1.1. Similarly, when someone from the Internet connects to the IP address 192.168.1.1 it will be translated into a destination IP address of 10.0.1.1 and hence connect to our server in the DMZ (Access-list permitting).

The post Configuring Static NAT on Cisco Routers appeared first on AO!P.

There are 3 ways to configure NAT on a Cisco Router:

1. Static NAT
2. Dynamic NAT
3. NAT overload (PAT – Port Address translation)

Static NAT is a one-to-one mapping. This is usually only required when you have a server inside your network (ie: Webserver, FTP, E-mail) that needs to be accessed from the internet. Users on the internet will access a public IP address that you have statically and permanently linked to your servers internal IP address. Of course any time your internal server sends packet to the internet, it’s source IP address will be translated into a public IP address configured with static NAT.

Dynamic NAT is used for many-to-many mapping. This will allow all your internal computers to be translated into a pool of public IP addresses, however if you only have 10 public IP addresses available in the NAT pool, only 10 computers will be able to access the public network at a time. Each computer will consume one public address at a time which makes this very limited for public internet access. The main purpose for dynamic NAT is to fix overlap IP addresses often experienced after a merger or acquisition. Since all companies use RFC 1918 for internal addresses, it’s not uncommon for 2 companies to be using the exact same internal IP addresses. When a merger or acquisition takes place there are issues with the IP addresses conflicting. Dynamic NAT allows us to translate the internal IP addresses from company ‘A’ into something unique that company ‘B’ does not use, and similarly translate all the internal IP addresses in company ‘B’ into something unique that company ‘A’ does not use. In most cases the ‘public’ address that the two companies will be translated into, will be part of RFC 1918 and will be used purely to resolve IP address overlaps, and NOT internet access.

NAT overload, or otherwise known as PAT (Port Address Translation), allows us to create a many-to-one mapping. Every computer in your network will be translated into a single Public IP address. This allows us to save on public addresses but still allows each computer in our organisation to access the internet at the same time. PAT identifies each session based on the source port number used in the communication flow. Since each session uses a random source port number, each session in theory should have a different number which allows PAT to associate a session with the single public IP addresses been shared. In the occurrence of two computers randomly choosing the same source port number, PAT will translate the port number and keep a record of the original as well as the new translated port to maintain the session. PAT will not allow internet users to access your internal servers as there is no mapping from outside to inside. The maximum theoretical limit for sharing a single IP address is 64,513 however the practical limit is dependent on the router or firewall doing the PAT and is usually limited to no more than 4,000 sessions to a single IP address.

The post NAT (Network Address Translation) appeared first on AO!P.

Ether Channels can be created as Layer 2 or Layer3. The obvious difference between the 2 is that a Layer 3 link will have a IP address associated and hence traffic can be routed between the 2 switches. A layer 2 ether channel will not have IP addresses attached and all traffic will be switched between the 2 devices.

There is a misconception about how the ‘load balancing’ works over a ether channel, so firstly lets clear that up.

An ether channel allows us to group multiple interfaces together so they act as one. This means that if I have 5 x 1 Gigabit Ethernet interfaces that I bind together I will in theory have a 5 Gigabit Ethernet interface. This is partly true but let’s dig deeper into how the switch will send traffic over the new link.

By Default, most Cisco switches are configured with a load balancing option of ‘source to destination IP’, what this means is that when the first session is created between machine A and machine B their traffic will use the same physical interface from the ether channel bundle. The packets will not be load balanced between all the ports. However when machine C sends traffic to machine D they would use a different physical interface compared to machine A and B. What we can derive from this, is that the load-balancing is session orientated and each session will be limited to 1 physical interface. So although the total throughput of data between the 2 switches is 5 Gigabit, the maximum throughput between 2 machines is the total of 1 physical interface of the ether channel.

The load-balancing technique can be changed from its default using the port-channel load-balance command, as seen below.

port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port}

NOTE: not all switches support all options of load-balancing!

So now that we have seen the concept of Ether Channels and how their load-balancing works, here is the configuration for configuring a Layer 2 Ether Channel.

AOIP.ORG-Switch(config)# interface range f0/4 – 5

The interface range command allow me to configure multiple interfaces at the same time, in this case FastEthernet 0/4 and 0/5

AOIP.ORG-Switch(config-if-range)# channel-group 1 mode desirable

This associates the interfaces to a new logical interface and tells the interface to actively negotiate a trunk.

AOIP.ORG-Switch(config-if-range)# no shut

AOIP.ORG-Switch(config-if-range)# exit

AOIP.ORG-Switch(config)# exit

In order to configure a Layer 3 Ether Channel, the following configuration can be used.

AOIP.ORG-Switch(config)# interface port-channel 10

This enters the logical interface used for the Ether Channel, I have given it a ‘name’ of 1

AOIP.ORG-Switch(config-if)# no switchport

Forces the port to act as a routed port and not a switchport

AOIP.ORG-Switch(config-if)# ip address 10.0.100.1 255.255.255.0

Assigns the IP address to the interface

AOIP.ORG-Switch(config-if)# no shut

AOIP.ORG-Switch(config-if)# exit

AOIP.ORG-Switch(config)# interface range f0/4 -5

Same as with a Layer 2 Ether Channel, I’m configuring 2 interfaces to belong to the Ether Channel

AOIP.ORG-Switch(config-if-range)# no switchport

Forcing the physical ports in Routed ports (Layer 3 port)

AOIP.ORG-Switch(config-if-range)# no ip address

Removing any IP addresses that may be configured on the physical interfaces. They may not have an IP address as it will be associated to the logical interface (port-channel 10)

AOIP.ORG-Switch(config-if-range)# channel-group 10 mode desirable

Binds the physical interfaces to the logical interface

AOIP.ORG-Switch(config-if-range)# no shut

AOIP.ORG-Switch(config-if-range)# exit

AOIP.ORG-Switch(config)# exit

The post Creating Layer 2 and Layer 3 Ether Channels appeared first on AO!P.

ISDN BRI (Basic Rate Interface) interfaces have 2 B-channels. By default when you create a connection using ISDN only one of these channels will dial. In order for us to use the additional B-channel we need to insert an additional command under our BRI interface (PPP Multilink)

Similarly ISDN PRI (Primary Rate Interface) interfaces have (23 B-Channels on T1, 30 B-Channels on E1) each of the channels on a PRI line run at 64kb/s and often we would like to use more than just one channel for our backup.

Although we can have all channels connect immediately when the ISDN becomes active; this results in all lines been billed by the PSTN. Instead we would rather have additional lines been brought up one at a time when the traffic demands it. We can achieve this by defining a load threshold that the line must be under before bringing up additional channels.

The load-threshold command is on a scale from 1 to 255 where 255 is equal to 100% utilisation.

AOIP.ORG(config)# interface bri 2/0
AOIP.ORG(config-if)# ppp multilink
AOIP.ORG(config-if)# dialer load-threshold 128 either

In the above example, I have set a threshold of 128 (50%) and this is based on traffic either inbound or outbound. In order to only monitor traffic inbound, replace ‘either’ with inbound. The same applied to outbound traffic.

NOTE: In order to use PPP multilink, both sides of the link need to be configured for its use.

The post ISDN and Multilink with load-threshold appeared first on AO!P.

Using floating static routing as a backup solution works on the following principle:

1. A dynamic routing protocol is running over your primary line
2. When the link fails, the routing updates will fail and the routing table will flush
3. A static route that uses the dial-up interface will become the best route
4. The backup interface will dial and traffic will continue to flow
5. When the primary line comes back up the dynamic routing protocol will fill the routing table, overwriting the floating static.

NOTE: Any type of dial-up interface may be used (modem / ISDN / 3G etc)

Based on the above it’s important to understand a few things about routing.

• A router will look for a route with the longest match (most specific route wins).
• If more than one identical route exists, the route with the LOWEST administration distance will be inserted into the routing table

So in order for us to configure floating static routes, we need 2 things configured.

• A dynamic routing protocol MUST be configured for this solution
• An identical static route must be created with an administrative distance higher than our routing protocol.

Example:

If I am running EIGRP as my routing protocol and it has learnt a route to network 192.168.1.0 /24 with an admin distance of 90 ( EIGRP has an administrative distance of 90 by default). I must create a static route for the network 192.168.1.0 /24 with a next hop of my remote routers dial-up interface. A static route however has a default administrative distance of 1, which at this point would mean it would overwrite my dynamically learnt route and all my traffic would be sent over my dial-up interface leaving me with a rather large phone bill. So when I create my static route it’s imperative that I change the default administrative distance to something higher than that of my routing protocol – I suggest a value of 250.

My static route would look like this:

AOIP.ORG(config)# ip route 192.168.1.0 255.255.255.0 10.0.1.1 200

Destination network : 192.168.1.0

Subnetmask for destination : 255.255.255.0

Next hop address of the remote routers dial-up interface: 10.0.1.1

Administrative Distance : 200

The post Floating Static Routes appeared first on AO!P.

For example: If I define an access-list that allows telnet and denies everything else, then telnet is the only traffic that will cause my ISDN interface to dial the remote router. Once the line has connected, ANY traffic may flow over the ISDN line. The router is looking purely for ‘interesting traffic’ so if no telnet traffic is sent over the line for the idle-timeout value, the line will drop.

This type of installation of ISDN is fantastic for very small branch offices that do not need to be connected to HQ permanently and you only need the link to be established for short periods of time. This however is not a good link backup solution.

In the below configuration we have created an access-list that will allow telnet traffic to cause the link to be established.

AOIP.ORG(config)# access-list 102 permit tcp any any eq telnet

Create the Access-list to be used to specify interesting traffic

AOIP.ORG(config)# dialer-list 2 protocol ip list 102    

The dialer-list defines what traffic is interesting, in this case – Access list 102

AOIP.ORG(config)# isdn switch-type basic-net3

Define the switch-type needed for ISDN, This is the settings for BRI interfaces in Europe and Africa

AOIP.ORG(config)# int bri 2/0

Enter the BRI interface you wish to configure

AOIP.ORG(config-if)# ip address 10.0.1.1

Set an IP address on the ISDN interface

AOIP.ORG(config-if)# encapsulation ppp

Define PPP as the encapsulation method

AOIP.ORG(config-if)# ppp authentication chap

Authentication for PPP has been set to CHAP

AOIP.ORG(config-if)# dialer-group 2

This tells our ISDN interface to use Dialer-list 2, you will notice the numbers for ‘dialer-group’ and ‘dialer-list’ match

AOIP.ORG(config-if)# dialer idle-timeout 180

If no interesting traffic is sent for 180 seconds, the line will drop

AOIP.ORG(config-if)# dialer map ip 10.0.1.2 name Router2 5551234  

If you need to connect to the IP address 10.0.1.2 (The remote routers ISDN interface), The remote router is name “Router2” and the telephone number to dial is “5551234”

AOIP.ORG(config-if)# no shut

AOIP.ORG(config)# ip route 192.168.2.0 255.255.255.0 10.0.1.2

Create a static route for the remote subnet with a next hop of Router2’s ISDN interface.

AOIP.ORG(config)# username Router2 password aoip

The remote routers hostname and a password that will be used for PPP authentication

The post Configuring Basic ISDN with Interesting Traffic appeared first on AO!P.

The switch-type is very much country dependant so it’s also important to memorize the switch-type that applies to where you do most of your installations.

If Layer-1 is showing ‘Deactivated’ when using the show isdn status command, only 3 things can be the source of the problem.

1. isdn switch-type has not been set, or has not been set correctly (The most common problem)
2. There is a problem with the PSTN (call your telephony service provider)
3. Cable problems
4. Physical port failure on the Router.

In order to configure the switch-type you can enter the command

Isdn switch-type {switch-type}

This can be done either in global configuration mode, or on the interface depending on the router and IOS version.

Below are all the switch-type options available 

The post ISDN Switch-type appeared first on AO!P.