Cisco 2800 Router w/ VPN connection, but no VPN traffic

[cooljoe04]

I am trying to get a basic understanding of the process of how the routers works so that I can try and troubleshoot things myself as I add more configuration to the system. Currently I am at a very basic level of understanding and have gotten internet access through the router and appear to have achieved an active VPN connection between this router and my endpoint which is a Netgear VPN router, as both diagnostics show that the VPN connection is active, but the traffic counters are at 0. I am not able to get any traffic to talk across the network though and believe it to be as a result of the NAT or lack of an ACL blocking the traffic, but I may be way off. If I can get this working, I would like to dive into adding VLANs to this unit for a couple different networks and inter-routing them as well, in case that would change anyone's answer to my problem. Any help would be appreciated. I feel like it is something easy that I am overlooking. My config is as follows:

Building configuration...

Current configuration : 1765 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname "HOSTNAME HERE"
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
ip cef
!
!
no ip dhcp use vrf connected
!
!
no ip ips deny-action ips-interface
ip name-server "ISP PRIMARY DNS IP"
ip name-server "ISP SECONDARY DNS IP"
!
no ftp-server write-enable
!
!
!
!
!
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key ABCD123456 address "PEER STATIC IP HERE"
!
crypto ipsec transform-set esp-3des-md5 esp-3des esp-md5-hmac
!
!
crypto map shop 20 ipsec-isakmp
 set peer "PEER STATIC IP HERE"
 set transform-set esp-3des-md5
 match address 100
!
!
!
interface FastEthernet0/0
 description LAN Interface
 ip address 192.168.27.1 255.255.255.0
 ip nat inside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 no cdp enable
!
interface FastEthernet0/1
 description WAN Interface
 ip address "WAN IP HERE" 255.255.255.248
 ip nat outside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 no cdp enable
 crypto map shop
!
ip default-gateway "GATEWAY IP HERE"
ip classless
ip route 0.0.0.0 0.0.0.0 "GATEWAY IP HERE"
!
no ip http server
no ip http secure-server
ip nat pool internet "WAN IP(s) HERE" prefix-length 30
ip nat inside source list 1 pool internet overload
!
ip access-list extended inside
!
access-list 1 permit 192.168.27.0 0.0.0.255
access-list 100 permit ip 192.168.27.0 0.0.0.255 192.168.1.0 0.0.0.255
no cdp run
!
!
control-plane
!
!
line con 0
 password password1
 login
line aux 0
 password password1
 login
line vty 0 4
 password password1
 login
!
end

[Roberto Kippins]

HI try using an extended acl for your nat configurations and set it so that it looks something like this:

ip access-list extend nat

deny ip 192.168.27.0 0.0.0.255 192.168.1.0 0.0.0.255

permit ip 192.168.27.0 0.0.0.255 any

then your nat statement

ip nat inside source list nat pool internet overload

Also ensure that your encryption parameters match on both ends, something else I notice on some routers when you use the same encryption parameters for both phase 1 and 2 the vpn does not work, so for example you can try using aes in your policy and keep 3des in the transform set or you can switch it the other way round but you would need to make this change on both endpoints.

Another thing, this will not affect your vpn but good to know, since your router is doing routing the ip default-gateway configuration is not needed, you usually use that command on layer 2 switches or if you want the router to act as a pc.

[cooljoe04]

Roberto,

Thank you for the suggestions. I have added the ACL and changed the VPN encryption so the transform set doesn't match but am still not able to get a ping across the VPN. I am getting an active VPN connection according to the Netgear router at the endpoint and according to the Cisco. I have posted the config below. If I run a traceroute from the cisco to ping the remote LAN, it is routing the VPN-bound traffic to the ISP gateway and not sending it over the tunnel. Is there something I missed/misunderstood on your suggestions? I also took out the default-gateway line to keep things as clean as possible.

Thanks again.

Joey

sho run
Building configuration...

Current configuration : 1896 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname "HOSTNAME"
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
ip cef
!
!
no ip dhcp use vrf connected
!
!
no ip ips deny-action ips-interface
ip name-server 208.38.252.3
ip name-server 184.170.172.131
!
no ftp-server write-enable
!
!
!
!
!
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
crypto isakmp key ABCD123456 address "ENDPOINT WAN IP"
!
!
crypto ipsec transform-set esp-3des-md5 esp-3des esp-md5-hmac
!
!
crypto map shop 20 ipsec-isakmp
 set peer "ENDPOINT WAN IP"
 set transform-set esp-3des-md5
 match address 100
!
!
!
interface FastEthernet0/0
 description LAN Interface
 ip address 192.168.27.1 255.255.255.0
 ip nat inside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 no cdp enable
!
interface FastEthernet0/1
 description WAN Interface
 ip address "LOCAL WAN IP" 255.255.255.248
 ip nat outside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 no cdp enable
 crypto map shop
!
ip classless
ip route 0.0.0.0 0.0.0.0 "ISP GATEWAY"
!
no ip http server
no ip http secure-server
ip nat pool internet "LOCAL WAN IP(S)" prefix-length 30
ip nat inside source list 1 pool internet overload
ip nat inside source list nat pool internet overload
!
ip access-list extended inside
ip access-list extended nat
 deny   ip 192.168.27.0 0.0.0.255 192.168.1.0 0.0.0.255
 permit ip 192.168.27.0 0.0.0.255 any
!
access-list 1 permit 192.168.27.0 0.0.0.255
access-list 100 permit ip 192.168.27.0 0.0.0.255 192.168.1.0 0.0.0.255
no cdp run
!
!
control-plane
!
!
line con 0
 password password1
 login
line aux 0
 password password1
 login
line vty 0 4
 password password1
 login
!
end

[Robert Falconer]

The previous poster was correct in using the extended ACL for NAT.

Try removing 'ip nat inside source list 1 pool internet overload'

What seems to be happening is your traffic sourced at 192.168.27.0 is hitting the NAT statement, which is still referencing ACL 1. ACL 1 is permitting 192.168.27.0 to go through the NAT process and be sent to the ISP. Because the destination is a private address, your ISP will drop it.

If only the ACL 'nat' is used for the NAT process, then it will deny traffic destined to the remote-side private network.

If you add any other remote vpn networks in the future, you will need to add the deny statement for those as well.

[cooljoe04]

I tried to take out the two extra lines to see what would happen, but had no luck. I also tried changing around some of the VPN settings to see if it would make any difference since the Netgear endpoint isn't quite as particular as it needs to be (reports that it is connected when not everything matches from time to time), but that didn't seem to make a difference either. I took out one of the access-lists as it didn't appear like it was being referenced anywhere either, and it had no effect on VPN or internet access.

I really appreciate the help and hope that we can figure out what I am missing!

Here is the updated config:

sho run
Building configuration...

Current configuration : 1780 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname L0stN00b
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
ip cef
!
!
no ip dhcp use vrf connected
!
!
no ip ips deny-action ips-interface
ip name-server "ISP DNS SERVER 1"
ip name-server "ISP DNS SERVER 2"
!
no ftp-server write-enable
!
!
!
!
!
!
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key ABCD123456 address "REMOTE VPN IP"
!
!
crypto ipsec transform-set esp-3des-md5 esp-3des esp-md5-hmac
!
!
crypto map shop 20 ipsec-isakmp
 set peer "REMOTE VPN IP"
 set transform-set esp-3des-md5
 match address 100
!
!
!
interface FastEthernet0/0
 description LAN Interface
 ip address 192.168.27.1 255.255.255.0
 ip nat inside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 no cdp enable
!
interface FastEthernet0/1
 description WAN Interface
 ip address "LOCAL WAN IP" 255.255.255.248
 ip nat outside
 ip nat enable
 ip virtual-reassembly
 duplex auto
 speed auto
 no cdp enable
 crypto map shop
!
ip classless
ip route 0.0.0.0 0.0.0.0 "ISP GATEWAY IP"
!
no ip http server
no ip http secure-server
ip nat pool internet "LOCAL WAN IP(S)" prefix-length 30
ip nat inside source list nat pool internet overload
!
ip access-list extended nat
 deny   ip 192.168.27.0 0.0.0.255 192.168.1.0 0.0.0.255
 permit ip 192.168.27.0 0.0.0.255 any
!
access-list 100 permit ip 192.168.27.0 0.0.0.255 192.168.1.0 0.0.0.255
no cdp run
!
!
control-plane
!
!
line con 0
 password password1
 login
line aux 0
 password password1
 login
line vty 0 4
 password password1
 login
!
end

[Nick Cutting]

Please post the output of 

sh crypto isakmp sa 

sh crypto session

sh crypto ipsec sa

If you are missing encaps, and phase one is up, then you know its either your ACL, or your NAT config.

[cooljoe04]

Outputs of show statements requested:

L0stN00b#sh crypto isakmp sa
dst                 src             state          conn-id slot status
"REMOTE WAN IP"  "LOCAL WAN IP"  QM_IDLE              5    0 ACTIVE

L0stN00b#sh crypto session
Crypto session current status

Interface: FastEthernet0/1
Session status: UP-ACTIVE     
Peer: "REMOTE WAN IP" port 500
  IKE SA: local "LOCAL WAN IP"/500 remote "REMOTE WAN IP"/500 Active
  IPSEC FLOW: permit ip 192.168.27.0/255.255.255.0 192.168.1.0/255.255.255.0
        Active SAs: 2, origin: crypto map

L0stN00b#sh crypto session ipsec sa

interface: FastEthernet0/1
    Crypto map tag: shop, local addr "LOCAL WAN IP"

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.27.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer "REMOTE WAN IP" port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 115, #pkts encrypt: 115, #pkts digest: 115
    #pkts decaps: 112, #pkts decrypt: 112, #pkts verify: 112
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: "LOCAL WAN IP", remote crypto endpt.: "REMOTE WAN IP"
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x4770604(74909188)

     inbound esp sas:
      spi: 0x280DA6EC(671983340)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 3002, flow_id: FPGA:2, crypto map: shop
        sa timing: remaining key lifetime (k/sec): (4562851/2815)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x4770604(74909188)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 3001, flow_id: FPGA:1, crypto map: shop
        sa timing: remaining key lifetime (k/sec): (4562848/2814)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
L0stN00b#

[Nick Cutting]

L0stN00b#sh crypto session ipsec sa

interface: FastEthernet0/1
    Crypto map tag: shop, local addr "LOCAL WAN IP"

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.27.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer "REMOTE WAN IP" port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 115, #pkts encrypt: 115, #pkts digest: 115
    #pkts decaps: 112, #pkts decrypt: 112, #pkts verify: 112

This looks healthy to me.  Can you ping devices behind the cisco and the netgear? i.e Laptop on 192.168.27.x to laptop on 192.168.1.x

Does each device behind the routers have default gateways pointing at the respective routers?  it could be time for a diagram

[cooljoe04]

Computer A --wired to-->Router A<<>>VPN<<>>Router B--wired to-->Computer B

Router A @ 192.168.1.1 can ping Router B @ 192.168.27.1

Router B @ 192.168.27.1 cannot ping Router A @ 192.168.1.1

Router A @ 192.168.1.1 cannot ping Computer B @ 192.168.27.10

Router B @ 192.168.27.1 cannot ping Computer A @ 192.168.1.114

Computer A @ 192.168.1.114 can ping Router B @ 192.168.27.1

Computer B @ 192.168.27.10 can ping Router A @ 192.168.1.1

Computer A @ 192.168.1.114 cannot ping Computer B @ 192.168.27.10

Computer B @ 192.168.27.10 cannot ping Computer A @ 192.168.1.114

Router A @ 192.168.1.1 can ping Computer A @ 192.168.1.114

Router B @ 192.168.27.1 can ping Computer B @ 192.168.27.10

(just to show that PCs are not blocking pings)

[Nick Cutting]

Make sure you source the ping from the inside interface. By default it will use the outgoing interface, which is most like the WAN interface.  This traffic will not go over the tunnel.

E.g. if router A is the cisco, trying pinging the remote PC using the lan interface.

ping 192.168.27.10 source fa0/0

[cooljoe04]

In the example/tests above, Router A was the Netgear. Router B was the Cisco. Sorry I forgot to add that.

The computer's are not able to ping each other through the network, so something is still blocking it, even if I were to source where the router was pinging from.

[Nick Cutting]

Try telnetting to port 445 if they are windows laptops, from laptop to laptop in both directions.  Could be host firewalls just blocking icmp, as some of your traffic flows look to be working.  I do not think its a VPN setup issue.

[cooljoe04]

From either router, I can ping the PC on that local network though, just not from the remote network, which should mean that there are no firewalls enabled on the PCs. Correct?

From either router, I cannot ping the PC on the other network (even with the addition of the source fa0/0 to the command). I can (with the source option added) ping the Netgear from the Cisco (Router B will ping Router A) now which I did not have before.

If I run a traceroute from the Cisco to try to ping the computer connected to the netgear, the route is still trying to go out to the gateway.

I will try the Telnet 445 in a bit when I get back and report the results, but I don't see how it would work if it is still trying to source the traffic to the gateway. Am I missing something in the process of its communication?

[Nick Cutting]

Pings often work asymmetrically, while tcp often wont if there is a security device in the way so I suggested the telnet to rule that out.  However that is the opposite of what may work here - as your pings are failing.  

Are you able to post the routing tables with the sensitive information removed? Both the cisco and the netgear (screenshots perhaps). 

Also perhaps check the host routing tables also - just in case there is some strange entries.

open a cmd window and grab a

route print -4

what is the model of netgear?

[cooljoe04]

As an update to the function of the VPN, I can now ping as follows:

Netgear (192.168.1.1) to Cisco (192.168.27.1) YES

Netgear (192.168.1.1) to Laptop on Cisco (192.168.27.10) NO

Cisco (192.168.27.1) to Netgear (192.168.1.1) NO

Cisco (192.168.27.1) to Desktop on Netgear (192.168.1.114) NO

To me, the fact that I can ping Lan to Lan at all would indicate that the VPN settings are correct and that the VPN is up and running. The fact that I can't ping the LAN devices on the cisco sounds like an inbound ACL problem, and the fact I can't ping anything on the Netgear side from the Cisco side sounds like it is still trying to route everything to the gateway through the NAT and not via the tunnel (an outbound ACL problem). Am I thinking about this correctly? Are these presumptions correct?