Cisco → [HELP] Help with Cisco VPN Client 3.6.1 and home network.

Help,
I am currently using a Cicso 831 for my home network.

I also have a laptop from work that has Cisco VPN Client 3.6.1 installed.

My ISP is Cablevision.

When I attempt to connect from the VPN software, I get a message that the package cannot connect to the server.

Cablevision told me that they do not block any of "those" VPN ports. The Tech guys from work are telling me that it's my network setup.

What do I need to do, in order to make the VPN software (3.6.1) work through my Cisco 831?

Thanks,
Jim

PS - Here's my Cisco 831 configuration:

Using 2869 out of 131072 bytes
!
! Last configuration change at 12:09:15 EST Fri Feb 13 2004 by Router
! NVRAM config last updated at 12:14:44 EST Fri Feb 13 2004 by Router
!
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname Router
!
no logging buffered
enable secret 5 $1$swn8$MIJInjz0Y/n5fSUOCH.N4.
!
username CRWS_Kannan privilege 15 password 7 074B700879581F24531D5A03370F3B257D6366754551475751
username CRWS_dheeraj privilege 15 password 7 03400A4F315E276D0A06480A24371B0D537C7A757B63627444
username Router password 7 135D45415E5900
clock timezone EST 5
clock summer-time EDT recurring
ip subnet-zero
ip name-server 167.206.3.245
ip name-server 167.206.3.246
ip dhcp excluded-address 10.10.10.1
!
ip dhcp pool CLIENT
import all
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
lease 0 2
!
ip inspect name myfw cuseeme timeout 3600
ip inspect name myfw ftp timeout 3600
ip inspect name myfw rcmd timeout 3600
ip inspect name myfw realaudio timeout 3600
ip inspect name myfw smtp timeout 3600
ip inspect name myfw tftp timeout 30
ip inspect name myfw udp timeout 15
ip inspect name myfw tcp timeout 3600
ip inspect name myfw h323 timeout 3600
ip audit notify log
ip audit po max-events 100
!
!
!
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
ip nat inside
no cdp enable
hold-queue 32 in
hold-queue 100 out
!
interface Ethernet1
ip address dhcp client-id Ethernet1
ip access-group 111 in
ip nat outside
ip inspect myfw out
no cdp enable
!
ip nat inside source list 102 interface Ethernet1 overload
ip classless
ip http server
!
!
access-list 23 permit 10.10.10.0 0.0.0.255
access-list 102 permit ip 10.10.10.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any traceroute
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq bootps any eq bootpc
access-list 111 permit udp any eq bootps any eq bootps
access-list 111 permit udp any eq domain any
access-list 111 permit esp any any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq 10000
access-list 111 permit tcp any any eq 1723
access-list 111 deny tcp any any eq 139
access-list 111 deny udp any any eq netbios-ns
access-list 111 deny udp any any eq netbios-dgm
access-list 111 deny udp any any eq netbios-ss
access-list 111 permit gre any any
access-list 111 deny ip any any
!
line con 0
exec-timeout 120 0
no modem enable
stopbits 1
line aux 0
stopbits 1
line vty 0 4
access-class 23 in
exec-timeout 120 0
login local
length 0
!
scheduler max-task-time 5000
sntp server 17.254.0.26
end

No crypto, no VPN.

You don't have anything configured to do encryption, so your VPN client has nothing to attatch to..

Read this:

»www.cisco.com/en/US/tech ··· db.shtml

Ok,
When I use my work laptop from my home office and try to connect to my office (via the 831 through Cablevision...), I cannot connect to the Company's private network (via cicso vpn client 3.6.1) The tech support at work told me there is something wrong with my ISP.

Do I need to open up some external ports on the 831? If so, which ones?

Thanks,
Jim

I think the problem you are having is that your router is using NAT (which it has to). It might also be your access list. Try removing access-list 111 and your firewall and see if that helps.

Just as a test plug your computer into the cable coming out of your cable modem (the one that is currently connected into your 831). If your vpn client work then it is your router for sure.

I was thinking the best solution for you would be to configure your router as a VPN client, but I'm finding there are a lot of restrictions with doing that. I'm not sure how the server you are connecting into is configured so here is a web site with list of restrictions »www.cisco.com/en/US/prod ··· #1015337. You might talk to your IT guys and see if the server's config will allow a connection to your router using the easy vpn remote feature. If their willing to work with you, you could also manually configure the VPN connection on your router (you would need some info from them). If they are then let us know and we can help you with a manual VPN config.

Bill

It also depends on the type on encryption being used

"IPSec can work from behind a firewall provided you
don't use AH and use ESP with some restrictions. The
reason is that IPSec does a checksum of the packet in
AH and some modes of ESP. NAT changes the packet and
so the checkdum does not match. So you need to use a
mode of ESP that only encrypts the data within the
packet and doesn't do any checksum on packet headers.

NAT After IPSec
===============
You may consider applying NAT after IPSec encryption
for address hiding. However, this provides no benefit
because the actual IP addresses of the devices
utilizing the tunnel for transport are hidden via the
encryption. Only the public IP addresses of the IPSec
peers are visible, and address hiding of these
addresses provides no real additional security. NAT
application after IPSec encapsulation will occur in
cases where IP address conservation is taking place.
This is, in fact, commonplace in hotels, cable/digital
subscriber line (DSL) residential deployments, and
enterprise networks. In these cases, depending on the
type of NAT used, its application may interfere with
the IPSec tunnel establishment.

When IPSec uses Authentication-Header (AH) mode for
packet integrity, if one-to-one address translation
occurs it will invalidate the signature checksum.
Because the signature checksum is partially derived
based on the AH packet's IP header contents, when the
IP header changes, the signature checksum is
invalidated. In this case, the packet will appear to
have been modified in transit and will promptly be
discarded when received by the remote peer. However,
when IPSec uses ESP, the devices will be able to
successfully send packets over the VPN, even when
one-to-one address translation occurs after
encapsulation. This scenario is possible because ESP
does not use the IP header contents to validate the
integrity of the packets. In cases where many-to-one
address translation occurs (aka port address
translation), the IP address and source IKE port,
normally User Datagram Protocol (UDP) port 500, will
change. Some VPN devices do not support IKE requests
sourced on ports other than UDP 500, and some devices
performing many-to-one NAT do not handle ESP or AH
correctly. Remember that ESP and AH are higher-layer
protocols on top of IP that do not use ports.

Because many-to-one address translation is commonplace
in many environments where remote-access clients are
deployed, a special mechanism called NAT transparency
exists to overcome these NAT issues. NAT transparency
reencapsulates the IKE and ESP packets into another
transport layer protocol, such as UDP or TCP, which
address-translating devices know how to translate
correctly. This mechanism also allows the client to
bypass access control in the network that allows TCP
or UDP but blocks encrypted traffic. Note that this
feature does not affect the security of the transport
in any way. NAT transparency takes packets already
secured by IPSec and then encapsulates them again in
TCP or UDP.

Guys this is what IPSEC transparent tunneling is for.

Find out if what your connecting to has the ability to transparent tunnel the IPSEC stream into either a tcp or udp wrapper.