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

IPSec VPN Remote Access

Morning,

My weekend was dedicated to my new toy.

I bought a HWIC-3G-GSM the other day and finally had 2 connections to the internets. eBay is evil.

I also have a WIC-1AM but it's too slow/frustrating to do anything interesting. eBay is evil.

If you want some great info on how to set up the 3G HWIC, go here http://whirlpool.net.au/wiki/?tag=3G_for_Network_Engineers. Without it, I wouldn't have got anywhere.

I was trying to replicate a scenario that a colleague had whereby roaming users would connect via IPSec on the 3G interface. The 3G interface would also be used for redundancy in case the primary link (I assume DSL of some sort) was down.

I'd never done a config for IPSec Remote Access so this was another learning experience. I've only ever done tunnel interfaces site-to-site protected by IPSec transform sets.

In a nutshell, this is what you can do:

(I apologize for the lack of detail. I'm the sort of person to hack something together and then randomly change things to see what happens. I'm only a CCNA at present and learning VERY slowly, often the hard way. For all intents and purposes, one can safely assume that I have no idea what I'm doing.)

1. Enable AAA. These will define the authentication methods for your remote IPSec clients. I'm using local authentication. You'll need to set up local users (username administrator password test)
   aaa new-model
aaa authentication login vpnuserauth local
aaa authorization network vpnusers local
aaa session-id common
2. Define a local IP pool for your VPN users. These will be the IP addresses assigned to remote access clients.
   ip local pool vpnpool 192.168.0.1 192.168.0.12
3. Define an ACL to identify your traffic to be encrypted
   access-list 123 permit ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255
4. Define a crypto isakmp policy. This policy must be matched by the VPN Client. I've been using this one for my site-to-site tunnels and this works with the Cisco VPN Client too.
   crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
5. Define a crypto ipsec transform set. As far as I know, this defines the encryption & hash algorithms to run on your data.
   crypto ipsec transform-set vpnset esp-3des esp-sha-hmac
6. Define a dynamic crypto map. Like a normal crypto map, but not all fields required. Only required field is the transform-set.
   crypto dynamic-map vpndynmap 1
set transform-set vpnset
7. Set up a crypto map that specifies authentication methods and links the dynamic map to it.
   crypto map vpnmap client authentication list vpnuserauth
crypto map vpnmap isakmp authorization list vpnusers
crypto map vpnmap client configuration address respond
crypto map vpnmap 1 ipsec-isakmp dynamic vpndynmap
8. Define a crypto client group and client settings
   crypto isakmp client configuration group vpnusers ! vpnusers is the group authentication used in the VPN Client
key Passw0rd
dns 10.0.0.32 ! you can set up dns and wins etc. see ? help for more options
wins 10.0.0.32
domain mydomain.com
pool vpnpool ! from Step 1
acl 123! identifies what traffic is to be encrypted
9. Assign the crypto map (vpnmap) to the appropriate WAN interface. Make sure you are not blocking IKE/IPSec traffic on the interface.
10. I don't know if this is required, but if you are NAT'ting on the interface (eg Dialer 3), you may want to disable NAT for traffic going from local -> VPN Client (10.0.0.0 -> 192.168.0.1)
11. I don't know if this is absolutely required either, but a route for 192.168.0.0 via Dialer 3 wouldn't be a bad idea.

So far so good, VPN Clients worked fine via the 3G interface. Now to make it do some NAT so I can browse through it.

I set up the Dialer 3 as ip nat outside and attempted to NAT traffic through it.

I also have Dialer 0 as my default route, and also an outside NAT interface.

Rookie Mistake #1

I had two NAT statements that I thought would cover it, provided I routed through the correct interface.

ip nat inside source list 100 interface Dialer 0 overload ! DSL
ip nat inside source list 103 interface Dialer 3 overload ! 3G
access-list 100 deny ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 100 permit ip 10.0.0.0 0.0.0.255 any

access-list 103 deny ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255
access-list 103 permit ip 10.0.0.0 0.0.0.255 any

So, off I go and make a static host route to a (business) client of mine and see if I can go via my 3G... No luck. Pings would timeout. Telnets to the SMTP server on the other end would fail. Funny enough, I could telnet to the mail server directly from the router, do an ehlo and it would show me the 3G IP address. It appeared that NAT wasn't working correctly. I started getting worried thinking: oh great, you just signed up for mobile internet & bought an expensive toy and it doesn't even work!

Rookie learns to "debug ip nat"

Debugs returned this: NAT: translation failed (A), dropping packet

Google returned 1 suggestion that I should enable ip subnet-zero. Clutching at straws, I did so even though it's now a default (just in case!). No change.

Then it hits me. It's trying to use the Dialer0 IP address while going out Dialer3, hence the failure. I obviously need to link the outgoing interface to the correct NAT statement.

Enter: ip nat inside source route-map

I've always wondered why anyone would use a route-map as a nat source. Now I know.

To link the outgoing interface to the correct address, I did the following:

route-map dslTraffic
match interface dialer0
match ip address 100

route-map celTraffic
match interface dialer3
match ip address 103

I then changed the 2 nat statements above to:

ip nat inside source route-map dslTraffic interface dialer0
ip nat inside source route-map celTraffic interface dialer3

Tada!

I didn't have time to do failover, but it can't be that hard? Can it?!?

anon ms.