Connecting the world…

local

GRE over IPsec with Cisco ASA

In different scenario’s it is required to configure some kind of routing protocol between two offices, but the routers should be configured to look directly connected to each other. Normally I always configure an IPsec VPN between the two offices and configure an additional GRE tunnel over the IPsec VPN tunnel. In that way the routers look directly connected and adding a routing protocol is no problem.

In the past I noticed several times that the GRE tunnel doesn’t come up, when using a Cisco PIX firewall or a Cisco ASA firewall. When using IOS 6.x on the PIX or 7.x on both hardware platforms, there is a workaround by using the following command:

clear local-host <remote peer>

Cisco has reported this bug in BugID CSCse36327:

The IPSEC tunnel was previously working and either one of the following events occured:
1. the crypto map and/or isakmp has been removed and reapplied to the interface
2. the PIX/ASA is upgraded from version 6.x to version 7.x
3. the PIX/ASA is rebooted
4. The remote IPSEC peer/s is rebooted

 

All events except 1 occur when a dynamic crypto map is used without a match address statement.
This typically affects only GRE traffic.

 

In PIX/ASA 7.x, GRE encryption may stop working (GRE packets are sent in clear) after removing and reapplying the encryption. This behaviour is by design in 7.x. If encryption is disabled but GRE packets are coming to the PIX in this time, GRE session is created on the PIX and marked as clear-text one (“do not encrypt”). When encryption is applied back, non-encrypted GRE session still exists on PIX and GRE packets that should be encrypted still bypass crypto map until old session is timed out or deleted. If there is a dynamic routing (OSPF/EIGRP/etc) running over GRE, this GRE session may never timeout and should be cleared manually.

 

In PIX/ASA 8.0.2, new functionality was introduced with new CLI command: “sysopt connection reclassify-vpn”. Default state is disabled. If this command is enabled, then enabling encryption causes non-encryption sessions to be dropped and reestablished with encryption.

Looks like there is a new command introduced in IOS 8.0.2 as mentioned above, by using sysopt connection reclassify-vpn.

There is also an entry on the Cisco SupportWiki about this problem. So the next time I will try this new command.

BGP Multihoming

Today I have been playing with configuring BGP and multihoming. I configured a simple test environment where one customer router (local AS 100) connects to two ISP routers from the same ISP (remote AS 200). I configure some kind of load-sharing amongst the two links to the ISP.

Important when configuring BGP is the concept to not becoming some kind of Transit AS for other BGP connections. It is also very important to secure your own router from accepting the whole routing table of the ISP. In this example I only accept a default route from the ISP.

I configured the following scenario:
BGP Multihoming
The next section show the significant configuration of the different network components in the scenario.

ICTIVITY

interface Loopback0
description INTERNAL NETWORK
ip address 172.16.100.1 255.255.254.0
!
interface FastEthernet0/0
description CONNECTION TO ISP-A
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description CONNECTION TO ISP-B
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto
!
router bgp 100
no synchronization
bgp log-neighbor-changes
bgp dampening
network 172.16.100.0 mask 255.255.254.0
timers bgp 1 5
neighbor 192.168.1.2 remote-as 200
neighbor 192.168.1.2 prefix-list DEFAULT-ONLY in
neighbor 192.168.2.2 remote-as 200
neighbor 192.168.2.2 prefix-list DEFAULT-ONLY in
maximum-paths 2
no auto-summary
!
ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0

ISP-A

interface FastEthernet0/0
description CONNECTION TO ICTIVITY
ip address 192.168.1.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description CONNECTION TO DEFAULT GATEWAY
ip address 10.11.0.2 255.255.0.0
duplex auto
speed auto
!
router bgp 200
no synchronization
bgp log-neighbor-changes
network 10.11.0.0 mask 255.255.0.0
neighbor 192.168.2.1 remote-as 100
neighbor 192.168.2.1 default-originate
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.11.0.1

ISP-B

interface FastEthernet0/0
description CONNECTION TO ICTIVITY
ip address 192.168.2.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
description CONNECTION TO DEFAULT GATEWAY
ip address 10.10.0.2 255.255.0.0
duplex auto
speed auto
!
router bgp 200
no synchronization
bgp log-neighbor-changes
network 10.10.0.0 mask 255.255.0.0
neighbor 192.168.2.1 remote-as 100
neighbor 192.168.2.1 default-originate
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 10.10.0.1

The above configuration is very basic, but yet very powerful. The command ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0 assures that only default routes are accepted from the ISP. The routing table of ICTIVITY has the following entries:

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

172.16.0.0/23 is subnetted, 1 subnets
C 172.16.100.0 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/1
B* 0.0.0.0/0 [20/0] via 192.168.1.2, 00:00:24
[20/0] via 192.168.2.2, 00:00:11

Looking at the routing table our router has two default routes for load-balancing and fail-over purposes.