Its been a while since I've sunk my teeth into something new. I've had the time consuming tasks of updating CV's and interview skills, for the impending shake up of the organisation I work for. CCNP study has taken a slight sidewards step (better than backwards) during recent weeks - but I've got a holiday booked shorty and there is no better way to learn than in the sun.
Problem
Anyway, we have the following situation:
Without concentrating on the lines and arrows, there are two sites depicted in the diagram. The top one (the top blue oblong that covers the LAN and two routers) is what we'd call a hub site. It is one of 5 sites that all connect together to form the core of the network. As you can see with the 3 black lines coming from the Cisco 3745.
The other site (the bottom blue oblong) is what we call a remote site. They typically connect back to their closest hub site, (based on legacy geographical cost) and we support about 60 of these remote sites - so the diagram is obviously cut down.
Both sites have an internet connection. The router that manages the internet connection is controlled by a third party - so we have no access to it. It has no firewall though, so we run CBAC on our routers.
The green lines at the remote site show traffic flow. The 1841 makes the decision (based on static routes) which path to take based on the destination address. If it is one of a pre-defined IP range for a website, then off it goes out of the local internet connection. If it is an internal address (server, other remote site etc) then the packets are routed through the default route and back to the hub site via a 2mb serial connection - WHICH IS OVERSUBSCRIBED.
Question?
And thus a question has been asked:
"If the 2mb connection goes down (often), can there be a backup route using the internet connections?"
Also...
"Could the two routes be used in tandem to increase throughput?"
The diagram (if possible) might look like this:
Answer...
The answer is yes. To both questions. Although I can't see this being implemented.
We already use GRE tunnels (see my previous posts) but that is internal. With this setup, we'd need some form of encryption when tunnelling through the internet.
I'll explain the tunnel setup first and just gloss over the other parts. As I mentioned, this probably wont get implemented and its purely just answering the question to detail a business case to make it happen to then not make it happen. Does that make sense? No - thats politics for you.
On with the technical.
IPSEC over GRE/GRE over IPSEC...
Its one or the other, but I don't know/don't need to know which - google is your friend, if you're bothered. Technically the tunnel would be accomplished using general routing encapsulation, but yet we'd run IPSEC to encrypt GRE packets. But then, you need IPSEC to create the encryption to run GRE in the first place. But you need the tunnel to then use the transport protection of IPSEC. Chicken & Egg, I suppose.
I've configured the remote site router first:
!
crypto isakmp policy 10
authentication pre-share
!
crypto isakmp key CISCO address 10.66.6.5
!
We define an ISAKMP policy (Good info about what this is and what it does is here) (and give it a priority number) and then instruct the policy to use pre-shared keys as the authentication method for this policy. Two peers must have a common policy or they wont connect.
We then specify what the key will be, in this example CISCO is used - passwords and IP's are abviously made up for the purposes of this post! We also define the 'other end' I.P address with whom the key exchange will take place.
!
crypto ipsec transform-set Transformers esp-3des esp-sha-hmac
mode transport
!
crypto ipsec profile MyProfile
set transform-set Transformers
!
Transform sets are then used (in this case we called ours transformers) to detail what encryption and authentication methods are used for the ESP protocol (Encapsulating security payload) which is what establishes the IPsec tunnel encryption and authentication between the peers. They must be the same at both ends or the IPSEC tunnel will not form.
The ipsec profile defines the parameters to be used between the two routers which we will reference in the tunnel protection command later. It references the previously created transform set - You might find this confusing, but remember you can use different transform sets with different profiles and even both of them can be referenced with different ISAKMP policies! As our example is using a simple point to point, some commands can seem overkill, but they are necessary.
!
interface Tunnel1
ip address 12.0.0.2 255.255.255.252
tunnel source 10.99.9.1
tunnel destination 10.66.6.5
tunnel mode ipsec ipv4
tunnel protection ipsec profile MyProfile!
!
And here we have one end of the tunnel. This one is referenced locally as 'tunnel1'.
The ip address is a completely private range and we've assigned a subnet mask so that only the two peers are useable.
The tunnel source is the interface IP for the interface you want to create the tunnel on. Similarly the destination is the interface IP of where the end of the tunnel should be.
Rather than using GRE, we specify the tunnel mode to be ipsec ipv4 and then introduce the tunnel protection command to reference the ipsec profile - which in turn references the transform set with encryption and authentication information.
Thats pretty much it. That creates one end of the tunnel on the remote site router and the process of creating the other end is just a reversal of the IP addresses used above - oh, and the ip address of the tunnel being the other useable one in that subnet!
We configured the above in a test environment and guess what? It didnt work.
Why it didn't work
I mentioned earlier that we use CBAC (or ip inspect as its referenced) and thus inbound access lists prevent any nasties from the internet making their way into the corporate network. We had to add a couple of earlier sequence numbers to an extended access list to ensure that both UDP and ESP were permitted from the respective peers.
Like so:
!
ip access-list extended INBOUND
8 permit udp host 10.66.6.5 eq 500 host 10.99.9.1 eq 500
9 permit esp host 10.66.6.5 host 10.99.9.1
!
Remember that because the list is INBOUND and applied with the IN statement, the source and destination fields of the ACL must reflect the peer at the other end. I'm only making this point because I'm used to amending ACL's for outbound access and thus I did it wrong.
Default keepalives were at 10, so we thought we'd adjust them to 5, but its user preference and not the reason why it didn't work.
Be aware:
Show int tun1 - should tell you if both the interface and protocols are up. Check the logs too, to ensure the tunnels are passing the authentication and encryption stages of the exchange. Ping the private addresses from each device to ensure connectivity is established. If you add static routes to test end to end Ip ranges, then ensure you specificy the source interfaces when trace routing or pinging.
Using it as a backup route - question 1
So the question was asked about using the tunnel as a backup. Given the 2mb serial is referenced with a: ip route 0.0.0.0/0 then we can simply add another static route but with a higher cost, to form a 'floating' static.
Load balancing - question 2
I didn't look into this option (I know, I know) but its simply because I can't replicate it in a lab environment. BUT... because we use RIPv2 then technically the tunnel would have to have the same hop count to reach the subnets in question as it would using the 2mb circuit. If so, then by default the Cisco router would load balance with 2 entries in the routing table. See my earlier posts about process and packet switching to understand how this load balancing would occurr. It would likely be load balanced per destination and not per packet - even so, with the 2mb serial connection saturated, a little breathing space would be created if only temporarily!
Hope it helps you if you need to create a point to point tunnel - securely.
This comment has been removed by a blog administrator.
ReplyDelete