Re: VPN connects, but can't ping inside interfaces (local LAN)

dgroscost · ‎07-22-2004

I can connect from the internet and VPN in, but I can't ping the internal LAN - even the internal router address I am connecting to.

Please advise - thanks!

Config off Cisco 831 router:

version 12.3

no service pad

service tcp-keepalives-in

service tcp-keepalives-out

service timestamps debug datetime msec localtime show-timezone

service timestamps log datetime msec localtime show-timezone

service password-encryption

service sequence-numbers

!

hostname VPN

!

boot-start-marker

boot-end-marker

!

security authentication failure rate 3 log

security passwords min-length 8

logging buffered 51200 warnings

!

username xxxxx password 7 xxxxx

aaa new-model

!

aaa authentication login userauthen local

aaa authorization network groupauthor local

aaa session-id common

ip subnet-zero

no ip source-route

!

ip dhcp excluded-address 192.168.1.1 192.168.1.99

!

ip dhcp pool CLIENT

import all

network 192.168.1.0 255.255.255.0

default-router 192.168.1.2

dns-server 151.202.0.85 151.203.0.85

lease 3

!

no ip domain lookup

no ip bootp server

ip cef

ip ips po max-events 100

no ftp-server write-enable

!

crypto isakmp policy 3

encr 3des

authentication pre-share

group 2

!

crypto isakmp client configuration group XXXXX

key XXXXX

pool vpnpool

acl 108

!

crypto ipsec transform-set myset esp-3des esp-sha-hmac

!

crypto dynamic-map dynmap 10

set transform-set myset

!

crypto map clientmap client authentication list userauthen

crypto map clientmap isakmp authorization list groupauthor

crypto map clientmap client configuration address respond

crypto map clientmap 10 ipsec-isakmp dynamic dynmap

!

interface Null0

no ip unreachables

!

interface Ethernet0

ip address 192.168.1.2 255.255.255.0

ip access-group 101 in

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

no cdp enable

hold-queue 32 in

!

interface Ethernet1

ip address 68.236.XXX.XXX 255.255.255.0

ip access-group 102 in

ip verify unicast reverse-path

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

ip route-cache flow

duplex auto

no cdp enable

crypto map clientmap

!

ip local pool vpnpool 192.168.1.50 192.168.1.99

ip classless

ip route 0.0.0.0 0.0.0.0 68.236.XXX.X permanent

!

no ip http server

ip nat inside source list 102 interface Ethernet1 overload

!

logging trap warnings

access-list 101 remark Secure Internal LAN class list.

access-list 101 deny ip 68.0.0.0 0.255.255.255 any log

access-list 101 deny ip host 255.255.255.255 any

access-list 101 deny ip 127.0.0.0 0.255.255.255 any

access-list 101 permit ip any any

access-list 102 remark Secure External WAN class list.

access-list 102 permit ahp any host 68.236.XXX.XXX

access-list 102 permit esp any host 68.236.XXX.XXX

access-list 102 permit udp any host 68.236.XXX.XXX eq isakmp

access-list 102 permit udp any host 68.236.XXX.XXX eq non500-isakmp

access-list 102 permit icmp any host 68.236.XXX.XXX echo-reply

access-list 102 permit icmp any host 68.236.XXX.XXX time-exceeded

access-list 102 permit icmp any host 68.236.XXX.XXX unreachable

access-list 102 permit tcp any any eq www

access-list 102 deny ip 10.0.0.0 0.255.255.255 any

access-list 102 deny ip 172.16.0.0 0.15.255.255 any

access-list 102 deny ip 127.0.0.0 0.255.255.255 any

access-list 102 deny ip host 255.255.255.255 any

access-list 102 deny ip host 0.0.0.0 any

access-list 102 permit ip any any

access-list 108 permit ip any any

no cdp run

!

line con 0

no modem enable

transport preferred all

transport output telnet

stopbits 1

line aux 0

transport preferred none

transport output none

line vty 0 4

length 0

transport preferred all

transport input telnet ssh

transport output telnet ssh

!

scheduler max-task-time 5000

scheduler interval 500

end

aacole · ‎07-22-2004

Looking at your config I would say that the problem is down to ACL 102 on the outside interface. You need to allow your pool addresses allocated to the VPN clients through the list as well.

The decrypted packets are passed via the ACL applied to the outside interface, so add in a line similar to: access-list 102 permit ip 192.168.1.0 0.0.0.255 any.

To test this is the case first you could (for testing purposes only!) use access-list 102 permit ip any any.

You also need to exclude the IP pool addresses from the NAT process as well outbound, I use a route map but I think you can also do it using a source list inthe NAT statement.

dgroscost · ‎07-22-2004

I'm not too familiar with route maps. Can you provide the syntax??

Thanks!

aacole · ‎07-23-2004

Ok,

Here is an example using your VPN pool:

ip local pool vpnpool 192.168.1.50 192.168.1.99

ip nat inside source route-map nonat interface Ethernet1 overload

ip access-list extended nonat

deny ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255

permit ip 192.168.1.0 0.0.0.255 any

route-map nonat permit 10

match ip address nonat

What this does is exclude traffic destined to the VPN pool client addresses from the NAT process. The networks are defined in ACL nonat.

If you dont exclude the traffic from NAT, inbound packets from the client are decrypted and reach the target server. Reply packets enter the router, get NAT'ed first, then miss the encryption process because the source address has changed to that defined in your NAT process.

There is another way to do this NAT exclusion, but I've never used it, so I'll stick with what I know.

The other problem with your inbound ACL is that encrypted packets need to be passed by that ACL so you have defined ESP and ISAKMP, but the decrypted packets are also passed via the ACL on the outside interface a second time around. So the addresses specified in the VPN pool also need to be allowed through the ACL. This is why I suggested using an ACL with IP any any as a test.

One final point, I always use a seperate address range for my VPN clients. Once I set up a PIX for IPSec VPN clients useing the same address space for the client as I had on the inside network. This caused me all sorts of problems, applying a unique address range to the client fixed all the connectivity issues. I've never tried using overlapping address space for both insode users and clients on a router, but with experience would expect the same issues to occur.

Andy

dgroscost · ‎07-23-2004

I changed the VPN pool of addresses to a different range of IPs. I added your changes and added the ip nat inside source map and everything appears to be working now. Thanks again for your help.

My only remaining concern is that we are allowing too much traffic in by using permit ip ANY ANY on the WAN interface ACL. We unfortunately use this router as a gateway for internet traffic as well to go out from the local LAN interface, so that has to work, and the only way I found to be able to get that traffic out was by using permit ip ANY ANY. I wasn't able to use the tcp any any eq www for example to allow web traffic to flow. Am I being too cautious??

Also, when using the ip local pool for VPN, is there a way to set an expire lease time on those addresses? I see after a few VPN sessions I'm already going up in the list of available IPs... what happens when we hit the limit? Will the previous sessions (IPs) get recycled?

Thanks again.

aacole · ‎07-23-2004

Excellent, sounds like some progress in the right direction.

N your not being too cautious, you need to apply that filter on the outside. In fact i would recommend running a firewall IOS if it Internet facing. Also it makes it easier to control outbound traffic and the corresponding replies to that traffic.

The inside ACL 101 needs to permit any inside source networks, this prevents your network being used as a spoofed address source.

eg access-list 101 permit ip 192.168.1.0 0.0.0.255 any

As for ACL 102, You need:

access-list 102 permit esp any

access-list 102 permit udp any eq isakmp

access-list 102 permit ip

access-list 102 permit entries as appropriate

The fist 3 lines allow ESP and ISAKMP for IPSEC, and the unencrypted VPN traffic from your clients.

If your having problems working out the rest of the entries you can add the line

access-list 102 deny ip any any log

This will print out a line on the console port (or vty with term mon enabled) every time a packet get denied by the acl, you can use this to work out what traffic you should allow in.

Andy