February 21, 2008
Static NAT Inaccessible Through VPN Connections
Alright, I've run into this problem three times now and each time I keep having to rediscover the solution, so I thought I'd write the solution here for myself and whomever it may help. Here's the problem:
Creating site-to-site VPN connections as a WAN link replacement is becoming quite common. The problem I continually encounter is the servers behind the router that have Static NAT entries allowing them to be accessible from the outside world become inaccessible through the VPN (using a private address). VPN users can still access the servers by using the Internet connection. This problem occurs simply because of the order in which the Cisco router handles NAT rules.
Take this example. A user from SiteA accesses ServerB at SiteB using its private address on TCP port 80 (HTTP):
UserA ---> Site-to-Site VPN ---> ServerB
The request reaches ServerB who attempts to transmit back to UserA. The router at SiteB has a Static NAT mapping allowing ServerB to be accessible from the Internet. This Static NAT mapping is processed before the site-to-site VPN rule:
ServerB Response ----> Static NAT mapping ---> Reply sent to Internet abyss
The result is the HTTP connection from SiteA times out. So, here's how to fix it:
RouterB(config)#route-map NO_NAT
RouterB(config-route-map)#match ip address 100
RouterB(config-route-map)#exit
RouterB(config)#access-list 100 deny ip host 192.168.15.100 192.168.10.0 0.0.0.255
RouterB(config)#access-list 100 permit ip 192.168.15.0 0.0.0.255 any
RouterB(config)#ip nat inside source static tcp 192.168.15.100 80 81.14.214.29 80 route-map NO_NAT
The above configuration essentially denies the server from going through the Static NAT entry when speaking to hosts across the VPN, but permits it to pass through Static NAT for everything else.
Here's the original Cisco reference:
http://www.cisco.com/warp/public/707/static.html#topic2
Posted by JC at 11:34 AM | Comments (7) | TrackBack
December 14, 2006
Configuring a Cisco Router to Accept VPN Connections
This blog has been a long-time-coming as someone asked me quite some time ago to post the simplest way to accomplish this (for a home environment). I hate to admit this, but my home PC (where I get all my email) was hacked since I allowed Microsoft's Remote Desktop Protocol (RDP) and VNC from anywhere on the Internet (very bad idea). That was the end of that - now VPN connections are required to get to my home PC. Well, the simplest way to configure a VPN on a router is to use the Cisco SDM...but Real Cisco Techs™ use the command line :). So here we go:
First thing you need to do is specify an authentication method. Since I'm assuming this is for a home environment, using the local router database is just fine:
Router(config)# aaa authentication login LOCAL_DB local (defines a login method called LOCAL_DB that uses the local DB)
Router(config)# username Jeremy password cisco (creates a user account in the local DB)
Second, you need to define a DHCP pool of addresses for your VPN clients. This is the address range that they will be assigned when they connect. This should be a unique range not in use on your LAN:
Router(config)# ip local pool CLIENT_ADDRESSES 172.30.50.10 172.30.50.20
Next, you have to create an ISAKMP policy. This is a policy that secures Phase 1 of the VPN negotiation. Phase 1 is there to allow you to securely exchange the encryption keys you'll be using for the VPN. Without this phase, someone could sniff your encryption keys and compromise the VPN security:
Router(config)# crypto isakmp policy 1
Router(config-isakmp)# encr aes (my preferred encryption: 128-bit AES; fast and secure)
Router(config-isakmp)# authentication pre-share (says that I'll need to type a secret key on the router & VPN client)
Router(config-isakmp)# group 2 (Diffie-helman group 2...super strong keys to lock down Phase 1)
Now, I need to configure a client configuration group. This is what gives the clients their settings (such as DNS server, IP address, etc...).
Router(config)# crypto isakmp client configuration group HOME
Router(config-isakmp-group)# key s3cr3t (the client has to provide this key to connect to the VPN)
Router(config-isakmp-group)# dns 172.30.100.11 (assigns a DNS server to the client)
Router(config-isakmp-group)# domain ciscoblog.com (assigns a DNS suffix to the client)
Router(config-isakmp-group)# pool CLIENT_ADDRESSES (says that this client will get an IP address from the CLIENT_ADDRESS pool)
There is MUCH more you can put under the above config to define things like split tunneling and access control...but that discussion is for another day :)
Next up, we can configure the settings for the IPSEC tunnel (all this stuff until now has been Phase 1, pre-tunnel info). Initially, we must set up a transform set. This defines what level of encryption (scrambling data so people can't read it) and hashing (checking to make sure data doesn't change) we'd like to use:
Router(config)# crypto ipsec transform-set JEREMYS_SET esp-aes esp-sha-hmac
As a fly-by description, the line above sets the VPN encryption to AES 128-bit and uses SHA-1 (160-bit, I believe) hashing. This is what I'd recommend, but you can choose whatever levels you'd like (just hit the ? key to see all your options).
Now we can create a crypto map. A crypto map takes all these settings and sums them together into something we can apply to an interface:
Router(config)# crypto dynamic-map CLIENT_MAP 1 (creates a dynamic map, which is used for remote access clients)
Router(config-crypto-map)# set transform-set JEREMYS_SET (says that this will be the transform set used for clients)
Router(config-crypto-map)# reverse-route (puts the client IP address in the routing table when the client connects)
Router(config)# crypto map JEREMY_VPN client authentication list LOCAL_DB (links authentication method to the VPN)
Router(config)# crypto map JEREMY_VPN isakmp authorization list LOCAL_DB (links authorization settings - what a user can do - to the VPN)
Router(config)# crypto map JEREMY_VPN client configuration address respond (allows router to respond to DHCP requests from clients)
Router(config)# crypto map JEREMY_VPN 100 ipsec-isakmp dynamic CLIENT_MAP (applies the dynamic crypto map to the real crypto map)
FINALLY, we can apply the crypto map to the interface:
Router(config)# interface fa0/1 (my DSL connection interface)
Router(config-if)# crypto map JEREMY_VPN (applies the crypto map from above)
The router is now ready to accept VPN connections. Now that I'm looking back over this, I'm sure it's generated many more questions than it answered...ask away :).
Posted by JC at 8:16 PM | Comments (22) | TrackBack
September 25, 2006
Cisco WebVPN / SSL VPN / Thin Client /
SSL VPNs are the future of VPN technology. While they are still brand new, "bleeding edge" sort of technology, they will eventually be how we run our VPN connections for most organizations. The concept is simple: HTTPS (SSL-based) web pages have used adequate encryption for years...why not harness the technology to create a "client-less VPN system," tunneling applications through the SSL connection.
For a user to connect to a SSL VPN, no client installation is necessary. Rather, they simply access a web page, authenticate, and minimize the web browser window. They're now on the corporate VPN.
There's more to it than this (such as JAVA client downloads may be necessary for full port forwarding capabilities, etc...). Cisco just published an excellent explanation / configuration document for the WebVPN/SSL VPN technology. Get it here.
Posted by JC at 9:55 AM | Comments (6) | TrackBack
August 26, 2006
VPN Virtual Tunnel Interfaces
While doing a recent deployment, I ran across this concept. It's a slightly different way to configure VPNs on a Cisco router that (for me) is far less confusing and finicky. If you've ever configured VPNs using a PIX firewall or IOS router, you probably know of the pain associated with making sure your crypto map is correctly configured. There are SO MANY pieces of it, you're almost assured that something is not going to match between one side of the connection and the other (especially that "interesting traffic" ACL). That's where these IPSec Virtual Tunnel Interfaces come in. Check this out...
Instead of configuring crypto maps between your routers, you create virtual interfaces. So the VPN has it's own "point-to-point" style connection between sites. The best way to get this is to see a configuration example. I borrowed the syntax / graphic for this example from Richard Deal's Complete Cisco VPN Configuration Guide by Cisco Press (awesome book, by the way).
RouterA Configuration:
RTRA(config)# crypto isakmp policy 10
RTRA(config-isakmp)# encryption aes 128
RTRA(config-isakmp)# hash sha
RTRA(config-isakmp)# authentication pre-share
RTRA(config-isakmp)# group 2
RTRA(config-isakmp)# exit
RTRA(config)# crypto isakmp key cisco123 address 193.1.1.1 255.255.255.255 no-xauth
RTRA(config)# crypto ipsec transform-set RTRtran esp-aes esp-sha-hmac
RTRA(cfg-crypto-trans)# exit
RTRA(config)# crypto ipsec profile VTI
RTRA(ipsec-profile)# set transform-set RTRtran
RTRA(ipsec-profile)# exit
RTRA(config)# interface tunnel 0
RTRA(config-if)# ip address 192.168.3.1 255.255.255.0
RTRA(config-if)# tunnel source 192.1.1.1
RTRA(config-if)# tunnel destination 193.1.1.1
RTRA(config-if)# tunnel mode ipsec ipv4
RTRA(config-if)# tunnel protection ipsec VTI
RTRA(config)# interface Ethernet0/0
RTRA(config-if)# ip address 192.1.1.1 255.255.255.0
RTRA(config-if)# exit
RTRA(config)# interface Ethernet 1/0
RTRA(config-if)# ip address 192.168.1.1 255.255.255.0
RTRA(config-if)# exit
RTRA(config)# ip route 192.168.2.0 255.255.255.0 tunnel0
RouterB Configuration:
RTRB(config)# crypto isakmp policy 10
RTRB(config-isakmp)# encryption aes 128
RTRB(config-isakmp)# hash sha
RTRB(config-isakmp)# authentication pre-share
RTRB(config-isakmp)# group 2
RTRB(config-isakmp)# exit
RTRB(config)# crypto isakmp key cisco123 address 192.1.1.1 255.255.255.255 no-xauth
RTRB(config)# crypto ipsec transform-set RTRtran esp-aes esp-sha-hmac
RTRB(cfg-crypto-trans)# exit
RTRB(config)# crypto ipsec profile VTI
RTRB(ipsec-profile)# set transform-set RTRtran
RTRB(ipsec-profile)# exit
RTRB(config)# interface tunnel 0
RTRB(config-if)# ip address 192.168.3.2 255.255.255.0
RTRB(config-if)# tunnel source 193.1.1.1
RTRB(config-if)# tunnel destination 192.1.1.1
RTRB(config-if)# tunnel mode ipsec ipv4
RTRB(config-if)# tunnel protection ipsec VTI
RTRB(config)# interface Ethernet0/0
RTRB(config-if)# ip address 193.1.1.1 255.255.255.0
RTRB(config-if)# exit
RTRB(config)# interface Ethernet 1/0
RTRB(config-if)# ip address 192.168.2.1 255.255.255.0
RTRB(config-if)# exit
RTRB(config)# ip route 192.168.1.0 255.255.255.0 tunnel0
The configuration is pretty straightforward, especially if you've configured GRE tunnels before. The difference is you use the "tunnel mode ipsec ipv4" command to notify the router that this is an IPSec-based interface rather than GRE and the "tunnel protection ipsec
The best part of the whole thing is NO CRYPTO MAPS!!! :) I love it - traffic is associated with a remote site using "ip route" static routes rather than mirrored ACLs. Awesome stuff!
Posted by JC at 9:28 AM | Comments (21) | TrackBack
February 9, 2006
Creating Site-to-Site VPNs with Pre-Shared Keys
I just finished recording a Cisco Security title for CBTNuggets. It came out awesome. When recording the VPN section, I typed up a document showing the minimum configuration to get a site-to-site VPN running with pre-shared keys. Those of you that have configured this before know how much of a headache getting all the configuration settings correct can be. Hopefully this document will help ease that pain!
Creating Site-to-Site VPNs with pre-shared keys (PDF)
Posted by JC at 4:33 PM | Comments (1) | TrackBack