A VRF is a Virtual Routing and Forwarding instance, it's basically a virtualization technique for IOS routers. Each VRF has its own interfaces (you cannot put a L3 interface in 2 different VRFs), it has its own routing table and everything.
You create a VRF by typing:
ip vrf my-out-vrf
You assign interfaces to a VRF using:
int fa0/0 ip vrf forwarding my-out-vrf
You create a static route and you look at the routing table for a VRF using:
ip route vrf my-out-vrf 10.1.1.0 255.255.255.0 192.168.5.5 sho ip route vrf my-out-vrf
lots of commands and features are "vrf-aware", just use the question mark to find out...
ping vrf my-vrf-out 10.1.1.2 sho ip cef vrf my-vrf-out 10.1.1.2 ip nat inside source list 199 interface fa0/0 vrf my-vrf-out overload
VPNs are MAGIC because they can have their encrypted traffic in 1 VRF and the decrypted traffic in another VRF.
The typical use case for this is an ISP that provides VPN service to multiple enterprise customers on the same box, the users and branches connect using internet for the encrypted traffic, but the decrypted traffic needs to go to the private network of each separate customer and this traffic cannot be mixed.
ivrf : Inside VRF, the VRF that contains the clear-text traffic (before encryption for outbound flows and after decryption for inbound flows)
fvrf : Front-door VRF (or outside VRF), the VRF that contain the encrypted traffic
global VRF: the routing instance that is used if no specific VRF is defined. If no VRF-aware config is used, everything is done in the global VRF and all interfaces are in the global VRF.
Crypto map-based with ivrf=cust1-vrf and fvrf=internet-vrf
ip cef ip vrf cust1-vrf ! ip vrf internet-vrf ! ! crypto keyring internet-keyring vrf internet-vrf pre-shared-key address 10.1.1.2 key cisco123 ! crypto isakmp policy 10 encr 3des authentication pre-share group 2
crypto isakmp profile cust1-ike-prof vrf cust1-vrf keyring internet-keyring match identity address 10.1.1.2 255.255.255.255 internet-vrf isakmp authorization list default ! crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac ! crypto map mymap 10 ipsec-isakmp set peer 10.1.1.2 set transform-set esp-3des-sha set isakmp-profile cust1-ike-prof match address 199 reverse-route
interface GigabitEthernet0/0 description internet WAN link ip vrf forwarding internet-vrf ip address 10.1.1.3 255.255.255.224 crypto map mymap ! interface GigabitEthernet0/1 description cust1 private VRF ip vrf forwarding cust1-vrf ip address 192.168.88.20 255.255.255.0 ! interface loopback10 ip vrf forwarding cust1-vrf ip address 184.108.40.206 255.255.255.255
ip route vrf internet-vrf 0.0.0.0 0.0.0.0 10.1.1.1 access-list 199 permit ip host 220.127.116.11 host 18.104.22.168
"vrf <ivrf>" on isakmp profile
fvrf on match statement of isakmp profile
keyring tagged with fvrf
RRI for route leaking (otherwise we don't hit the crypto map) or a static route like "ip route vrf cust1-vrf 22.214.171.124 255.255.255.255 GigabitEthernet0/0 10.1.1.1" (note that the route is on the ivrf routing table but points to an interface of the fvrf)
interfaces in their respective VRF
proper routes in each VRF
Tunnel-protection with ivrf=cust1-vrf and fvrf=internet-vrf
ip cef ip vrf cust1-vrf ! ip vrf internet-vrf ! crypto keyring internet-keyring vrf internet-vrf pre-shared-key address 10.1.1.2 key cisco123 ! crypto isakmp policy 10 encr 3des authentication pre-share group 2 ! crypto isakmp profile cust1-ike-prof keyring internet-keyring match identity address 10.1.1.2 255.255.255.255 internet-vrf isakmp authorization list default local-address GigabitEthernet0/0 ! crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac ! crypto ipsec profile cust1-ipsec-prof set transform-set esp-3des-sha set isakmp-profile cust1-ike-prof ! ! interface Tunnel200 ip vrf forwarding cust1-vrf ip address 172.16.4.4 255.255.255.0 tunnel source GigabitEthernet0/0 tunnel destination 10.1.1.2 tunnel mode ipsec ipv4 tunnel vrf internet-vrf tunnel protection ipsec profile cust1-ipsec-prof ! interface GigabitEthernet0/0 description internet WAN link ip vrf forwarding internet-vrf ip address 10.1.1.3 255.255.255.224 ! interface GigabitEthernet0/1 description cust1 private VRF ip vrf forwarding cust1-vrf ip address 192.168.88.20 255.255.255.0 ! ip route vrf internet-vrf 0.0.0.0 0.0.0.0 10.1.1.1
"ip vrf forwarding <ivrf>" on the tunnel interface
"tunnel vrf <fvrf>" on the tunnel interface
crypto keyring tagged with fvrf
NO "vrf <ivrf>" on isakmp profile
fvrf on match statement of isakmp profile
no need to worry about RRI (tunnel destination needs to be reachable in fvrf), inside traffic gets routed to the tunnel interface
interfaces in their VRF and proper routes in each VRF as well
Which scenarios are supported?
everything except fvrf=vrf1 and ivrf=global i.e.
ivrf=fvrf=global is OK (this is normal non-vrf aware ipsec)
ivrf=fvrf=vrf1 is OK (this is the example shown in the video)
ivrf=vrf1 and fvrf=vrf2 is OK
ivrf=vrf1 and fvrf=global is OK
in ISAKMP debugs, scroll up and make sure that you match the expected profile!!!, don't focus too much on the errors that you see later on, if you don't match the right profile, start by verifying this.
is the PSK in a keyring and tagged to the right VRF? Does the profile we match have the keyring?
Tunnel is up but traffic not passing
Check the routes in each VRF
confirm with "show ip cef vrf <ivrf> <remote-subnet-ip>" the adjacency for the remote subnet and the interface it goes to
confirm with "show ip cef vrf <fvrf> <peer-ip>" the adjacency for the remote peer
look for "protected vrf" in "show crypto ipsec sa", are we protecting the expected VRF?
Hello, our app samepage.io has been blacklisted and our clients using Cisco are complaining thay cannot access it. We are classified as malware which is wrong. We are a business collaboration platform, have been around for quite a while and we have no mal...
i have recently configured a azure to asa site to site policy base vpn. Devices on the inside subnet can reach azure subnet. But when i try to ping azure subnet from ASA it fails. This makes LDAP authentication to fail since the ASA cant reach the LDAP se...
Can the ASA can authenticate portal access on the firewall (non-firepower)? The ASA would have to intercept a https/http connection request to the public IP of the portal and shunt the request to an authentication service before allowing the traffic....
Hey everyone, We have two 5516's in HA at the moment in our data center that are now nothing more than a VPN concentrator. We have resources in both the DC and in our HQ office. I've been instructed to break the fail-over and bring the secondary...