GRE over IPsec tunnels (Part 2)

In my last post I wrote about GRE over IPsec, but only with static routes. One of the benefits of GRE over IPsec tunnels is that you can send multicast traffic  over the tunnel. With a plain IPsec tunnel this is not possible. So to prove that multicast traffic can cross the GRE over IPsec tunnel I took the topology of my last post and removed the static routes from the configuration of the HQ and Branch routers.
Below the used topology:
GRE_over_IPsec

Then configure the EIGRP configuration on both routers.

R1#sh run | se eigrp
router eigrp 10
network 10.10.10.0 0.0.0.255
network 172.18.2.0 0.0.0.255
no auto-summary
R1#

The syslog below confirms that the EIGRP adjacency is up and running:
EIGRP_adj

Then use the “debug ip packet detail” command to verify that multicast is used and allowed:
EIGRP_multicast

To prove the solution is working check the routing table.
sh_ip_route

And that’s all there to configure dynamic routing over a GRE over IPsec tunnel.

Advertisements

GRE over IPsec tunnels (Part 1)

Why a IPsec over a GRE tunnel? A couple of things come to mind. Things like encryption of tunneled traffic and the possibility to send multicast traffic over the tunnel.

GRE on itself only tunnels traffic by encsapsulating the traffic within an additional GRE and IP header. But if you Wireshark the traffic it’s just plain text and therefore readable. In a plain IPsec tunnel it is not possible to send multicast traffic over the IPsec tunnel. But if you’re using OSPF or EIGRP you need to be able to send multicast traffic over the IPsec tunnel.

To prove the above I created a case study. First I will show how to configure a normal GRE tunnel, after that a GRE over IPsec tunnel with static routes. In a separate post I will write about GRE over IPsec tunnel with dynamic routing.

So for this case study I used the topology as shown below.

GRE_over_IPsec

Below the configuration of the HQ router, the branch router is the same but use different IP addresses.

First configure the physical internet facing interface, the vlan interface for the internal subnet and the needed routes.

!
interface FastEthernet1/0
ip address 109.232.100.1 255.255.255.0
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.10.10.1 255.255.255.0
!
ip route 10.10.11.0 255.255.255.0 172.18.2.1
!

Then create the tunnel interface

!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination 109.232.100.2
!
Don’t forget to change the MTU size to 1400, because of the overhead created by the GRE encapsulation.

Now it’s possible to ping from PC1 at HQ to PC3 at the bracnch office. If you look at the traffic you will see it’s encapsulated in a GRE packet, but there is no encryption:
GRE_capture

To create an IPsec connection do the following on the HQ and Branch routers:
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key sjiekismiechdat address 109.232.100.2
!
!
crypto ipsec transform-set test esp-3des esp-md5-hmac
!
!
access-list 101 permit gre host 109.232.100.1 host 109.232.100.2
!
!
crypto map s-2-s 10 ipsec-isakmp
set peer 109.232.100.2
set transform-set test
match address 101
!
!
interface Tunnel0
crypto map s-2-s
!
!
interface FastEthernet1/0
crypto map s-2-s
!

Now send some traffic from PC1 to PC3 and use the “show crypto session” command to verify that the GRE over IPsec connection is established:
crypto_session

Now we know the tunnel is up and it’s possible to exchange traffic between PC1 at the HQ and PC3 at the branch office. Now let’s look at the traffic with Wireshark.
ESP

As you can see there are only ESP packets, in other words the encryption of the IPsec tunnel is working.

In my next post I will talk about dynamic routing with GRE over IPsec.

 

Private vlan’s

This blogpost is about private vlan’s. For  my CCIE study I looked into PVLAN’s. First some terminology. When working with PVLAN’s words like primary vlan, secondary vlan, promiscuous port, isolated port and community port have to sound familiar. If not check the following summary:

  • Primary VLAN: Original vlan, used to forward the actual traffic
  • Secondary VLAN: is configured with one of the following types Isolated or Community
  • Isolated port: A switch port configured as Isolated is only able to communicate with the promiscuous port. It is not able to reach any other destination!
  • Community port: A switchport configured as Community is able to communicate with a server in the same community vlan and the promiscuous port. A community port is not able to communicate with an isolated port.

Below a drawing which describes the above summary.

PVLAN

In the configuration below two laptops are configured in an isolated vlan. Therefor they won’t be able to communicate with each other, but they are able to communicate with the promiscuous port.

PVLAN_isolated

 

In the next configuration the two laptops are configured in a community vlan. because of that they are able to ping each other.

PVLAN_community

 

As you probably noticed, the only configuration change is that the private-vlan host-association changed.

Private vlan’s are very useful to large ISP, because with isolated ports it’s possible to use the same subnets. There is virtually no limit to the number of customers and only one firewall is needed for a lot of customers. The only limiting option is the throughput of the used firewall!

 

** to build this topology I used a Cisco 3560 switch and a Cisco ASA 5505 firewall

Port Access-Lists (PACL)

A while ago I blogged about VACL or Vlan Access-Lists. PACL and VACL are really connected to each other. In this blogpost I will show you how PACL works and how to configure it on a Cisco switch.

First of all, what is PACL. PACL makes it possible to filter incoming traffic on a layer 2 interface using layer 3 or 4 information.

First some restrictions on PACL

  • There can only be one ACL applied to a layer 2 interface per direction
  • PACL don’t filter later 2 traffic like CDP, VTP, DTP, UDLD and STP because this traffic is handled by the Route Processor before the applied ACL takes effect
  • The number of ACL’s that can be configured as part of the PACL configuration is bounded by the hardware resources of the switch
  • A MAC ACL is not applied to IP, MPLS or ARP messages
  • Only named MAC ACL can be used

I spoke earlier about the interaction between PACL and VACL. When they are both used on the switch and the traffic is bridged, PACL will always be applied before VACL’s. PACL will even override a “normal” ACL that is applied to the same interface (for this situation is only one exception, if packets are forewarded in software by the RP. If this is true an ” normal” ACL will take precedence over the PACL). Summarizing the above:

  • PACL for the ingress port
  • VACL for the egress vlan
  • VACL vfor the egress vlan

Below a schematic of this.

*PACL_bridged

It’s fairly easy to configure this, below an example of my lab and how to configure this:

topology

PACL_portconfig

PACL_acl

 

It’s a little different when the traffic is routed. The next is true for routed packets:

  • PACL for the ingress port
  • VACL for the ingress vlan
  • Input Cisco IOS ACL
  • Output Cisco IOS ACL
  • VACL for the egress vlan

Below a schematic of the above:

*PACL_routed

 

PACL can come in handy when you want to deny access of a PC/Server to another PC/Server in the same vlan and you can’t change the vlan of the machines.

 

More information on this topic can be found on the Cisco site (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/port_acls.pdf).
*=I found the used schematics on the Cisco site and borrowed them!

Protect your network against HSRP attacks!

As in my earlier post, I’m writing a series of postings to help protect your network against attacks. A good hacker will always find a way to hurt your network. But with the recommendations described in this series of postings it will be more difficult for the hacker to find a way in.

In this post I will describe the hacking of HSRP operations and off course I will describe a solution to this problem.

As always I use GNS3. Below the topology and the configuration of multilayer switch R2.
topology

R2
!
interface FastEthernet0/0
switchport mode trunk
!
interface FastEthernet0/5
switchport access vlan 13
no cdp enable
!
interface Vlan10
ip address 10.0.0.253 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.253 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.253 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.253 255.255.255.0
standby 13 ip 192.168.80.254
!

HSRP
The cisco.com website explains HSRP as follows:

“HSRP is Cisco’s standard method of providing high network availability by providing first-hop redundancy for IP hosts on an IEEE 802 LAN configured with a default gateway IP address. HSRP routes IP traffic without relying on the availability of any single router. It enables a set of router interfaces to work together to present the appearance of a single virtual router or default gateway to the hosts on a LAN. When HSRP is configured on a network or segment, it provides a virtual Media Access Control (MAC) address and an IP address that is shared among a group of configured routers. HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router. The virtual router does not exist; it represents the common target for routers that are configured to provide backup to each other. One of the routers is selected to be the active router and another to be the standby router, which assumes control of the group MAC address and IP address should the designated active router fail.”

So in short, HSRP provides a virtual default gateway. And that’s the problem, when someone or something finds a way to hack into the HSRP operations it is possible to change the default gateway and reroute networktraffic or blackhole the networktraffic. This turns out to be very simple with Kali. Below a simple explanation how to change the behaviour of HSRP operations.

Start Kali, start yersinia, click the HSRP tab, choose to become active router, give in an ip address and that’s al there is:
hsrp_att

hsrp ip

 

When you have enable terminal monitor on your switch, you’ll see a state change
state change
Now check the HSRP settings with “show standby vlan 13” and you’ll see that the gateway has changed to 10.10.10.10
sh stand vlan 13

When you look closer to the config you’ll notice something else:
config change
For Yersinia to be able to take over the HSRP operations, it alters the config by entering a static entry to the mac address table!

Again this al there is to! To prevent this, make sure u use authetication on your HSRP interfaces as described in the following example:

First create a key-chain
key chain

 

Then configure the authentication on the vlan interface. If your are in a production network. First configure the standby unit, then the active unit. Otherwise the actions are disruptive!

 

stand auth

Now try the HSRP attack again and you’ll see it will not work this time!
stand vlan 13 auth

 

And to make it even more clear, when terminal monitor is enabled you’ll get the message depicted in the picture below
bad auth

 

 

 

Protect your network against CDP attacks!

As a network consultant/engineer you should be aware of network security risks. Today it is fairly simple to take down a network with the use of Kali Linux. There, it has been said: Kali Linux. This Linux distro is a hackers dream. It has all the necessary tools on board to damage a network very very hard! A hacker only needs a free outlet that is patched to a switch. Within minutes a company can be down on it’s knees!

First of all I’m writing this series of postings to point out the need for security on the network layer, not to make a hackers life easy! In this post I will describe how to use Kali Linux, but more important are the security solutions I give to prevent attacks on your network. This post will be about protecting your network against CDP attacks.

How do I test Kali, you probably guest it already when you read my earlier posts, I use GNS3 for it. Below the topology I use for testing.
topology

R1 and R2 are configured as two multilayer switches, with several (routed) vlan’s. For reference below the config of R1.

R1
!
interface FastEthernet0/0
description Trunk to R2
switchport mode trunk
!
!
interface FastEthernet0/4
switchport access vlan 11

!
!
interface Vlan10
ip address 10.0.0.252 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.252 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.252 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.252 255.255.255.0
standby 13 ip 192.168.80.254
!

CDP Flooding
CDP (Cisco Discovery Protocol) is a great tool when you have to make documentation of a network and most cases CDP is globally enabled on every switch en every switchport on the network. Great, but then a any given moment you check the cdp status on your switch and see this:

cdp_flood

and this:
proc_cpu

As you can see the cdp table is flooded with bogus entry’s and because of the ongoing stream of bogus cdp packets, the cpu spikes to 100%. It’s just a matter of time before the switch will reboot. Problem is, when the switch is rebooted it will be just the same because the stream of cdp packets just keeps going on.

How is this possible you think, well it’s really easy. Install Kali Linux, start the Yersinia program and click attack. Is it that easy I hear you think? Yes it’s that easy! Check it out:

Start Kali Linux:
kali

Start Yersinia
start yersinia

Click the cdp tab, click Launch Attack, choose “flooding CDP table” and click “OK”.
start attack

 

That’s it, your cdp table will be flood with bogus cdp packets. Now check your switch with the “show cdp table”, “show cdp traffic” and “show proc cpu sorted” command:
cdp_flood

proc_cpu

cdp traffic

Within two minutes my switch crashed and rebooted, so this is a real threat to the stability of your network.
To prevent this kind of attacks a couple of things can be done:

First of all, place switchports that are not in use in a dummy vlan and give them an admin down
Second, disable cdp on switchports that don’t need it. For example access ports that only contain a computer or a IP phone which don’t need the CDP protocol to function!
Third, ports that can’t be disabled, configure Port Security on them!

 

 

Multicast Routing with PIM-SM

To get a better understanding of Multicast PIM-SM routing I created a case study. In the picture below the GNS3 topology I used.

topology

I used EIGRP between the routers for full unicast connectivity. On all te routers I configured “IP multicast-routing” and on the connected interfaces I configured the “ip pim sparse-mode”. R3 serves as a Rendevouz Point (RP) and R4 serves as the Mapping Agent (MA).

First configure the full unicast connectivity. I will show one sample, the other routers are pretty straight forward.

R1
!
interface FastEthernet1/0
ip address 10.0.0.5 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/0
ip address 172.18.100.254 255.255.255.0
duplex auto
speed auto
!
router eigrp 10
network 1.1.1.1 0.0.0.0
network 10.0.0.0 0.0.0.3
network 10.0.0.4 0.0.0.3
network 172.18.100.0 0.0.0.255
no auto-summary
eigrp router-id 1.1.1.1
!

Make sure there is full unicast connectivity from 172.18.100.254 to 192.168.157.254. Check your routing table on router R1 and use the ping command. The routing table will look like the picture blow.
R1_RT

Now that we have full unicast connectivity we can start with the multicast basics. First configure multicast routing on all the routers. This can be done with the following command: “ip mulicast-routing”. After that configure the “ip pim sparse-mode” command on all the interfaces which are participating in the multicast routing. In my topology this means all physical interfaces and the Loopback interfaces on router R3 and R4.
After this we have basic multicast connectivity.

Now it’s time to configure the Rendevous Point, but first a little explanation about PIM-SM, Rendevouz Point’s and Mapping Agents.

PIM-SM*
PIM-SM is a protocol for efficiently routing IP packets to multicast groups that may span wide-area and inter-domain internets. The protocol is named protocol-independent because it is not dependent on any particular unicast routing protocol for topology discovery, and sparse-mode because it is suitable for groups where a very low percentage of the nodes will subscribe to the multicast session. Unlike earlier dense-mode multicast routing protocols such as DVMRP and dense-multicast routing which flooded packets across the network and then pruned off branches where there were no receivers, PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast group
explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage.

Rendevouz Point*
A Rendezvous Point (RP) is used as a temporary way to connect a would-be multicast receiver to an existing shared multicast tree passing through the rendezvous point. When volume of traffic crosses a threshold, the receiver is joined to a source-specific tree, and the feed through the RP is dropped. You can think of this as obtaining copies of something through a friend who already subscribes, and when it proves useful or interesting, it’s worth the bother to become a direct subscriber.

I used auto-RP to configure a RP, so a little more about auto-RP

auto-RP
Auto-RP automatically distributes information to routers as to what the RP address is for various multicast groups. It simplifies use of multiple RP’s for different multicast group ranges. It avoids manual configuration inconsistencies, and allows for multiple RP’s acting as backups to each other. Cisco routers automatically listen for this information.

Auto-RP relies on a router designated as RP mapping agent. Potential RP’s announce themselves to the mapping agent, and it resolves any conflicts. The mapping agent then sends out the multicast group-RP mapping information to the other routers.

Mapping-Agent
The RP mapping agent listens to the announced packets from the RPs, then sends RP-to-group mappings in a discovery message that is sent to 224.0.1.40. These discovery messages are used by the remaining routers for their RP-to-group map. You can use one RP that also serves as the mapping agent, or you can configure multiple RPs and multiple mapping agents for redundancy purposes.

If you want to know more about the theory behind multicast routing check out the “Routing TCP/IP Volume II book written by Jeff Doyle and Jennifer DeHAven Carroll. Or check out this link: http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/9356-48.html

Let’s start configuring. To configure the RP on R3 use the commands as in the below configuration:

R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
!
ip pim send-rp-announce Loopback0 scope 15
!

And configure the Mapping-Agent on router R4. RP and MA can be configured on the same router, but for the sake of the example I configure them on different routers.

R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip pim sparse-mode
!
ip pim send-rp-discovery Loopback0 scope 15
!

Basically this is all there is to make PIM-SM, RP and MA to function. To check if everthing works as expected, use the following commands:

Show ip pim rp mapping
pim rp map
As can be seen in the above picture the 224.0.0.0/4 groups are connected to the RP on router R3 and the RP is chosen via Aur0-RP

To check if there is multicast connectivity check the multicast routing table:

Show ip mroute
sh ip mrou

Now were up to the next part, how to stream a videofile over the multicast network to a multicast receiver.

In my example I used 3 virtual machines with windows 7 installed, I use VMware workstation for it. To stream the videofile I installed VLC on C1. See below the configuration I used to stream the file
C1
VLC sets the TTL default to 1. I the topology used, this won’t work because there are at least 4 hops between sender and receiver. I set the TTL to 12. Check this with a wireshark trace like in the picture below
ttl
Because I set the multicast (group)address to 239.255.255.250 on C1, check on router R1 if the correct multicast group is “created” with the “show ip igmp groups” command.
sh ip igmp grou

 

Now configure the client, as shown in the picture below

C2

And there we go! We are looking to an udp multicast videostream. To make C3 work, follow the same steps.

This is a faitly simple example of the of PIM-SM and multicast, but nevertheless it gives a perfect view of the multicast capabilities!

If you run into any trouble, there are some handy multicast troubleshooting tools like mtrace and mstat.

Mtrace is the multicast equivalent of traceroute
mtrace

The mstat command gives you an overview of the multicast path in ascii style. It shows drops, duplicates, TTL’s and delays between the nodes in the paths.
mstat

 

 

*Source of this information is http://www.cisco.com