anon.ms anon ms it guy: more than break-fix

23Nov/090

Directing HTTP Traffic onto Another Link

Hello,

A client of mine unfortunately cannot get ADSL2+ at their new office. They have 3 ADSL1 services instead.

We decided to use one for HTTP/HTTPS traffic to take some of the load off their primary link.

You can use Policy Based Routing to do this.

Numbers:
Default Gateway: 192.168.1.1
Secondary DSL router: 192.168.1.2
Vlan1 Address: 192.168.1.1

First, define an access list that selects your interesting traffic:
access-list 180 remark *** Select HTTP/HTTPS Traffic ***
access-list 180 permit tcp 192.168.1.0 0.0.0.255 any eq 80
access-list 180 permit tcp 192.168.1.0 0.0.0.255 any eq 443

Next, define a route-map that matches the interesting traffic, and sets the next-hop IP address.
route-map WebTraffic permit 10
match ip address 180
set ip next-hop 192.168.1.2

Apply it to the vlan interface
interface Vlan1
ip policy route-map WebTraffic

If, for example, they were hosting services on the second line using a server at 192.168.1.49, you can select more interesting traffic:
access-list 180 remark *** SELECT HTTP/HTTPS Server Traffic ***
access-list 180 permit tcp host 192.168.1.49 eq 80 any
access-list 180 permit tcp host 192.168.1.49 eq 443 any

anon ms.

20Nov/090

Renaming a Network

Hey,

To make my life easier, I often set up site-to-site VPNs to the clients my own company looks after.

I sometimes set up site-to-site VPNs to the larger clients of my employer.

I encountered a problem recently where my Client's and my Employer's Client's subnets were the same: 192.168.0.0/24.

I knew what needed to be done, but whether or not it was possible I was not sure.

Basically I had two options:
1. Change the source as it left one of the client's, and change the destination on it's way back
OR
2. Change my destination as it left my network, and change the source as it came back.

Even though I had full access to both Clients' routers, I thought it would be better if I did it on my own company's router. Option 2.

So, from my previous posts you will see that I particular like Tunnel interfaces.

I did some research, and found I had to change my usual Tunnel interface and define it as an outside nat interface.

Example:
MyRouter(config)# interface Tunnel9
MyRouter(config-if)# ip unnumbered Vlan1
MyRouter(config-if)# ip nat outside
MyRouter(config-if)# tunnel source Dialer0
MyRouter(config-if)# tunnel destination A.A.A.A
MyRouter(config-if)# tunnel mode ipsec ipv4
MyRouter(config-if)# tunnel protection ipsec profile ipsecProfile

I then needed to define my rules for translation, plus a new route.

ip nat inside source static network 192.168.9.0 192.168.0.0 /24
ip nat outside source static network 192.168.0.0 192.168.9.0 /24
ip route 192.168.9.0 255.255.255.0 Tunnel9

Works perfectly, although I find the terms REALLY confusing!!!

Of course I will need a corresponding route on the remote router back to my network.

ip nat inside source static will change the SOURCE on its way OUT, and DESTINATION when it comes back in. (Compare this to a usual ip nat outside on a Dialer for internet sharing).
This seems counter-intuitive as the Tunnel interface is ip nat outside. When traffic goes out via the Tunnel, it is essentially going in->out, then why is the SOURCE not changed? The source will always be from my Vlan1, correct?

I can't explain this one. Any help is appreciated!

Also:

show ip nat translations will give:

Pro Inside global Inside local Outside local Outside global
--- ---           ---          192.168.9.0   192.168.0.0
--- 192.168.0.0   192.168.9.0  ---           ---

19Nov/090

Site-to-Site VPN with Virtual Tunnel Interfaces

Hey,

There are many ways to create Site-to-Site VPNs. One method that I like uses Virtual Tunnel Interfaces with optional IPSec encryption.

This method allows you to create a virtual interface and you are able to see if the tunnel is up/down.

I will be using IPSec in this example, and I assume both sites have Static IP addresses.

This example pretty much has 5 things involved: isakmp policy, isakmp key, transform set, and the actual tunnel interface, and of course a static route pushing other-site traffic across it.

First, define your ISAKMP Key to identify each side:

RouterA(config)# crypto isakmp key P455word address B.B.B.B

Next, define your ISAKMP policy:

RouterA(config)# crypto isakmp policy 1
RouterA(config-isakmp)# encr 3des
RouterA(config-isakmp)# authentication pre-share
RouterA(config-isakmp)# group 2

Then define your IPSec Transform Set:

RouterA(config)# crypto ipsec transform-set ipsecTransformSet ah-sha-mac esp-3des

Now we are ready to define our Tunnel Interface:

RouterA(config)# interface Tunnel1
RouterA(config-if)# description *** Tunnel to RouterB ***
RouterA(config-if)# ip unnumbered Vlan1
RouterA(config-if)# keepalive 10 3
RouterA(config-if)# tunnel source A.A.A.A
RouterA(config-if)# tunnel destination B.B.B.B
RouterA(config-if)# tunnel mode ipsec ipv4
RouterA(config-if)# tunnel protection ipsec profile ipsecProfile

I personally like to limit the number of IP addresses I need to worry about, hence the use of ip unnumbered Vlan1. Other configurations include a different subnet (most likely a /30) to identify each side of the tunnel. This means you can ping the other side of the Tunnel if you wish.

Now we can identify our static route:

RouterA(config)#ip route 192.168.0.0 255.255.255.0 Tunnel1 permanent

I add the permanent option here so that in the event the Tunnel is down, it does not go across the default route, usually a Dialer which goes out the internet.

If you are having trouble getting your Tunnel up, make sure you are not denying any IPSec or GRE traffic on your WAN connection and that you have the correct isakmp keys and addresses defined on both routers.

You may like to debug crypto isakmp and crypto ipsec to see what's going on.

You can temporarily leave your tunnel unsecure by removing:
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsecProfile

The RouterB configuration will be the same except for the isakmp key (at address A.A.A.A) and the Tunnel interface source and destinations switched around.

Hope that helps,

anon ms.

Disclaimer: I don't know enough Cisco to answer all the questions regarding IPSec and Virtual Tunnel Interfaces. For all intents and purposes, I have no idea what I'm doing!