Solved: IPSEC tunnel and Routing protocols Support

mahesh18 · ‎12-23-2012

Hi Everyone,

I read IPSEC does not support Routing Protocols with Site to Site VPN as they both are Layer4.

Does it mean that If Site A has to reach Site B over WAN link we should use Static IP on Site A and Site B Router?

In my home Lab i config Site to Site IPSES VPN and they are working fine using OSPF does this mean that IPSEC supports Routing Protocol?

IF someone can explain me this please?

OSPF config A side

router ospf 1

router-id 3.4.4.4

log-adjacency-changes

area 10 virtual-link 10.4.4.1

passive-interface Vlan10

passive-interface Vlan20

network 3.4.4.4 0.0.0.0 area 0

network 192.168.4.0 0.0.0.255 area 10

network 192.168.5.0 0.0.0.255 area 0

network 192.168.10.0 0.0.0.255 area 0

network 192.168.20.0 0.0.0.255 area 0

network 192.168.30.0 0.0.0.255 area 0

network 192.168.98.0 0.0.0.255 area 0

network 192.168.99.0 0.0.0.255 area 0

3550SMIA#sh 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 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.5.3 to network 0.0.0.0

O 192.168.12.0/24 [110/13] via 192.168.5.3, 3d17h, FastEthernet0/11

100.0.0.0/32 is subnetted, 1 subnets

O 100.100.100.100 [110/3] via 192.168.5.3, 3d17h, FastEthernet0/11

3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

O 3.3.3.3/32 [110/2] via 192.168.5.3, 3d17h, FastEthernet0/11

C 3.4.4.0/24 is directly connected, Loopback0

C 192.168.30.0/24 is directly connected, Vlan30

64.0.0.0/32 is subnetted, 1 subnets

O E2 64.59.135.150 [110/300] via 192.168.5.3, 1d09h, FastEthernet0/11

4.0.0.0/32 is subnetted, 1 subnets

O 4.4.4.4 [110/2] via 192.168.5.3, 3d17h, FastEthernet0/11

C 192.168.10.0/24 is directly connected, Vlan10

172.31.0.0/24 is subnetted, 4 subnets

O E2 172.31.3.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11

O E2 172.31.2.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11

O E2 172.31.1.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11

O E2 172.31.0.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11

O 192.168.11.0/24 [110/3] via 192.168.5.3, 3d17h, FastEthernet0/11

O 192.168.98.0/24 [110/2] via 192.168.99.1, 3d17h, FastEthernet0/8

C 192.168.99.0/24 is directly connected, FastEthernet0/8

C 192.168.20.0/24 is directly connected, Vlan20

192.168.5.0/31 is subnetted, 1 subnets

C 192.168.5.2 is directly connected, FastEthernet0/11

C 10.0.0.0/8 is directly connected, Tunnel0

192.168.6.0/31 is subnetted, 1 subnets

O 192.168.6.2 [110/2] via 192.168.5.3, 3d17h, FastEthernet0/11

O 192.168.1.0/24 [110/13] via 192.168.5.3, 3d17h, FastEthernet0/11

O*E2 0.0.0.0/0 [110/1] via 192.168.5.3, 1d09h, FastEthernet0/11

B Side Config

Side A

router ospf 1

log-adjacency-changes

network 192.168.97.0 0.0.0.255 area 0

network 192.168.98.0 0.0.0.255 area 0

network 192.168.99.0 0.0.0.255 area 0

1811w# sh 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 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.99.2 to network 0.0.0.0

O 192.168.12.0/24 [110/14] via 192.168.99.2, 3d17h, FastEthernet0

100.0.0.0/32 is subnetted, 1 subnets

O 100.100.100.100 [110/4] via 192.168.99.2, 3d17h, FastEthernet0

3.0.0.0/32 is subnetted, 2 subnets

O 3.3.3.3 [110/3] via 192.168.99.2, 3d17h, FastEthernet0

O 3.4.4.4 [110/2] via 192.168.99.2, 3d17h, FastEthernet0

O 192.168.30.0/24 [110/2] via 192.168.99.2, 3d17h, FastEthernet0

64.0.0.0/32 is subnetted, 1 subnets

O E2 64.59.135.150 [110/300] via 192.168.99.2, 1d09h, FastEthernet0

4.0.0.0/32 is subnetted, 1 subnets

O 4.4.4.4 [110/3] via 192.168.99.2, 3d17h, FastEthernet0

O 192.168.10.0/24 [110/2] via 192.168.99.2, 3d17h, FastEthernet0

172.31.0.0/24 is subnetted, 4 subnets

O E2 172.31.3.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0

O E2 172.31.2.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0

O E2 172.31.1.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0

O E2 172.31.0.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0

O 192.168.11.0/24 [110/4] via 192.168.99.2, 3d17h, FastEthernet0

C 192.168.98.0/24 is directly connected, BVI98

C 192.168.99.0/24 is directly connected, FastEthernet0

O 192.168.20.0/24 [110/2] via 192.168.99.2, 3d17h, FastEthernet0

192.168.5.0/31 is subnetted, 1 subnets

O 192.168.5.2 [110/2] via 192.168.99.2, 3d17h, FastEthernet0

192.168.6.0/31 is subnetted, 1 subnets

O 192.168.6.2 [110/3] via 192.168.99.2, 3d17h, FastEthernet0

O 192.168.1.0/24 [110/14] via 192.168.99.2, 3d17h, FastEthernet0

O*E2 0.0.0.0/0 [110/1] via 192.168.99.2, 1d09h, FastEthernet0

Thanks

Mahesh

olpeleri · ‎12-23-2012

Mahesh.

Purely crypto-map based solution are indeed not compatible with a routing protocol. However crypto map are the legacy config we are supporting on IOS. The best practice is to use tunnel protection. Any routing protocol would then work.

eg

https://learningnetwork.cisco.com/docs/DOC-2457

That's the best solution we currenty have

View solution in original post

olpeleri · ‎12-23-2012

Hello,

I'm saying crypto maps have a lot of limitations. Tunnel Protection make way more sense

U can configure in 2 ways [ and multicast WILL work over it]

1- GRE over IPSEC

crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac

mode transport

crypto ipsec profile tp

set transform-set aes

int tu1

ip address 255.255.255.252

tunnel source

tunnel destination

tunne protection ipsec profile tp

We have configured mode transport because we encrypt GRE + what ever we encapsule in GRE [ eg OSPF - telnet - http ]

Pros:

We can as well transport IPV6 or CDP

Cons:

4 bytes of overhead due to GRE

2- IP over IPSEC

crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac

mode tunnel

crypto ipsec profile tp

set transform-set aes

int tu1

ip address 255.255.255.252

tunnel source

tunnel destination

tunnel mode ipsec ipv4

tunne protection ipsec profile tp

This config is in fact closer from a crypto map [ from encapsulation standpoint]. The transform-set then NEED to be in tunnel-mode

Pro:

4 bytes overhead less than GRE over IPSEC

Cons:

Cannot transport CDP or MPLS or IPV6. Very limiting IMHO

Cheers

Olivier

View solution in original post

olpeleri · ‎12-23-2012

Mahesh.

Purely crypto-map based solution are indeed not compatible with a routing protocol. However crypto map are the legacy config we are supporting on IOS. The best practice is to use tunnel protection. Any routing protocol would then work.

eg

https://learningnetwork.cisco.com/docs/DOC-2457

That's the best solution we currenty have

mahesh18 · ‎12-23-2012

Hi olpeleri,

So when you say crypto-map does you mean this porvides envryption before?

When you say we should use tunnel protection you mean IPSEC to use as GRE does not support encryption right?

Thanks

MAhesh

olpeleri · ‎12-23-2012

Hello,

I'm saying crypto maps have a lot of limitations. Tunnel Protection make way more sense

U can configure in 2 ways [ and multicast WILL work over it]

1- GRE over IPSEC

crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac

mode transport

crypto ipsec profile tp

set transform-set aes

int tu1

ip address 255.255.255.252

tunnel source

tunnel destination

tunne protection ipsec profile tp

We have configured mode transport because we encrypt GRE + what ever we encapsule in GRE [ eg OSPF - telnet - http ]

Pros:

We can as well transport IPV6 or CDP

Cons:

4 bytes of overhead due to GRE

2- IP over IPSEC

crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac

mode tunnel

crypto ipsec profile tp

set transform-set aes

int tu1

ip address 255.255.255.252

tunnel source

tunnel destination

tunnel mode ipsec ipv4

tunne protection ipsec profile tp

This config is in fact closer from a crypto map [ from encapsulation standpoint]. The transform-set then NEED to be in tunnel-mode

Pro:

4 bytes overhead less than GRE over IPSEC

Cons:

Cannot transport CDP or MPLS or IPV6. Very limiting IMHO

Cheers

Olivier

mahesh18 · ‎12-23-2012

Hi Olivier,

Many thanks again

Regards

MAhesh