public crl and private crl vrf issue

[Jacob Zartmann]

Hello,

I'm trying to set up a VPN solution with an existing PKI infrastructure.

We have a public CRL and som private CRL distribution points (both http and ldap)...

I run my private/inside interfaces in a vrf which causes issues when the router reloads og is set up initially. When establishing a VPN the router must check crl (and this of course has to be the public crl, as the VPN isn't up yet) so no vrf here. When the router then has the VPN up and wants to check the private crl or re-enroll the trustpoint is no longer able to contact the servers because it isn't vrf'ed.

How do I solve this scenario where I can allow the VPN to be both secure with crl checking and enjoy the benefit of checking the private crl and/or re-enroll with the CA server?

Thanks.

/JZN

[Marcin Latosiewicz]

JZN,

What do you have currently in place - two trustpoints, one available via VRF? What are you using for VPN?

I've seen a similar solution with dual VPN tunnels between both remote location and central.

The primary tunnel was setup with access to CA (and CSM in this particular case) only.
You would need to use isakmp profiles to match particular trustpoints to connection.

I'm not sure if a solution where you would grant access to your main CA over Internet is not a better one (you could protect the CA additionally with cut through proxy) if it was just for purpose of re-enrollment...

Marcin

[Jacob Zartmann]

Well... I managed to get this to work actually... Here's what I did: (comments are very welcome!)

crypto pki trustpoint my_ca

vrf my_vrf

source interface lo1

!
int lo1

ip vrf forwarding my_vrf

ip address 10.10.10.10 255.255.255.255
ip nat inside
!
int fa4
ip add dhcp
ip nat outside
!
ip access-list extended crl-nat
permit ip host 10.10.10.10 host 1.2.3.4

!

ip nat inside source list crl-nat interface FastEthernet4 vrf my_vrf overload
!

! Sadly domain lookups does not work with VPNs
ip host crl.my.dom 1.2.3.4
!

! Remember that Fa4 i in global (not VRF'ed) kinda analogous to route leaking...
ip route vrf my_vrf 1.2.3.4 255.255.255.255 FastEthernet4 dhcp

Now lo1 is able to be NAT'ed out Fa4 to reach the crl server at 1.2.3.4