Tag Archives: Security

Dynamic GRE Tunnels Part 2

Hello to all of our followers,

It’s time to continue with the mGRE topic.

The last time we saw how the spokes were able to send traffic dynamically from spoke to spoke through the hub but now we will see how to make the Spokes talk to each other without having to go through the hub.

Here is the link to the previous post:

http://i-networks.us/dynamic-gre-tunnels-part-1

Let’s get started by sharing the topology we will be using today in our lab:

Screen Shot 2015-07-24 at 2.27.07 PM

 

It’s the same topology we use last time, the hub configuration it’s almost the same with only one change in mind.

I will share the config of the Hub first:

Hub (R1) Config

interface Tunnel1

ip address 10.10.10.1 255.255.255.0

no ip redirects

no ip next-hop-self eigrp 100

ip nhrp map multicast dynamic

ip nhrp network-id 1

no ip split-horizon eigrp 100

tunnel source FastEthernet0/0

tunnel mode gre multipoint

The only thing that should be new to you here is the no ip-next-hop-self command!

Remember that the whole purpose of this lab is to make the spokes to be able to talk to each other without going through the hub.

With EIGRP we have a problem for this scenarios as when you send an update outside one of your interfaces, that update will have the IP address on your interfaces as the NEXT-HOP IP and that would force the packets to be send trough you! We do not want that in our LAB so we need to add that command. We want the Spokes to learn the Updated from the other Spokes by having their own IP’s.

Let’s now move to the Spoke’s config:

R3 Config:

interface Tunnel1

ip address 10.10.10.3 255.255.255.0

no ip redirects

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp map multicast 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

R4 Config:

interface Tunnel1

ip address 10.10.10.4 255.255.255.0

no ip redirects

ip nhrp map 10.10.10.1 1.1.1.1

ip nhrp map multicast 1.1.1.1

ip nhrp network-id 1

ip nhrp nhs 10.10.10.1

tunnel source FastEthernet0/0

tunnel mode gre multipoint

Do you see the differences here?

Pretty simple, we just change the tunnel mode from a regular GRE mode to a mGRE and we removed the tunnel destination as we don’t need it to be statically defined as the hub anymore.

Now I will show the Routing Protocol Config on each router and then you will see how each Spoke learns the IP Networks

R1 (Hub)

router eigrp 100

network 10.0.0.0

network 192.168.10.0

no auto-summary

R3 (Spoke1)

router eigrp 100

network 10.0.0.0

network 192.168.20.0

no auto-summary

R4(Spoke2)

router eigrp 100

network 10.0.0.0

network 192.168.30.0

no auto-summary

Verfication Stage

Let’s go directly to the Spoke Routers and check the routing table

R3#sh ip route eigrp 100

D    192.168.30.0/24 [90/310172416] via 10.10.10.4, 00:07:22, Tunnel1

D    192.168.10.0/24 [90/297372416] via 10.10.10.1, 00:07:22, Tunnel1

R4#sh ip route eigrp 100

D    192.168.10.0/24 [90/297372416] via 10.10.10.1, 00:10:13, Tunnel1

D    192.168.20.0/24 [90/310172416] via 10.10.10.3, 00:07:28, Tunnel1

Awesome!! As you can see they can see each other routes with their own IP address.

Let’s send a ping packet and see the result

R3#ping 192.168.30.1 source 192.168.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.20.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 72/93/120 ms

If we go further on this lab we can check the NHRP Mapping Cache on each router:

R3#sh ip nhrp tunnel 1 brief            

   Target                     Via                   NBMA           Mode   Intfc   Claimed

10.10.10.1/32      10.10.10.1      1.1.1.1         static   Tu1     <   >

10.10.10.4/32      10.10.10.4      1.1.1.9         dynamic  Tu1     <   >

I bet you are asking how did R3 and R4 learn each other NBMA IP. In order to show you that I ran a debug NHRP cache in the Hub Router to obtain the NHRP Resolution request and Reply when R3 first tried to ping R4. All of this cause at the beginning R3 only knew the tunnel destination IP was 10.10.10.4 but who owns that tunnel IP?????

Here is the debug output:

R1#

“Here R3 send the ping and it’s trying to learn the NBMA IP address of 10.10.10.4″

*Mar  1 00:18:10.039: NHRP: Receive Resolution Request via Tunnel1 vrf 0, packet size: 68

*Mar  1 00:18:10.039:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.043:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.043:  (M) flags: “router auth src-stable”, reqid: 7

*Mar  1 00:18:10.043:      src NBMA: 1.1.1.5

*Mar  1 00:18:10.043:      src protocol: 10.10.10.3, dst protocol: 10.10.10.4

*Mar  1 00:18:10.043:  (C-1) code: no error(0)

*Mar  1 00:18:10.047:        prefix: 0, mtu: 1514, hd_time: 7200

*Mar  1 00:18:10.047:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar  1 00:18:10.047: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 96

*Mar  1 00:18:10.051:  src: 10.10.10.1, dst: 10.10.10.3

*Mar  1 00:18:10.051:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.051:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.051:  (M) flags: “router auth dst-stable unique src-stable”, reqid: 7

*Mar  1 00:18:10.051:      src NBMA: 1.1.1.5

*Mar  1 00:18:10.055:      src protocol: 10.10.10.3, dst protocol: 10.10.10.4

*Mar  1 00:18:10.055:  (C-1) code: no error(0)

*Mar  1 00:18:10.055:        prefix: 32, mtu: 1514, hd_time: 6981

*Mar  1 00:18:10.055:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar  1 00:18:10.055:        client NBMA: 1.1.1.9

*Mar  1 00:18:10.059:        client protocol: 10.10.10.4

“Here we can see R4 doing the same thing but for R3s NBMA IP”

*Mar  1 00:18:10.175: NHRP: Receive Resolution Request via Tunnel1 vrf 0, packet size: 68

*Mar  1 00:18:10.175:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.175:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.175:  (M) flags: “router auth src-stable”, reqid: 5

*Mar  1 00:18:10.175:      src NBMA: 1.1.1.9

*Mar  1 00:18:10.179:      src protocol: 10.10.10.4, dst protocol: 10.10.10.3

*Mar  1 00:18:10.179:  (C-1) code: no error(0)

*Mar  1 00:18:10.179:        prefix: 0, mtu: 1514, hd_time: 7200

*Mar  1 00:18:10.179:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

*Mar  1 00:18:10.183: NHRP: Send Resolution Reply via Tunnel1 vrf 0, packet size: 96

*Mar  1 00:18:10.183:  src: 10.10.10.1, dst: 10.10.10.4

*Mar  1 00:18:10.183:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

*Mar  1 00:18:10.187:      shtl: 4(NSAP), sstl: 0(NSAP)

*Mar  1 00:18:10.187:  (M) flags: “router auth dst-stable unique src-stable”, reqid: 5

*Mar  1 00:18:10.187:      src NBMA: 1.1.1.9

*Mar  1 00:18:10.187:      src protocol: 10.10.10.4, dst protocol: 10.10.10.3

*Mar  1 00:18:10.187:  (C-1) code: no error(0)

*Mar  1 00:18:10.191:        prefix: 32, mtu: 1514, hd_time: 7147

*Mar  1 00:18:10.191:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0

*Mar  1 00:18:10.191:        client NBMA: 1.1.1.5

*Mar  1 00:18:10.191:        client protocol: 10.10.10.3

And that’s how mGRE Tunnels work! I hope you enjoyed this post.

Regards,

Jcarvaja

Kali SSH Access

Hello Followers,

By default when you install Kali the SSH Daemon it’s not gonna allow any connection via this protocol as it’s not enabled!

In this post I will show you how to make sure the SSH Daemon it’s already installed in your PC and how to enable it for remote access in the best possible way.

As our Kali version 1.1.0 runs over Debian we can use the dpkg command as this is a package manager for this Linux Distribution to find out whether OpenSSH it’s installed in our server or not.

root@kali-Jcarvaja:~# dpkg -s openssh-server
Package: openssh-server
Status: install ok installed

As we can see the package it’s installed but what if the package it’s not installed?

Then get the right package:

root@kali-Jcarvaja~:# apt-get install openssh-server

After you have that done you would like to make sure that SSH it’s enable persistenly (meaning even if the Server it’s rebooted).

In order to make that happen run the following commands:

root@kali-Jcarvaja:~# update-rc.d -f ssh remove

root@kali-Jcarvaja:~# update-rc.d -f ssh defaults

These last 2 commands are going to disable the current run levels being used by the SSH Process and start using the default run levels.

After you have this done you can change the RSA keys being used by this protocol but first you will make sure you save a copy of the default RSA keys.

root@kali-Jcarvaja:~# cd /etc/ssh

root@kali-Jcarvaja:/etc/ssh# mkdir default_kali_keys

root@kali-Jcarvaja:/etc/ssh# mv ssh_host_* default_kali_keys/

In the first command shown we just move to the ssh container and then we create a folder name default_kali_keys.

This is exactly where we want to backup our host SSH default keys and we use the command mv to move that RSA key to the previously created container.

We can then move to the creation of the new key  set

root@kali-Jcarvaja:/etc/ssh# dpkg-reconfigure openssh-server

And finally you restart the SSH daemon
root@kali-Jcarvaja:/etc/ssh# service ssh restart

 

Regards,

 

Jcarvaja