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.

 

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

 

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.

 

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

 

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 .