cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
391
Views
0
Helpful
2
Replies
shutikov
Beginner

OSPF over IPSEC with VRF

Hello everyone. I have IPSEC between two sites, and unicast OSPF (with neighbors). IPSEC works on VRF interfaces. Problem is - all traffic between sites encrypted, but not OSPF :-(. How can I fix this? Or OSPF over IPSEC isn't supported by VRF?

3825-1#sh run

Building configuration...

Current configuration : 2279 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname 3825-1

!

boot-start-marker

boot-end-marker

!

!

aaa new-model

!

!

aaa authentication login default local

aaa authorization exec default local

!

aaa session-id common

!

resource policy

!

ip subnet-zero

ip cef

!

!

no ip dhcp use vrf connected

!

!

ip vrf data

rd 100:1

!

ip vrf voice

rd 100:2

!

no ip ips deny-action ips-interface

!

!

!

!

!

!

!

!

!

!

!

!

!

!

!

username admin privilege 15 password 0 admin

!

!

crypto keyring datakey vrf data

pre-shared-key address 192.168.11.1 key cisco

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

!

!

crypto ipsec transform-set TS esp-3des esp-sha-hmac

!

crypto map cm-6509 10 ipsec-isakmp

set peer 192.168.11.1

set transform-set TS

match address ACL-ALL

!

!

!

!

interface GigabitEthernet0/0

no ip address

duplex auto

speed auto

media-type rj45

negotiation auto

!

interface GigabitEthernet0/0.101

encapsulation dot1Q 101

ip vrf forwarding data

ip address 192.168.101.1 255.255.255.0

no snmp trap link-status

!

interface GigabitEthernet0/0.201

encapsulation dot1Q 201

ip vrf forwarding voice

ip address 192.168.201.1 255.255.255.0

no snmp trap link-status

!

interface GigabitEthernet0/1

no ip address

duplex auto

speed auto

media-type rj45

negotiation auto

!

interface GigabitEthernet0/1.11

encapsulation dot1Q 11

ip vrf forwarding data

ip address 192.168.11.3 255.255.255.0

ip ospf network non-broadcast

no snmp trap link-status

crypto map cm-6509

!

interface GigabitEthernet0/1.21

encapsulation dot1Q 21

ip vrf forwarding voice

ip address 192.168.21.3 255.255.255.0

no snmp trap link-status

!

router ospf 1 vrf data

router-id 192.168.11.3

log-adjacency-changes

network 192.168.0.0 0.0.255.255 area 0

neighbor 192.168.11.1

!

ip classless

!

!

ip http server

no ip http secure-server

!

ip access-list extended ACL-ALL

permit ip any any

permit ospf any any

ip access-list extended ACL-C

permit ip 192.168.101.0 0.0.0.255 host 192.168.92.1

permit ip 192.168.201.0 0.0.0.255 host 192.168.92.1

!

!

!

!

!

control-plane

!

!

!

!

!

!

!

!

!

!

line con 0

stopbits 1

line aux 0

stopbits 1

line vty 0 4

!

scheduler allocate 20000 1000

!

end

2 REPLIES 2
Harold Ritter
Cisco Employee

First, the "permit ospf any any" will never be matched since it is after "permit ip any any", which matches the ospf traffic as well.

Second, from what I remember, IPsec doesn't like "any any" to be used in the ACL.

Try being more specific as follow:

permit ospf host 192.168.11.3 host 1932.168.11.1

You should also be more specific with the "permit ip any any"

Let me know if I answered your question,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hello Harold.

IPSEC session is successfully established, packets like pings are encrypted, but OSPF packets don't.

I have had the same config before VRF, and everything worked fine. So I think problem isn't in access-lists. I've tried to change access-list, but it hasn't result.