Cisco VRF-lite and VRF-Aware IOS Firewall

[drebo]

I am putting together a network currently that will utilize VRF-lite to segregate various customer VPNs. I am using VRF-lite because I don't have the need for capacity greater than a single Cisco 7206 at the moment, and I don't really anticipate growing past that for the forseeable future (although that would be a good problem to have).

I am having a bit of trouble wrapping my brain around how to implement the firewall, though. The idea is to provide "in-cloud" internet access for my customers using VRF-Aware NAT as well as IPsec access to their VPN. To that end, I have already configured NAT and it works fine. But I would also like to secure that NAT with the IOS firewall.

Right now, the two ways that I can think of for doing this are: 1) to create a separate routed subinterface to represent each VRF instance between this router and the upstream router, or 2) to have a single monolithic ACL and inspect class to apply to the existing interface which would cover all PATs and static NATs for all customers on this router.

How is this kind of thing normally done? I'd prefer not to create routed subinterfaces for each VRF to avoid IP address waste, but I certainly can if I need to.

Here are some relevant portions of my config to see how I'm currently handling things (IP addresses have been obfuscated, but all subnets are correct). Constructive criticism is welcome.

ip vrf 1001
 description Test Network 1
!
interface Loopback1
 ip address 1.1.169.1 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 ip ospf network point-to-point
!
interface Loopback1001
 ip vrf forwarding 1001
 ip address 192.168.163.55 255.255.255.255
 ip nat inside
 ip virtual-reassembly
!
interface Tunnel101
 ip vrf forwarding 1001
 ip address 172.29.1.1 255.255.255.252
 ip nat inside
 ip virtual-reassembly
 ip ospf network broadcast
 tunnel source 1.1.173.2
 tunnel destination 3.3.5.2
 tunnel key 11022
!
interface Port-channel1
 no ip address
 duplex full
 hold-queue 150 in
!
interface Port-channel1.1731
 encapsulation dot1Q 1731 native
 ip address 1.1.173.2 255.255.255.252
 ip nat outside
 ip virtual-reassembly
!
router ospf 1001 vrf 1001
 router-id 1.1.1.1
 log-adjacency-changes
 area 1 stub
 network 172.29.1.0 0.0.0.3 area 1
 network 192.168.163.55 0.0.0.0 area 0
!
router ospf 1
 router-id 1.1.1.2
 log-adjacency-changes
 network 1.1.169.0 0.0.0.255 area 0
 network 1.1.173.0 0.0.0.3 area 0
!
ip forward-protocol nd
ip route vrf 1001 0.0.0.0 0.0.0.0 Port-channel1.1731 1.1.173.1
!
ip nat pool 1001 1.1.169.65 1.1.169.65 netmask 255.255.255.0
ip nat inside source list 1301 pool 1001 vrf 1001 overload
!
access-list 1301 permit 192.168.163.55
access-list 1301 permit 10.0.0.0 0.255.255.255

Any insight would be appreciated! Thanks!

 

[sactwnguy]

I have never done vrf-lite so I am not sure what the limitations are but if I was trying to do this I would configure overlapping VPN's using route targets with the Internet router in the center able to access all of your customer VPN's. I have done this for a centralized backup network but not for Internet. I would just assume you would advertise a default route from your Internet vrf into your customer vrf's.

 

[drebo]

Well, that's what the static route does. Because I want everything self-contained in this one router, I'm having some trouble conceptualizing this.

I guess the other thing I could do is create a /32 loopback address for each IP address I needed to NAT to. That way, I could apply a separate ACL to each customer and just apply it to each loopback they need. That might accomplish what I need...

I'll try that. If I ever need so many that my router can't handle it anymore, I'll be glad to have to upgrade

 

[sactwnguy]

I was thinking something along the lines of this. This is just off the top of my head so I would recommend reading up on it.


ip vrf internet
rd 1:1
route-target export 1:1
route-target import 1:1
route-target import 2:2
route-target import 3:3
!
ip vrf cust1
rd 2:2
route-target export 2:2
route-target import 2:2
route-target import 1:1
!
ip vrf cust2
rd 3:3
route-target export 3:3
route-target import 3:3
route-target import 1:1


router ospf 1 vrf cust1
network x.x.x.x

router bgp 6000
no synchronization
bgp log-neighbor-changes
no auto-summary

address-family ipv4 vrf internet
network 0.0.0.0


address-family ipv4 vrf cust1
network x.x.x.x

address-family ipv4 vrf cust2
network x.x.x.x

 

[Cooky]

We support & maintain different networks w/ the way sactwnguy has it (different vrf instances & utilizing route-target import/export).

You would still have separate interfaces to your upstream/downstream routers where your customers transit through, unless each is assigned to a different vlan/SVI, and you bring them in over a trunk.

Doing it this way gives you an easy way to migrate from vrf-lite to a full blown MPLS, should you decide to grow into a multi-node scenario.
It also allows you to support multiple types of services.
Each service can have a unique vrf & route-targets assigned to facilitate who gets what services.

I'm kind of puzzled though by what you said about everything is self-contained in this one router...
What role is your 7206?
Is it the core, or Internet edge?

 

[drebo]

This 7206 is just going to be an aggregation router. Various customer links (T1s or tunnels) will terminate here to be used in VRFs or as simple Internet access links. I've got another 7206 which serves as my core and internet edge router. It's not a very complex network.

The customer VRFs are all going to be private IP ranges, with the rest of the router being global IPs.

Routing to the internet isn't the problem. My config above works properly for NATing the customer VRFs to the Internet. My question was mainly what is the best way to firewall that NAT without wasting IP addresses. It turns out that there really isn't a way, so I'm not going to bother. I'll just offer customers single PATs or one-to-one NATs, and have a general ip inspect class for all customers. If they want to firewall them individually, they can use a transparent firewall at their site.

I haven't bothered using route targets because I can't see us moving to a multi-node scenario any time soon. My opinion is that we need to...if for no other reason than so that we can offer cheaper T1s to our main customer base. Unfortunately, it's not my decision. I can just take what I'm given and try my best to make it work.

In this case, I was told "use existing equipment and implement this for a customer". Well, it would have been easy to set up a dedicated router specifically for this customer and not bothered with VRF, but I can see the potential for us to be able to provide this to some of our other customers.

 

[drebo]

Ok, I think I understand what you guys are getting at.

I should create another VRF that is also a private network and import my customer VRFs into that VRF so that all internet access goes through that new VRF.

When I do this and configure my BGP, do I set this up under my current (public) AS or do I run a new BGP instance specifically for my internal network? The two shouldn't ever need to talk to each other, from what I understand (my public BGP session is only public IPs, and my private one is only for customer networks).

 

[Cooky]

I would use a private BGP ASN for this purpose.
If all these vrf's are contained within this aggregation 7206, you're correct you don't need to peer w/ another router via BGP.
BGP is just used to facilitate the route-target import/export.

Keep in mind the import/export is still subject to the BGP timer, so don't be alarmed if it doesn't work right after the config is put in.