Private and Public IP Addresses: What’s the Difference?


IP Address

Internet Protocol (IP) addresses are usually of two types: Public and Private. If you have ever wondered to know what is the difference between a public and a private IP address, then you are at the right place.

In this post I will try to explain the difference between a public and a private IP address in layman’s terms so that it becomes simple and easy to understand.

What are Public IP Addresses?

A public IP address is assigned to every computer that connects to the Internet where each IP is unique. In this case, there cannot exist two computers with the same public IP address all over the Internet. This addressing scheme makes it possible for the computers to “find each other” online and exchange information. User has no control over the IP address (public) that is assigned to the computer. The public IP address is assigned to the computer by the Internet Service Provider as soon as the computer is connected to the Internet gateway.

A public IP address can be either static or dynamic. A static public IP address does not change and is used primarily for hosting web pages or services on the Internet. On the other hand, a dynamic public IP address is chosen from a pool of available addresses and changes each time one connects to the Internet.

Most Internet users will only have a dynamic IP assigned to their computer which goes off when the computer is disconnected from the Internet. Thus when it is re-connected it gets a new IP.

You can check your public IP address by visiting www.whatismyip.com

What are Private IP Addresses?

An IP address is considered private if the IP number falls within one of the IP address ranges reserved for private networks such as a Local Area Network (LAN). The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks (local networks):

10.0.0.0 - 10.255.255.255 (Total Addresses: 16,777,216)
172.16.0.0 - 172.31.255.255 (Total Addresses: 1,048,576)
192.168.0.0 - 192.168.255.255 (Total Addresses: 65,536)

Private IP addresses are used for numbering the computers in a private network including home, school and business LANs in airports and hotels which makes it possible for the computers in the network to communicate with each other.

Say for example, if a network X consists of 10 computers, each of them can be given an IP starting from 192.168.1.1 to 192.168.1.10. Unlike the public IP, the administrator of the private network is free to assign an IP address of his own choice (provided the IP number falls in the private IP address range as mentioned above).

Devices with private IP addresses cannot connect directly to the Internet. Likewise, computers outside the local network cannot connect directly to a device with a private IP. It is possible to interconnect two private networks with the help of a router or a similar device that supports Network Address Translation.

If the private network is connected to the Internet (through an Internet connection via ISP), then each computer will have a private IP as well as a public IP. Private IP is used for communication within the network where as the public IP is used for communication over the Internet. Most Internet users with a DSL/ADSL connection will have both a private as well as a public IP.

You can know your private IP by typing ipconfig command in the command prompt. The number that you see against “IPV4 Address:” is your private IP which in most cases will be 192.168.1.1 or 192.168.1.2. Unlike the public IP, private IP addresses are always static in nature.

Common Myth about Private IP Address:

Most people assume that a private IP is the one used for stealth Internet activities and hence cannot be detected. But this is NOT TRUE!.

Unlike what most people think, a private IP address (unlike the private telephone number) is just like any other IP address that belongs to a private network. In reality, there is no public IP address that is impossible to trace as the protocol itself is designed for transparency.

Online Networking tools

Visual Subnet Calculator

Subnet Mask Cheat Sheet


Addresses Hosts Netmask Amount of a Class C
/30 4 2 255.255.255.252 1/64
/29 8 6 255.255.255.248 1/32
/28 16 14 255.255.255.240 1/16
/27 32 30 255.255.255.224 1/8
/26 64 62 255.255.255.192 1/4
/25 128 126 255.255.255.128 1/2
/24 256 254 255.255.255.0 1
/23 512 510 255.255.254.0 2
/22 1024 1022 255.255.252.0 4
/21 2048 2046 255.255.248.0 8
/20 4096 4094 255.255.240.0 16
/19 8192 8190 255.255.224.0 32
/18 16384 16382 255.255.192.0 64
/17 32768 32766 255.255.128.0 128
/16 65536 65534 255.255.0.0 256

 

Guide to sub-class C blocks

/25 — 2 Subnets — 126 Hosts/Subnet

Network # IP Range Broadcast
.0 .1-.126 .127
.128 .129-.254 .255

/30 — 64 Subnets — 2 Hosts/Subnet

Network # IP Range Broadcast
.0 .1-.2 .3
.4 .5-.6 .7
.8 .9-.10 .11
.12 .13-.14 .15
.16 .17-.18 .19
.20 .21-.22 .23
.24 .25-.26 .27
.28 .29-.30 .31
.32 .33-.34 .35
.36 .37-.38 .39
.40 .41-.42 .43
.44 .45-.46 .47
.48 .49-.50 .51
.52 .53-.54 .55
.56 .57-.58 .59
.60 .61-.62 .63
.64 .65-.66 .67
.68 .69-.70 .71
.72 .73-.74 .75
.76 .77-.78 .79
.80 .81-.82 .83
.84 .85-.86 .87
.88 .89-.90 .91
.92 .93-.94 .95
.96 .97-.98 .99
.100 .101-.102 .103
.104 .105-.106 .107
.108 .109-.110 .111
.112 .113-.114 .115
.116 .117-.118 .119
.120 .121-.122 .123
.124 .125-.126 .127
.128 .129-.130 .131
.132 .133-.134 .135
.136 .137-.138 .139
.140 .141-.142 .143
.144 .145-.146 .147
.148 .149-.150 .151
.152 .153-.154 .155
.156 .157-.158 .159
.160 .161-.162 .163
.164 .165-.166 .167
.168 .169-.170 .171
.172 .173-.174 .175
.176 .177-.178 .179
.180 .181-.182 .183
.184 .185-.186 .187
.188 .189-.190 .191
.192 .193-.194 .195
.196 .197-.198 .199
.200 .201-.202 .203
.204 .205-.206 .207
.208 .209-.210 .211
.212 .213-.214 .215
.216 .217-.218 .219
.220 .221-.222 .223
.224 .225-.226 .227
.228 .229-.230 .231
.232 .233-.234 .235
.236 .237-.238 .239
.240 .241-.242 .243
.244 .245-.246 .247
.248 .249-.250 .251
.252 .253-.254 .255

/26 — 4 Subnets — 62 Hosts/Subnet

Network # IP Range Broadcast
.0 .1-.62 .63
.64 .65-.126 .127
.128 .129-.190 .191
.192 .193-.254 .255

/27 — 8 Subnets — 30 Hosts/Subnet

Network # IP Range Broadcast
.0 .1-.30 .31
.32 .33-.62 .63
.64 .65-.94 .95
.96 .97-.126 .127
.128 .129-.158 .159
.160 .161-.190 .191
.192 .193-.222 .223
.224 .225-.254 .255

/28 — 16 Subnets — 14 Hosts/Subnet

Network # IP Range Broadcast
.0 .1-.14 .15
.16 .17-.30 .31
.32 .33-.46 .47
.48 .49-.62 .63
.64 .65-.78 .79
.80 .81-.94 .95
.96 .97-.110 .111
.112 .113-.126 .127
.128 .129-.142 .143
.144 .145-.158 .159
.160 .161-.174 .175
.176 .177-.190 .191
.192 .193-.206 .207
.208 .209-.222 .223
.224 .225-.238 .239
.240 .241-.254 .255

/29 — 32 Subnets — 6 Hosts/Subnet

Network # IP Range Broadcast
.0 .1-.6 .7
.8 .9-.14 .15
.16 .17-.22 .23
.24 .25-.30 .31
.32 .33-.38 .39
.40 .41-.46 .47
.48 .49-.54 .55
.56 .57-.62 .63
.64 .65-.70 .71
.72 .73-.78 .79
.80 .81-.86 .87
.88 .89-.94 .95
.96 .97-.102 .103
.104 .105-.110 .111
.112 .113-.118 .119
.120 .121-.126 .127
.128 .129-.134 .135
.136 .137-.142 .143
.144 .145-.150 .151
.152 .153-.158 .159
.160 .161-.166 .167
.168 .169-.174 .175
.176 .177-.182 .183
.184 .185-.190 .191
.192 .193-.198 .199
.200 .201-.206 .207
.208 .209-.214 .215
.216 .217-.222 .223
.224 .225-.230 .231
.232 .233-.238 .239
.240 .241-.246 .247
.248 .249-.254 .255

What switches can be used with PING?


PING does have a number of option parameters to accomplish different objectives.

ping \[-t\] \[-a\] \[-n count\] \[-l size\] \[-f\] \[-i TTL\] \[-v TOS\] \[-r count\] \[-s count\] \[-k host-list \[-w timeout\] destination-list

-t Ping the specifed host until interrupted.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don’t Fragment flag in packet.
-i TTL Time To Live.
-v TOS Type Of Service.
-r count Record route for count hops.
-s count Timestamp for count hops.
-j host-list Loose source route along host-list.
-k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.

In Windows 2000 you can press Ctrl-Break when running the -t option for a list of statisitics. Press Ctrl-C to actually stop the ping.

1) Increase or Decrease the Time Interval Between Packets:

ping -i 5 127.12.3.6

Wait for 5 seconds before sending the next packet.

ping -i 0.1 127.12.3.6

Wait 0.1 seconds before sending the next packet.

2) Check whether the local network interface is up and running:

Ping localhost using zero (0)

ping 0
PING 0 (127.0.0.1) 56(84) bytes of data.

ping localhost <or> ping 127.0.0.1

3) Send N packets and stop:

In the following example, ping command sends 5 packets, and waits for response from the destination host. Ping will exit after receiving the response or error.

$ ping -c 5 google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=1 ttl=44 time=731 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=2 ttl=44 time=777 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=3 ttl=44 time=838 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=4 ttl=44 time=976 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=5 ttl=44 time=1071 ms

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4216ms

4) Show Version and Exit:
ping -V

5) Flood the network:

Super users can send hundred or more packets per second using -f option. It prints a ‘.’ when a packet is sent, and a backspace is printed when a packet is received.

As shown below, ping -f has sent more than 400,000 packets in few seconds.

# ping -f localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
.^C
--- localhost ping statistics ---

6) Audible ping: Give beep when the peer is reachable:
ping -a IP

7) Find out the IP address:
ping -c 1 google.com
PING google.com (74.125.67.100) 56(84) bytes of data.
64 bytes from gw-in-f100.google.com (74.125.67.100): icmp_seq=1 ttl=43 time=287 ms

--- google.com ping statistics ---

8) Print Only Ping Command Summary Statistics:

ping -c 5 -q 127.0.0.1 
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

--- 127.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
9) Change Ping Packet Size:
ping -s 100 localhost
PING localhost (127.0.0.1) 100(128) bytes of data.
108 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.022 ms
108 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.021 ms
108 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.020 ms
^C
--- localhost ping statistics ---

10) Timeout:

Ping -w option specifies the deadline to terminate the ping output. This specifies the total number of seconds the ping command should send packets to the remote host.

The following example will ping for 5 seconds. i.e ping command will exit after 5 seconds irrespective of how many packets are sent or received.

$ ping -w 5 localhost

Note: When you specify both -w, and -c, whichever comes first will terminate the ping command.

11) Shorter statistics with SIGQUIT:

While ping is printing the individual packet status, when you want to view the shorter statistics you can use this technique.

Pressing CTRL+| (Control key followed by pipe symbol) for the shows the summary in between, and continues with it packet sending and receiving process.

$ ping -w 100 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=10 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_seq=11 ttl=64 time=0.022 ms
11/11 packets, 0% loss, min/avg/ewma/max = 0.020/0.022/0.022/0.024 ms
64 bytes from localhost (127.0.0.1): icmp_seq=12 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_seq=13 ttl=64 time=0.022 ms
64 bytes from localhost (127.0.0.1): icmp_seq=14 ttl=64 time=0.021 ms
64 bytes from localhost (127.0.0.1): icmp_seq=15 ttl=64 time=0.021 ms
19/19 packets, 0% loss, min/avg/ewma/max = 0.020/0.022/0.022/0.024 ms
64 bytes from localhost (127.0.0.1): icmp_seq=31 ttl=64 time=0.022 ms
64 bytes from localhost (127.0.0.1): icmp_seq=32 ttl=64 time=0.022 ms
32/32 packets, 0% loss, min/avg/ewma/max = 0.020/0.022/0.022/0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=33 ttl=64 time=0.023 ms

12) ecord and print route of how ECHO_REQUEST sent and ECHO_REPLY received:

It records, and prints the network route through which the packet is sent and received. This is useful for network engineers who wish to know how the packet is sent and received.

$ ping -R 192.168.1.63
PING 192.168.1.63 (192.168.1.63) 56(84) bytes of data.
64 bytes from 192.168.1.63: icmp_seq=1 ttl=61 time=2.05 ms
RR:   192.168.9.118
        192.168.3.25
        192.168.10.35
        192.168.1.26
        192.168.1.63
        192.168.1.63
        192.168.10.4
        192.168.3.10
        192.168.4.25
64 bytes from 192.168.1.63: icmp_seq=2 ttl=61 time=2.00 ms      (same route)

What is ARP/RARP?


What is ARP/RARP?

ARP: Stands for Address Resolution Protocol…whenever a request is sent by a node on one network to the node on another network the Physical address(MAC) is required and for this the IP address need to be flow over the network..whenver a router with that network (IP) gets the msg. the required MAC address is sent through the network this process of converting the IP address to MAC address is Called ARP..and the reverse thats the convertion of the Mac address to the IP address is called RARP ( Reverse Address Resolution Protocol)

Cisco IOS NAT on a Stick Configuration Example


NAT (Network Address Translation) is most commonly used to let users on our  LAN access the Internet using a single public IP address but it can be used for  some more interesting scenarios. Recently I encountered an interesting CCIE  R&S task that had the following requirement:

"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface"

This sounds easy enough but there’s no such thing as a “traceroute source loopback 0″ command or anything alike. To make this work we have to configure the NAT on a stick feature. In this tutorial I’ll show you this is done. First of all, this is the topology that we will use:

Two Routers R2 Loopback Interface

There are only two routers that are directly connected to each other. R2 has  a loopback 0 interface with IP address 2.2.2.0 /24. Let’s configure these IP  addresses first:

R1(config)#interface fa0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fa0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#interface loopback0
R2(config-if)#ip address 2.2.2.2 255.255.255.0

Before we dive into the NAT configuration let’s do a trace and look at the  output:

R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

  1 192.168.12.2 0 msec 4 msec *

As expected R2 responds with the IP address on its FastEthernet interface.  The task requires this output to show the 2.2.2.2 address from the loopback  interface. To achieve this we’ll configure NAT on R2:

R2(config)#access-list 100 permit icmp any any time-exceeded
R2(config)#access-list 100 permit icmp any any port-unreachable

R2(config)#ip nat inside source list 100 interface loopback0 overload

R2(config)#interface fastethernet 0/0
R2(config-if)#ip nat inside

R2(config)#interface loopback 0
R2(config-if)#ip nat outside

The configuration above defines the FastEthernet interface as NAT inside and  the loopback interface as NAT outside. An access-list is used to permit the ICMP  time-exceeded and port-unreachable packets that are used as a response to a  traceroute. The NAT configuration itself is complete but we still have a problem  with this setup, take a look at the following picture:

Cisco Traceroute ReplyIf you look closely at the image above you can see  that whenever R1 does a trace, R2 will reply with its FastEthernet 0/0  interface. In order for NAT to work traffic has to flow from the inside  interface to the outside interface. To fix this we can configure policy  based routing on R2 to forward traffic to the loopback 0 interface:

R2(config)#route-map FORWARD_TO_L0
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback0
R2(config)#ip local policy route-map FORWARD_TO_L0

This route-map matches on the interface that we created before and forwards  the traffic towards the loopback 0 interface. We also require the ip  local policy command to apply the route-map to self-generated  traffic. Let’s enable a debug on R2 and try that traceroute again from  R1:

R2#debug ip policy 
Policy routing debugging is on

R2#debug ip nat
IP NAT debugging is on

Time to trace!

R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

  1 2.2.2.2 0 msec 4 msec *

Excellent, we now see IP address 2.2.2.2 from R2 in our traceroute. Let’s  take a look at the debug on R2:

R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: local to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [17]

The first line is the ICMP packet from R2 towards R1 that it wants to send as  a reply to the traceroute. It matches the route-map so it is being policy based  routed towards the loopback 0 interface. Since the loopback 0 interface is  configured for NAT outside, IP address 192.168.12.2 is translated to 2.2.2.2 and  then routed towards R1. Basically it looks like this:

Cisco NAT on a Stick Example

Great! it’s working as it should…what if we make this scenario a little bit  more interesting by changing the task as following:

"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface, you are not allowed to configure NAT on the FastEthernet interface but you may configure an additional interface and IP address."

No problem! We can still make this work but we’ll have to use another  interface that is configured with the “IP NAT inside” command. Traffic still has  to flow from a NAT inside interface to a NAT outside interface in order to be  translated. To accomplish this we will create a new loopback interface that has  the “IP NAT inside” command. We will send traffic from the FastEthernet  interface to the new loopback and then forward it to the first loopback  interface. I know this sounds funky so let me help you visualize it:

Cisco NAT on a Stick Two Loopback Interfaces

Just follow the arrows starting at R1.  This is what we have to  configure:

  1. Configure policy based routing so that the ICMP replies are forwarded from  the FastEthernet interface to the new loopback 1 (NAT inside) interface.
  2. Configure policy based routing so that the ICMP replies are forwarded from  the loopback 1 interface to the loopback 0 (NAT outside) interface.

First we’ll remove the NAT configuration from the FastEthernet interface and  I’ll also get rid of the policy based routing configuration:

R2(config)#interface fa0/0
R2(config-if)#no ip nat inside
R2(config)#no ip local policy route-map FORWARD_TO_L0

Let’s create a new loopback interface. I just made up an IP address, it  really doesn’t matter what we configure here as long as there’s something. Don’t  forget to add IP NAT inside:

R2(config)#interface loopback 1
R2(config-if)#ip address 22.22.22.22 255.255.255.0
R2(config-if)#ip nat inside

We will create a new route-map that forwards ICMP traffic to the loopback 1  interface:

R2(config)#ip local policy route-map FORWARD_TO_L1
R2(config)#route-map FORWARD_TO_L1
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback 1

The route-map that we created before can now be applied to the loopback 1  interface. This ensures that traffic is forwarded to the loopback 0  interface:

R2(config)#interface loopback1
R2(config-if)#ip policy route-map FORWARD_TO_L0

That should do it. Let’s try our trace again:

R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

  1 2.2.2.2 4 msec 4 msec *

Excellent, it’s working! What does the debug look like now?

R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L1, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback1), len 56, policy routed
IP: local to Loopback1 192.168.12.1
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: Loopback1 to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [21]

Look closely at the debug and you can see that the ICMP traffic is forwarded  to the loopback 1 interface, then to the loopback 0 interface and because it  flowed from a NAT inside to a NAT outside interface it can now be  translated.

That’s all I have for you now, hopefully you enjoyed this tutorial! If you  have any questions feel free to leave a comment.

Read more: http://networklessons.com/network-services/cisco-ios-nat-stick-configuration-example/#ixzz2pnVLWiOm

How to configure EIGRP Authentication


Routing protocols can be configured to prevent receiving false routing  updates and EIGRP is no exception. If you don’t use authentication and you are  running EIGRP someone could try to form an EIGRP neighbor adjacency with one of  your routers and try to mess with your network…we don’t want that to happen  right?

EIGRP only offers MD5 authentication, there’s no plaintext  authentication.

What does authentication offer us?

  • Your router will authenticate the source of each routing update packet that  it will receive.
  • Prevents false routing updates from sources that are not approved.
  • Ignore malicious routing updates.

A potential hacker could be sitting on your network with a laptop running  GNS3 / Dynamips, boot up a Cisco router and try the following things:

  • Try to establish a neighbor adjacency with one of your routers and advertise  junk routes.
  • Send malicious packets and see if you can drop the neighbor adjacency of one  of your authorized routers.

In order to configure EIGRP authentication we need to do the following:

  • Configure a key-chain
    • Configure a key ID under the key-chain.
      • Specify a password for the key ID.
      • Optional: specify accept and expire lifetime for the key.

Let’s use two routers and see if we can configure EIGRP MD5  authentication:

EIGRP with keys The configuration for both routers is very  basic:

Jack(config)#interface fastEthernet 0/0
Jack(config-if)#ip address 192.168.12.1 255.255.255.0

Jack(config)#router eigrp 12
Jack(config-router)#network 192.168.12.0
John(config)#interface fastEthernet 0/0
John(config-if)#ip address 192.168.12.2 255.255.255.0

John(config)#router eigrp 12
John(config-router)#network 192.168.12.0

The first thing we need to configure is a key-chain:

EIGRP Keychain

I called mine “KingKong” but it can be different on both routers, it doesn’t  matter. The Key ID is a value that has to match on both routers and the  key-string is the password which has to match of course.

Jack(config)#key chain KingKong
Jack(config-keychain)#key 1
Jack(config-keychain-key)#key-string Banana
Jack(config)#interface fastEthernet 0/0
Jack(config-if)#ip authentication mode eigrp 12 md5 
Jack(config-if)#ip authentication key-chain eigrp 12 KingKong

First you have to create the keychain and then you need to activate it on the  interface. The “12” is the AS number of EIGRP. The configuration on router John  is exactly the same.

John#debug eigrp packets 
EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

John# EIGRP: FastEthernet0/0: ignored packet from 192.168.12.1, opcode = 5 (authentication off or key-chain missing)

You can check if your configuration is correct by using debug eigrp  packets. You can see that we received a packet with MD5 authentication but I  didn’t enable MD5 authentication yet on router John.

Let’s fix it:

John(config)#key chain KingKong
John(config-keychain)#key 1
John(config-keychain-key)#key-string Banana

John(config)#interface fastEthernet 0/0
John(config-if)#ip authentication mode eigrp 12 md5
John(config-if)#ip authentication key-chain eigrp 12 KingKong

Right away I can see that the EIGRP neighbor adjacency is working:

John# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (FastEthernet0/0) is up: new adjacency

What if I entered a wrong key-string?

Jack(config)#key chain KingKong
Jack(config-keychain)#key 1
Jack(config-keychain-key)#key-string Apples

Let’s see if KingKong likes apples…

John# EIGRP: pkt key id = 1, authentication mismatch

You will see the message above in the debug output on router John. At least  it tells us that key 1 is the one with the error.

You will see the message above in the debug output on router John. At least  it tells us that key 1 is the one with the error.

If you want to spice it up a bit you can set an accept and expire lifetime on keys. The idea behind this is that you can have keys  that are only valid for a day, a week, a month or something else. Do you want to  use this in real life? It might enhance security but it also makes maintenance a  bit more complex…

Before you configure keys with a limited lifetime make sure you set the  correct time and date. You can do this manually on each router but it’s better  to use a NTP (Network Time Protocol) server so all the routers have the same  time/date.

Anyway that’s all I wanted to show you! If you have any more questions please  leave a comment!

Read more: http://networklessons.com/eigrp/how-to-configure-eigrp-authentication/#ixzz2pnTR62WO

How to configure RIP on a Cisco router


RIP (Routing Information Protocol) is one of the routing protocols you need  to understand if you want to pass the Cisco CCNA exam. If you have no idea how  RIP works I suggest to read  this article first where I explain how RIP works. In this article I’ll show  you how to configure RIP on a Cisco router. This is the topology that I will  use:

RIP 3 routers

Above we see 3 routers called Spade, Hearts and Clubs. There are a couple of  networks so we’ll have something to advertise in RIP. First let’s configure all  the interfaces:

Spade>enable 
Spade#configure terminal 
Spade(config)#interface fastEthernet 0/0
Spade(config-if)#no shutdown
Spade(config-if)#ip address 172.16.1.1 255.255.255.0
Spade(config-if)#exit
Spade(config)#interface fastEthernet 1/0
Spade(config-if)#ip address 192.168.12.1 255.255.255.0
Spade(config-if)#no shutdown
Hearts>enable
Hearts#configure terminal
Hearts(config)#interface fastEthernet 0/0
Hearts(config-if)#no shutdown
Hearts(config-if)#ip address 192.168.12.2 255.255.255.0
Hearts(config-if)#exit
Hearts(config)#interface FastEthernet 1/0
Hearts(config-if)#no shutdown
Hearts(config-if)#ip address 192.168.23.2 255.255.255.0
Hearts(config-if)#exit

Clubs>enable
Clubs#configure terminal
Clubs(config)#interface fastEthernet 0/0
Clubs(config-if)#no shutdown
Clubs(config-if)#ip address 172.16.2.3 255.255.255.0
Clubs(config-if)#exit
Clubs(config)#interface fastEthernet 1/0
Clubs(config-if)#no shutdown
Clubs(config-if)#ip address 192.168.23.3 255.255.255.0
Clubs(config-if)#exit

Before we continue RIP we’ll check the routing tables:

Spade#show 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 - S-IS level-2
       ia - IS-IS inter area, * - candidate default, 
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, FastEthernet1/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
Hearts#show 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 - S-IS level-2
       ia - IS-IS inter area, * - candidate default, 
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, FastEthernet0/0
C    192.168.23.0/24 is directly connected, FastEthernet1/0
Clubs#show 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 - S-IS level-2
       ia - IS-IS inter area, * - candidate default, 
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.2.0 is directly connected, FastEthernet0/0
C    192.168.23.0/24 is directly connected, FastEthernet1/0

Our routers only know 1 thing…their directly connected interfaces. Let’s  configure RIP and see what happens:

Spade(config)#router rip
Spade(config-router)#network 192.168.12.0
Spade(config-router)#network 172.16.1.0
Hearts(config)#router rip
Hearts(config-router)#network 192.168.12.0

We use the router rip command to go to the RIP configuration. Next  step is to use the network command which does two things:

Let’s zoom in on router Spade and Hearts so I can explain this a bit  more…

RIP send Updates Both Ways

  1. All networks that fall in the range of the network command will be  advertised in RIP to other routers.
  2. RIP updates will be sent on the interface that falls in the range of the  network command.
Spade(config-router)#network 192.168.12.0

When I type “network 192.168.12.0” I will put all networks that fall within  the 192.168.12.0 range in the RIP database. The FastEthernet1/0 interface has  network 192.168.12.0 /24 so this will be placed in the RIP database. It will  also send RIP updates on this interface.

Spade(config-router)#network 172.16.1.0

172.16.1.0 /24 that is configured on FastEthernet 0/0 falls within the  172.16.1.0 range so it will be placed in the RIP database.

We will also send RIP updates on the FastEthernet 0/0 interface. This might  sound a bit silly since there is no other router connected to this interface,  there’s no point in sending RIP updates this direction. I’ll show you how to  deal with this later.

Let’s take a look at router Hearts:

RIP Advertise One Network

Hearts(config-router)#network 192.168.12.0

On router Hearts I only used the network command above. This means that it  will put 192.168.12.0 /24 in the RIP database and send RIP updates on its  FastEthernet 0/0 interface. At this moment it won’t advertise network  192.168.23.0 /24 in RIP and it won’t send RIP updates on the FastEthernet 1/0  interface.

Let’s check the routing tables of router Spade and Hearts!

Spade#show ip route rip 
Hearts#show ip route rip 
R    172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:21, FastEthernet0/0

Instead of typing “show ip route” you can also use show ip route rip.  This will show you only the RIP information in the routing table. As you can see  router Spade didn’t learn anything from router Hearts. This is because network  192.168.23.0 /24 isn’t advertised on router Hearts.

Router Hearts has learned network 172.16.0.0 /16. Why do we see 172.16.0.0  /16 and not 172.16.1.0 /24? Keep in mind that by default RIP is running  version 1 which is classful. It does NOT send a subnet mask along  with the routing updates. Since 172.16.1.0 /24 is in the class B range it will  be advertised as 172.16.0.0 /16.

I’ll configure RIP version 2 later so you can see the difference between  classless and classful.

Anyway let’s see if we can make router Spade learn about 192.168.23.0  /24:

Hearts(config)#router rip
Hearts(config-router)#network 192.168.23.0

I’ll use this network command; let me show you another picture of router  Hearts:

RIP Advertise Two Networks

When I use the “network 192.168.23.0” command it will place 192.168.23.0 /24  in the RIP database AND it will send RIP updates on the FastEthernet 1/0  interface. Let’s check router Spade:

Spade#show ip route rip 
R    192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:16, FastEthernet1/0

Now router Spade knows how to reach this network. Let’s take a closer look at  this entry…

R    192.168.23.0/24

The “R” means that this entry was learned through RIP and 192.168.23.0 /24 is  the network that we learned.

[120/1]

The first number (120) is the administrative distance. The second number (1)  is the metric. RIP uses “hop count” as the metric so network 192.168.23.0/24 is  1 hop away.

via 192.168.12.2

This is the next hop IP address. If we want to reach network 192.168.23.0 /24  we’ll send IP packets to 192.168.12.2.

00:00:16

This is the time since the last update for this entry. RIP sends an update  each 30 seconds so this value will never be higher than 29 seconds.

FastEthernet1/0

This is the outgoing interface. When we want to reach network 192.168.23.0  /24 we’ll use this interface for outgoing traffic.

There is one last thing I want to share with you about the network command.  Let me show you router Hearts one more time:

Router Hearts Two Interfaces Router Hearts has these two interfaces and I  used these network commands:

Hearts(config-router)#network 192.168.12.0
Hearts(config-router)#network 192.168.23.0

This works perfectly fine as you have seen. I also could have used just one  network command:

Hearts(config-router)#network 192.168.0.0

If I would have used network 192.168.0.0 I would have had the same result.  Both 192.168.12.0 /24 and 192.168.23.0 /24 fall within this range so RIP would  have been activated on both interfaces and network 192.168.12.0 /24 and  192.168.23.0 /24 would have been advertised.

Even the following network command would work:

Hearts(config-router)#network 0.0.0.0

Network 0.0.0.0 basically means “enable RIP on all interfaces and advertise  everything”. This is what we call the “shotgun approach”. I sometimes like to  use it in labs when I quickly want to advertise all networks on my router.

Don’t use anything like “network 0.0.0.0” on a  production network. It will work but it means that whenever someone adds a new  interface and configures an IP address on it that it will be advertised in RIP.  This is something you probably don’t want to happen “automagically”.

We still have one router to configure so let’s enable RIP on router Clubs  shall we?

Clubs(config)#router rip
Clubs(config-router)#network 172.16.2.0
Clubs(config-router)#network 192.168.23.0

First I’ll enable the network commands. Now let’s see what we find in our  routing tables:

Spade#show ip route rip 
R    192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:21, FastEthernet1/0
Hearts#show ip route rip 
R    172.16.0.0/16 [120/1] via 192.168.23.3, 00:00:15, FastEthernet1/0
                   [120/1] via 192.168.12.1, 00:00:11, FastEthernet0/0
Clubs#show ip route rip 
R    192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:26, FastEthernet1/0

Now this is an interesting output. There are a couple of interesting things  here:

  • Router Spade didn’t learn about network 172.16.2.0 /24.
  • Router Clubs didn’t learn about network 172.16.1.0 /24.
  • Router Hearts has 172.16.0.0 /16 in its routing table with two next hop IP  addresses:
    • 192.168.23.3.
    • 192.168.12.1.

At this moment we are running RIP version 1 which is classful. This  means that router Spade advertises 172.16.1.0 /24 as 172.16.0.0 and router Clubs  advertises 172.16.2.0 /24 as 172.16.0.0.

So what does router Hearts do with this information? Whenever you learn about  a network from two difference sources with the same metric, your router will  do load-balancing. For example when router Hearts receives an IP packet  meant for 172.16.1.1 it might send it to router Clubs and it will be  dropped.

Router Spade and Clubs are not learning about network 172.16.1.0 /24 or  172.16.2.0 /24 but why is this happening? Let me show you a picture:

RIP Classful Advertisement

Router Spade and Clubs both advertise 172.16.0.0 to router Hearts. Router  Hearts stores this information in its routing table but doesn’t advertise  172.16.0.0 to router Spade or Clubs because of split-horizon. You don’t  advertise to your neighbor what you learned from them…

So how to fix this? We need to make sure that router Spade and Clubs send a  subnet mask with their RIP updates….it’s time for RIP version 2 because it’s classless.

There is a very useful command to verify what routing protocols you are  using, let me show you:

Spade#show ip protocols 
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 21 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       1     1 2                                  
    FastEthernet1/0       1     1 2                                  
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.16.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:00:03
  Distance: (default is 120)

Show ip protocols is a very useful command so I recommend to write it  down somewhere. This isn’t just for RIP but it shows you information for any  other routing protocol. We can see that we are running RIP version 1 and that we  are sending RIP updates on interface FastEthernet 0/0 and 1/0. You can also see  the networks that we are advertising (172.16.0.0 and 192.168.12.0).

Let’s now switch our routers to RIP version 2:

Spade(config)#router rip
Spade(config-router)#version 2
Spade(config-router)#no auto-summary
Hearts(config)#router rip
Hearts(config-router)#version 2
Hearts(config-router)#no auto-summary
Clubs(config)#router rip
Clubs(config-router)#version 2
Clubs(config-router)#no auto-summary

Just type version 2 to switch to this version. By default RIP version  2 will behave classful and won’t send a subnet mask. I need to type no  auto-summary to make it behave classless and send a subnet mask with its RIP  updates.

Spade#show ip protocols 
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 19 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2                                    
    FastEthernet1/0       2     2                                    
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    172.16.0.0
    192.168.12.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.2         120      00:00:23
  Distance: (default is 120)

You can see that we are now using RIP version 2. Let’s see if there’s a  difference in our routing tables:

Spade#show ip route rip 
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.2.0 [120/2] via 192.168.12.2, 00:00:24, FastEthernet1/0
R    192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:24, FastEthernet1/0
Hearts#show ip route rip 
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/1] via 192.168.12.1, 00:00:08, FastEthernet0/0
R       172.16.2.0 [120/1] via 192.168.23.3, 00:00:26, FastEthernet1/0
Clubs#show ip route rip 
R    192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:16, FastEthernet1/0
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/2] via 192.168.23.2, 00:00:16, FastEthernet1/0

This is looking better. You can see that router Hearts has learned about  network 172.16.1.0 /24 and 172.16.2.0 /24. This is because Spade and Clubs are  advertising 172.16.1.0 /24 and 172.16.2.0 /24, not 172.16.0.0 anymore. Router  Spade and Clubs also have learned about each other’s networks.

You now know how to configure RIP and you have seen some show commands to  lookup information. We can also use a debug command to see in real-time  what our router is doing. Let’s look at a RIP example!

Hearts#debug ip rip 
RIP protocol debugging is on

Debug IP rip is how we enable it. You will see messages like these:

Hearts#
RIP: received v2 update from 192.168.12.1 on FastEthernet0/0
     172.16.1.0/24 via 0.0.0.0 in 1 hops

Here’s what you see when router Hearts receives a RIP update from router  Spade. We learn about network 172.16.1.0 /24.

RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (192.168.12.2)
RIP: build update entries
	172.16.2.0/24 via 0.0.0.0, metric 2, tag 0
	192.168.23.0/24 via 0.0.0.0, metric 1, tag 0

This is the RIP update that router Hearts will send towards router Spade. It  carries network 172.16.2.0 /24 and 192.168.23.0 /24. In case you are wondering  what the 224.0.0.9 means…RIP version 2 doesn’t use broadcast but multicast for  delivery. 224.0.0.9 is the multicast address for RIP version 2.

Last but not least I want to show you how to create summaries when using RIP.  Here’s the topology we will use:

RIP Summarization

On router Spade I have the 172.16.0.0 /24 and 172.16.1.0 /24 network. Here’s  the RIP configuration before summarization:

Spade(config-router)#version 2
Spade(config-router)#no auto-summary 
Spade(config-router)#network 192.168.12.0
Spade(config-router)#network 172.16.0.0
Hearts(config-router)#version 2
Hearts(config-router)#no auto-summary 
Hearts(config-router)#network 192.168.12.0

I will use version 2 and disable auto-summary. The routing table of router  Hearts will look like this:

Hearts#show ip route rip
172.16.0.0/24 is subnetted, 2 subnets
R 172.16.0.0 [120/1] via 192.168.12.1, 00:00:00, FastEthernet0/0
R 172.16.1.0 [120/1] via 192.168.12.1, 00:00:00, FastEthernet0/0

Above you see both networks. Now let’s create a summary:

Spade(config)#interface fastEthernet 1/0
Spade(config-if)#ip summary-address rip 172.16.0.0 255.255.0.0

Use the ip summary-address rip command to create the summary, we do  this on the outgoing interface towards router Hearts. Let’s check the routing  table of router Hearts again:

Hearts#show ip route rip 
R    172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:03, FastEthernet0/0

Above we now see the summary. 172.16.0.0 /16 is not very efficient because it  covers everything between 172.16.0.0 and 172.16.255.255. Whenever router Hearts  has an IP packet with a destination address that matches this summary it will  forwarded to router Spade. For example, an IP packet with destination  172.16.99.99 will be forwarded by router Hearts to router Spade. Router Spade  however will drop this IP packet because it doesn’t have anything in its routing  table that matches 172.16.99.99. The summary below would be better:

Spade(config)#interface fastEthernet 1/0
Spade(config-if)#no ip summary-address rip 172.16.0.0 255.255.0.0
Spade(config-if)#ip summary-address rip 172.16.0.0 255.255.254.0

Summary 172.16.0.0 /23 is more specific because it only covers 172.16.0.0 /24  and 172.16.1.0 /24. This is what it looks like on router Hearts:

Hearts#show ip route rip 
     172.16.0.0/23 is subnetted, 1 subnets
R       172.16.0.0 [120/1] via 192.168.12.1, 00:00:22, FastEthernet0/0

When you create summaries, try to be a specific as possible.

That’s all I have on RIP for you, if you understand all these commands you’ll  know everything you need to know for the Cisco CCNA exam. Before you move on I  highly recommend you to try these commands yourself. If you enjoyed this article  please leave a comment or share it with your friends.

 

How to Simulated 3 site MPLS with Remote Site-to-site Branch Office


No messing about today, we are going straight in with a more advanced lab! (and once which is more than likely familiar to you)

Now we all know how to create simple site to site VPN’s between two cisco devices (easy right? especially if you’ve read my previous blogs…), but what about say requiring access to multiple LANS, topped off with a sprinkle of IPSec tunnel terminating on a non-cisco device? Well that’s what I’m going to try and attempt here.

As you can see from the above network diagram, we are effectively  simulating an “MPLS CLOUD” at it’s simplest level as well as the “PUBLIC INTERNET”.

There are 3 MPLS sites, SITE A, SITE B and SITE C.

We then have a remote site, which will connect to MPLS Site C via the public internet using a VPN Tunnel.

The idea here is to allow the Remote site, access to all three MPLS LAN’s.

First I’m going to configure up the 3x 1841’s SITEA, SITEB and the MPLS Cloud.

If you are not familiar with the serial interfaces, then don’t worry too much. They are very similar to ethernet interfaces, you just need to specify a few addtional options (e.g clock speed of the interface). I’m not going to cover this now as it’s not relevant, so am going to carry on configuring the routers.

We now need to tell the “MPLSCLOUD” how to get to the various sites

And on with Site A configuration

Moving to Site B

Quick check to make sure Site B can ping the interface Site A connects to, as well as pinging Site A’s MPLS IP

Now lets move over to Site C (ignore the hostname Internet in the first line, that was me typing the wrong name…)

Now lets assign these VLAN’s to switchports (as you have to do on the ASA 5505)

Quickly check we can access the inside interface of Site A… Oh dear. Lets make sure we can get to the MPLS Cloud interface…

So we can hit the cloud router, but not site A.

Best have a look at the routes then make sure they are OK

So it knows how to get to those remote subnets, but what about the MPLS subnets. Right lets add them in then

We also need to add the following line:

This will now let traffic flow between interfaces with the same security level (so inside to MPLS and MPLS to inside)

Now this is done and all the route’s are in lets continue with the configuration, moving on to the “Internet Router”

Make sure you can ping the outside interface of site C

Everything is coming together nicely so far, so lets go ahead and configure up the branch office.

The branch office uses a draytek 2820, and first things first lets make sure we are running the latest firmware.

July 24th 2009. Hummmm there must be some later firmware…off to draytek.com and indeed there is, so now i’ll update

Thats better, May 23rd 2012.

On with configuring the interface which connects to the public internet

And now we need to configure the local lan of the remote site

Everything looks to be OK so far. We can see a connect to the public internet:

And I can also ping the “next hop” after the draytek

Back on to the internet router to make sure I can ping the draytek.

Oh dear, something isn’t right here. Don’t worry to much, much like cisco ASA’s blocking ICMP traffic by default so does our friend the draytek

Lets retry that

That’s much better.

Now time to configure the VPN tunnel on the Draytek, fairly straight forward (for those GUI lovers)

click advanced to enter the phase 1 / phase 2 settings

Now jump back over to site C and configure the VPN tunnel on there.

So thats the VPN tunnel done on this end, lets now try and send some traffic and hopefully the tunnel builds.

Oh dear, this is not good, lets have a look at the logs on the ASA (debug crypto isakmp 7 and debug crypto ipsec 7)

So what we can see here is Phase 1 has completed, but Phase 2 is a no go. It’s saying the ACL does not match Proxy ID’s.

Local proxy 0.0.0.0 / 255.255.255.0

Well it has a point, I’ve not any specified that on the ASA, so lets just check the draytek again

And there it is “remote Network IP”, we need to specify the remote LAN on here so it matches the ASA’s ACL

Now lets pass some traffic…

And looking at the logs, we can see Phase 2 completed (and as above traffic is passing)

Lets just check this on the draytek

We now have a tunnel built, and we can pass traffic from Site C to the remote site and site C to the remote site but what about accessing Site A and B?

Well naturally you would assume on the ASA all you need to do is make this simple change to the ACL:

  • access-list VPN extended permit ip 192.168.10.0 255.255.255.0 192.168.40.0 255.255.255.0 (original ACL)
  • access-list VPN extended permit ip 192.168.20.0 255.255.255.0 192.168.40.0 255.255.255.0 (additional line)
  • access-list VPN extended permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0 (additional line)

Then we move over to the draytek and click the “more” button

And here we specify the remote subnets

Drop the tunnel then wait for it to rebuild, and try to ping across to site A or B….The result? You won’t be able to.

Lets just take a look at the ASA (show crypto ipsec sa)

access-list VPN extended permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.40.0/255.255.255.0/0/0)

for some reason the ASA is only showing the first line of the ACL. Not good, this leaves sites A  and B cut off from the remote site.

So what can we do? well luckily for us the remote sites can all be summarised, so 192.168.10.0/24, 192.168.10.20/24 and 192.168.30.0/24 can be summarised as 192.168.0.0 /21 (255.255.224.0)

If we make this change on the ASA as well:

  • access-list VPN extended permit ip 192.168.10.0 255.255.255.0 192.168.40.0 255.255.255.0 (original ACL)
  • access-list VPN extended permit ip 192.168.0.0 255.255.224.0 192.168.40.0 255.255.255.0 (NEW ACL)

Re-build the VPN tunnel by dropping the tunnel and passing traffic, we can now see the following:

Notice next to IPsec it shows 192.168.0.0/255.255.224.0 as oppose to 192.168.30.0/24

This is good news surely? Lets try from the 192.168.30.0/24 (Site C) subnet and see what we can reach

We can hit our default gateway, the laptop on 192.168.10.10 (Site A) and also the laptop on 192.168.40.10 (Site C) (no Site B as I ran out of power to have the 5th router on!)

Lets move over to site A and the 192.168.10.0/24 network and make sure we can get to everything

Again, we can hit the default gateway and the laptops in SITE C and the Remote site.

There we have it then ladies and gentlemen, complete connectivity between 3 MPLS sites and a remote branch office…..

Or do we, well I wasn’t happy having to specify such a wide subnet (just to be able to access SITE A/B/C) (192.168.0.0/21), so I spent a fair amount of time looking into this and trouble shooting.

What I discovered was:

ASA to ASA (multiple remote/local LANS) = OK

Draytek to Draytek (multiple remote/local LANS) = OK

Draytek to ASA (with multiple remote/local LANS) = Fail

After a bit of further head scratching, pulling out of hair, and shouting at the kit I found out that ONLY one pair of IPsec Security Associations (SA’s) can be maintained at anyone time……

If you’ve not already fallen asleep let me explain..

Remote Site (192.168.40.0/24)
|
Internet (IPSEC TUNNEL) ——–PHASE 1 SA OK
|
SITE C (192.168.30.0/24) WITH SITE A & B subnets connected (192.168.10.0/24 & 192.168.20.0/24)

As you can see SITE C has 3 IP subnets behind it. With IPSEC tunnels there needs to be a PAIR (one outgoing, one incoming) of SA’s for each IP Subnet pair.

Eg:
PHASE2 SA’S for example would be as follows:

192.168.40.0/24 —OUTGOING—->192.168.10.0/24
192.168.40.0/24 <—INCOMING—-192.168.10.0/24

192.168.40.0/24 —OUTGOING—->192.168.20.0/24
192.168.4.0/24 <—INCOMING—-192.168.20.0/24

192.168.4.0/24 —OUTGOING—->192.168.30.0/24
192.168.4.0/24 <—INCOMING—-192.168.30.0/24

Communication can only exist between the different IP subnets if these SA “PAIRS” exist for the corresponding subnet pairs.

The Draytek has the limitation of only being able to maintain ONE SA PAIR at a time which has the unwanted affect of NOT being able to communicate to ALL subnets at the SAME time…

Luckily for the purpose’s of this lab I was able to summarise the three subnets in to a larger subnet to get around this issue. But if I had used 192.168.10.0/24 at one site and 172.16.40.0/24 at another site then I’d have been up the creek without a paddle.

As mentioned above this problem only occurs when doing IPSEC VPN between Draytek and CISCO in my test Draytek to Draytek has no problems.

So hopefully this saves you many hours of shouting, head scratching and hair loss! as i’ll be honest until I did this lab I was not aware of that either.

Finally below is the lovely setup I’ve had to live with looking at for the past few days….

%d bloggers like this: