1. Home
  2. Cisco Systems
  3. Why can't I connect or ping my boxes after having connected to a Cisco VPN server.

Why can't I connect or ping my boxes after having connected to a Cisco VPN server.

Hello, experts.

I have a home office with following networking equipment.

  1. a DSL modem (Internal IP 192.168.0.0)
  2. a Wireless Router AP (Internal IP 192.168.3.0)
  3. a laptop connected via a wireless card (static ip: 192.168.3.3)
  4. subnet mask : 255.255.255.0 Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Belkin 802.11g Wireless Card Physical Address. . . . . . . . . : 00-22-90-10-F7-88 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Autoconfiguration IP Address. . . : 192.168.3.3 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 192.168.3.1

if I am connected to my company cisco VPN, my laptop is assigned

  1. IP 10.0.0.100 (dynamic)
  2. DNS 10.0.0.1
  3. subnet mask: 255.255.0.0 VPN server allows local LAN connection. Connection-specific DNS Suffix . : mycompany.com Description . . . . . . . . . . . : Cisco Systems VPN Adapter Physical Address. . . . . . . . . : 00-30-303-3C-93-01 Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 10.0.0.100 Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 10.0.0.100 DNS Servers . . . . . . . . . . . : 10.0.0.1 Primary WINS Server . . . . . . . : 10.0.0.1

While being connected to the Cisco VPN concentrator server, I would not be able to manage or ping any of my networked resources (servers, dsl modem , wireless AP). As soon as I disconnect from the VPN connection, i can do everything (ping, rdp, access my dsl modem, AP).

I used to be able to do this with a different DSL modem provided by a different provider. I moved to a new location and have a different ISP with different DSL modem.

Is it the routing issue? Thanks.

Reply to
BSDUX
Loading thread data ...

Enable NAT-T on the device you are connecting to.

Reply to
Chad Mahoney

What leads you to this strange advice?

My initial diagnosis is that this is expected behavior since his VPN concentrator has disabled split-tunnelling. While connected into the company network, direct access to the local network is blocked and all traffic is routed up the encrypted tunnel.

This policy is configurable on the concentrator end. Cisco's VPN client software respects the concentrator's configuration in this regard.

Changing the IPSEC encapsulation from Cisco's proprietary UDP port 10000 to NAT-T won't change this behavior. And it isn't a client side choice in any case. The concentrator gets to choose whether NAT-T is supported. The client gets a somewhat less robust way to choose -- use an old enough client and UDP 10000 gets used because NAT-T doesn't exist.

Out of the box the Cisco client normally has NAT-T turned on by default.

Note that my assumption that this behavior is due to split tunnelling policy does not explain why it used to work. I don't think it should ever have worked. Though possibly a split tunnelling network list (configured on the concentrator side) that included 192.168.1 but not

192.168.3 would fit the symptoms.
Reply to
briggs

Actually re-reading your post you are correct NAT-T would not cause the problem:

I would ask what local IP is the concentrator seeing come in? Is it the

192.168.1.x network or the 192.168.3.X network? I would check to see if you are excluding the 192.168.3.0 network from NAT. In the config it would be the NAT (inside) 0 access-list some-acl

the ACL some-acl probaly says something like permit 192.168.1.0

255.255.255.0 10.0.0.0 255.255.255.0

you would want to include this in that ACL

access-list some-acl permit IP 192.168.3.0 255.255.255.0 10.0.0.0

255.255.255.0

Sorry for the brain malfunction :(

Reply to
Chad Mahoney

Actually that does not make sense either. That would be for a site to site VPN not a client VPN. Is the 10.0.0.0 IP pool new or was it existing? I am done for the week before I really brake something :).

Reply to
Chad Mahoney

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.