Archive for the ‘vpn’ tag
Junos – VPN Hierarchy
Wow! A Junos post! Amazing.
We all know that the configuration on a Junos box is very hierarchical. Sometimes it doesn’t make a lot of sense, but it’s all a pretty cascade of code. One of the big messes that I’ve found is the VPN configuration hierarchy; there are way more items to configure than on an IOS device. To reinforce the stpes in my head, I thought I’d get some of the pieces into a post. These aren’t all the options, but it’s all you need to get a static IPSec tunnel up and running.
That’ll do, pig. I’ll fire off a real configuration post later. Feel free to add your pair of pennies since I’m a total Junos n00b.
Send any stocking stuffers questions my way.
VRF-Aware IPSec Tunnels
Man, time is hard to come by of late. I’ve had so little time to rest that’s it’s hard to get my thoughts together. It’s a good thing in this case, though, since it’s my fantastic job that’s taking all my time. It’s great to see new network and learn their internals…especially when they were designed by some long-time CCIEs who actually knew what they were doing.
One of the big things that I’m dealing with lately is VRFs. I’ve implemented some VRF-lite stuff, but I’ve never had any practical experience with the full force of them. I’m definitely learning here. Since the blog here is really about my sharing what I’ve learned, let’s go through something that came up recently – terminating VPNs on one VRF while passing traffic to another.
What I’m talking about is the old-school, static IPSec VPNs that we’ve all configured a million (or so) times. You know the ones with crypto maps applied to interfaces? Well, we’re going to configured one of those for the VRF called “CUSTOMER1″ terminated on an interface in the “INTERNET” VRF.
There’s some terminology for these VRFs, actually. The INTERNET VRF, which has the tunnel endpoint is called the front VRF (FVRF); CUSTOMER1 is called the internal VRF (IVRF). I’ll try to remember to use those terms, but I make no promises.
First, we need to create the VRFs themselves. Since the endpoints are in two different VRFs, we’ll need to have some routes leaked from the IVRF to the FVRF. I could write 847829843828 words on route leaking and not cover everything in my limited experience, so you’ll have to look that up on your own if you don’t know what I’m talking about. Route-target 65000:1 is exported from INTERNET and imported into CUSTOMER1
ip vrf INTERNET rd 65000:1 route-target export 65000:1 ! ip vrf CUSTOMER1 rd 65000:101 route-target import 65000:1
At this point, we just put the interfaces in the right VRF along with their addresses. We’ll also configure an ISAKMP policy just like we’ve done a million times.
crypto isakmp policy 100 encr aes authentication pre-share group 2 ! interface Ethernet0/0 ip vrf forwarding INTERNET ip address 192.0.2.1 255.255.255.0 ! interface Ethernet0/1.1 encapsulation dot1Q 1 ip vrf forwarding CUSTOMER1 ip address 192.168.201.1 255.255.255.0
Next we’ll create a keyring that’s referenced by the IVRF. This will make the key for the remote end available for use by that VRF.
crypto keyring KEY1 vrf INTERNET pre-shared-key address 192.0.2.101 key TEST.KEY
Now we create and ISAKMP profile, which is really the blood and guts that make all this work. An ISAKMP profile references some of the important pieces of the tunnel – the IVRF in which to place the traffic, the keyring to use, and tunnel endpoint, and the FVRF where the tunnel terminates.
crypto isakmp profile CUSTOMER1-PROFILE vrf CUSTOMER1 keyring KEY1 match identity address 192.0.2.101 255.255.255.255 INTERNET
We’ll then create the ACL for interesting traffic. I’ll save some trees and not go through that since this should be pretty easy by now.
Now we can create the crypto map. This will be just like any other crypto map you’ve ever made with one exception; this is where you include that nifty ISAKMP profile we just made.
crypto map CM 100 ipsec-isakmp set peer 192.0.2.101 set transform-set TS set isakmp-profile CUSTOMER1-PROFILE match address CUSTOMER1-TRAFFIC
Just like in other cases, we need to add a static route to make sure the router sends the packets destined for the remote end of the tunnel out the right interface. Since the FVPN is INTERNET, we’ll add static routes for that VRF. We’ll do the same for the tunnel endpoint just in case the default routes doesn’t go the right way.
ip route vrf INTERNET 192.0.2.101 255.255.255.0 192.0.2.2 ip route vrf INTERNET 10.0.0.0 255.255.255.0 192.0.2.2
Now the tunnel should be up, right? Probably not. If you take a close look, you’ll see that the FVRF has the route to the remote network, but the IVRF – the one that will use the tunnel – doesn’t. We’ll need to use MPBGP to leak those routes from one VRF to another. Did I mention that route leaking can get long-winded and that I’m not going to get into it? Yeah…it can get that bad. Just trust me that this works.
What we’re going to do is to start up BGP for both VRFs. At the same time, we’ll redistribute the static routes that we added above from the FVRF into the IVRF. Since we set up our imported and exported route-targets in the VRF definition, the static routes will magically appear in both VRFs.
router bgp 65000 bgp router-id 192.0.2.1 ! address-family ipv4 vrf INTERNET redistribute static exit-address-family ! address-family ipv4 vrf CUSTOMER1 exit-address-family
If we do a show ip route vrf CUSTOMER1, we’ll see the static routes from the INTERNET VRF. They’re real easy to spot. :)
... B 10.0.0.0 [20/0] via 192.0.2.102 (INTERNET), 00:00:05 ... B 192.0.2.1 [20/0] via 192.0.2.102 (INTERNET), 00:00:05 ...
That should do it. Now you should be able to talk from your local network in the CUSTOMER1 VRF and talk through a tunnel that’s established on the INTERNET VRF.
Send any Juniper configs questions my way.
Stubby Post – A Story on VPN Hardware Acceleration
We use a hosted application that requires IPSec tunnels to the provider from different properties across the country. The ones in the lower 48 perform adequately, but the new one in Alaska is absolutely horrible. Read the rest of this entry »
ONT Notes – Pre-classify and End-to-end QoS
- VPNs (Didn’t ISCW cover this?)
- Provide
- Confidentiality
- Integrity
- Authentication
- Types
- Remote-access
- Client-initiated
- NAS-initiated
- Site-to-site
- LAN-to-LAN
- Extranet
- Remote-access
- Provide
- L3 Tunneling protocols
- GRE
- IPSec
- Pre-classify allows traffic to be classified before being sent across a tunnel or crypto-ed.
- qos pre-classify
- Provides a view into the original IP headers
- To classify on pre-tunnel header, apply the policy to the tunnel interface WITHOUT pre-classify.
- To classify on post-tunnel header, apply the policy to the physical interface WITHOUT pre-classify.
- To classify on pre-tunnel header, apply the policy to the physical interface WITH pre-classify.
- SLA – agreement with provider to guarantee QoS mechanisms across their network based on your markings.
- Assures availability, loss, throughput, delay, and jitter.
- End-to-end QoS
- To be effective, each hop in the path must have QoS configured similarly.
- Necessary in three locations
- Campus – within the customer network
- The edges – customer facing the provider, provider facing customer
- On the provider network
- QoS tasks
- Campus access switches
- Speed/duplex settings
- Classification
- Trust
- Phone/access switch configs
- Multiple queues on switch ports, including priority for VOIP
- Campus distribution
- L3 policing and marking
- Multiple queues on switch ports, including priority for VOIP
- WRED
- WAN edge
- SLA definitions
- LLQ
- LFI
- WRED
- Shaping
- Provider cloud
- Capacity planning
- PHB
- LLQ
- WRED
- Campus access switches
- Enterprise campus QoS implementation
- Implement multiple queues to avoid congestion
- Assign VOIP and video to highest priority queue
- Esablish trust boundaries
- Use policing to rate-limit excess traffic
- Use hardware QoS when possible
- Control Plane Policing (CoPP)
- Applies QoS policy to traffic destined for the router
- Routing protocols
- Management protocols
- Can be used to avoid DOS attacks
- Applied to control-plane in global config
- Applies QoS policy to traffic destined for the router
Cheat Sheets from Packetlife.net
My friend Josh over at blindhog.net has found a collection of cheat sheet gems for the network dude(tte). There’s sheets on BGP, OSPF, Subnetting, QoS, connector types, and more. Check it out.
GRE Tunnels and Encryption
GRE tunnels rock. They are interfaces on a router that are used to “connect” to another router somewhere on your LAN, your WAN, the Internet, wherever. The most popular use for them is for router-to-router VPNs.
I’ll let my friend Josh from blindhog.net show you how to do it. He’s got a video on how to configure the tunnels, and another on how to set it up for VPN.