One other thing - I had a problem with the key pairing so I rebuilt the rsa 1024 and the unit started working. Unfortunately I reloaded without the config in place and now I cannot get it to work again. Any help will be greatly apprecaited although I did review a dozen other posts of people having similar problems and for some reason there is never any conclusion as to the solution and I am not sure why.
Some other info from the client end:
I just ran the stats on the client and packets are being encrypted BUT none are decrypted.
Also Tunnel received 0 and sent 115119
Encryption is 168-bit 3-DES
Authentication is HMAC-SHA1
also even though the allow LAN is selected in the Cisco VPN client it states the local LAN is disabled in the client stats
also Transparent tunneling is selcted but in the stats it states it is inactive
Other people have had similar issues with accessing the internal network from the VPN. One solution was the split-tunnel, another was the natting and another had to do with the encrption where there and an issue with the encrypt and ecrypt which was stopping the communicaton via the VPN.
I still cannot seem to find the issue with this config and any help will be greatly appreciated.
I had this statement missing from the previous posted config but even with the nat (inside) 0 access-list no_nat_inside it still does not work.
nat (inside) 0 access-list no_nat_inside
route outside 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx 1
Have you applied the NAT0 ACL at any point? In the above configuration it is not applied to the ASA so its not used
You have this ACL
access-list no_nat_inside permit ip 192.168.40.0 255.255.255.0 192.168.40.0 255.255.255.0
To use it as a NAT0 ACL you would have to add
nat (inside) 0 access-list no_nat_inside
Naturally I would suggest changing the VPN Pool to something else than the internal network and changing the above NAT0 ACL to reflect that change
Did you change the VPN Pool used? This would mean changing the NAT0 ACL and Split Tunnel ACL too.
If you do those changes and they dont work after that could you then provide us with screenshots from the VPN Client computer from the Statistics section of the VPN Client software. Check for a tab that lists routes and also show us the tab with the data counters so we can see how the situation looks on the client side.
To be honest its been a long time since I have configured a PIX with the old 6.x series software so I am not sure if there is any VPN related configurations missing.
But I would start changing the VPN Pool to something else than the LAN network and testing connectivity through the VPN to the LAN with different services like ICMP. You could even install VNC server on some host and try to connect to it from the client computer.
I did try a different internal network and changed the no_nat and split_tunnel but it still did not work. Just to clean it up I will try it again today. Unfortunately I had it running yesterday but I thought for sure it had to do with the RSA private key pairing. When I rebuilt the RSA it worked. After a reset I was back to the same problem. I also noticed on these devices that when you do not have a good private key in place that the commands act very erratic. I also read on some posts that some people would enter CLI statements that make no sense at all but the unit starts operating properly afterwards. I have a few of these units I have been testing and a 6.3(4) version was giving a few errors (route, access-list and subnet mask, etc errors)when I pasted a known working config minus my VPN problem. After I rebuilt the RSA everything went back to normal so I am wondering if these units and their OS are a little unstable and if the commands must be entered and saved in a certain order ( aside from the access-lists) for the unit to operate properly. I will try a new config and post it later. I did find many posts concerning similar problems but no one listed a working config after they reported they solved the problem. Some people discuss crypto, isakmp nat-traversal, default routes, as the problem and since I was able to get it to work with a RSA rebuild I am wondering if it is a decryption issue. Thank you for responding.
If I have understood your problem correctly then you are able to connect with the VPN but you are not able to form connections to the LAN through that VPN connection. That is why I asked to see some screenshots so we could confirm if the Client is truly forwarding any traffic to the VPN to beging with and if its routing table is ok according to the VPN Client software.
If possible you can also check the output of this command on the PIX when the VPN Client connection is on and being tested
show crypto ipsec sa
It should show you if packets are flowing to both directions.
I just finished changing the config and I changed the following:
access-list OutToIn permit icmp any any
access-list OutToIn permit IP any any
access-list outbound permit icmp any any
access-list outbound permit IP any any
access-list split_tunnel permit ip 192.168.40.0 255.255.255.0 10.10.10.0 255.255.255.0
access-list no_nat_inside permit ip 192.168.40.0 255.255.255.0 10.10.10.0 255.255.255.0
ip local pool vpn_client_pool 10.10.10.1-10.10.10.10
Before I did this, with the pool the same as the network there was always traffic being encrypted via the client but no decrypts coming back. Now I only see a encrypt from the client maching when I try to ping another machine on the network or the PIX itself. So there are encrypts but no decrypts which is the same problem I had before - also the transparent tunneling is inactive and when I had this running before it was active with udp and some value.
I am going crazy with this config. Yesterday I had it running and I could ping computers on the network and the encrypts and decrypts counters were both increasing. I wish I would have stopped at that point but I was certain it had to do with rebuilding the RSA and I wanted to be able to confirm this. Thank you for responding.
You should probably keep the Transparent Tunneling enabled in the connection profile configured on the actual VPN Client software to avoid possible problems.
If you are seeing traffic flow to the VPN but not getting anything back then the problem might usually be NAT on the central device. In this case it doesnt seem to apply though. It could naturally be that the actual hosts just arent replying to the ICMP but even in this case you have pointed out that they have replied before.
One common problem related to ICMP is missing the ICMP Inspection or the Fixup ICMP in the case of your older software. I am not sure its a problem in the case of VPN but could always try
fixup protocol icmp
fixup protocol icmp error
I put in the fixup protocol icmp error (the other command did not work) and now the transparent tunneling is active on udp port 4500 which it was not before. But still no decrypts. I tried also isakmp nat-transversal and crypto for the same.I am worried that these device are a little screwy. I have the same config on another pix without DHCP and it works fine and yet when you copy the config to another it does not. Do you know if the PIX501 is a reliable device?
OK just double checked everything and on the client side - packets sent none received.
Packets are encrypted none decrypted.
When I try to ping the PIX or a PC on the network the packets sent and encrypted counter increases
When I try to ping from the PIX to the VPN_client that is attached, no packets received on the client and timeout on the PIX.
Another person said the problem was the default route. My external network has a route to the gateway 0.0.0.0 0.0.0.0 gateway
is it possible the external VPN IP_Pool is responding to this gateway and not the PC connected via the VPN?
This would explain what packets are sent and ecrypted by the client and yet nothing it received back.
Any thoughts? Once again thank you for your time.
I just ran the command you requested
show crypto ipsec sa
Cyprto map tag: vpn, local addr, My External/public IP address on the PIX external interface
PIX501 is a very very old Cisco firewall that has not been sold for a long time to my understanding. It also doesnt support even close to new software levels.
If you wanted to replace the PIX501 the corresponding model nowadays would be ASA5505 which is the smallest Cisco ASA firewall with 8 switch port module. There is already a new ASA5500-X Series (while ASA5505 is of the original ASA 5500 Series) but they have not yet introduced a replacing model for this model nor have they stopped selling this unit. I have a couple of them at home. Though naturally they are more expensive than your usual consumer firewalls.
But if you wanted to replace your PIX firewall then I would probably suggest ASA5505. Naturally you could get some other models too but the cost naturally rises even more. I am not sure at what price these are sold as used.
I used some PIX501 firewalls at the start of my career but have not used them in ages since ASA5505 is pretty much the firewall model we use when we need a firewall/vpn device for a smaller network/branch site.
Here is a PDF of the original ASA5500 Series.
Here is a PDF of the new ASA5500-X Series
I am afraid that its very hard for me atleast to troubleshoot this especially since I have not seen any outputs yet. Also the very old CLI and lack of GUI (?) make it harder to see what the problem is.
Could you provide the requested outputs?
From the PIX after connection test
show crypto ipsec sa
Screen captures of the VPN Client routing and statistics sections.
Received 0 Encryption 168-bit-3-DES
Sent 15268 Authrntication HMAC-SHA1
Encrypted 155 Transport Tunneling Active on UPD port 4500
Decrypted 0 Local Lan Disabled
Discarded 4 Compression: No
You should see more than that in the output.
You should see something like this
local ident (addr/mask/prot/port): (
remote ident (addr/mask/prot/port): (
And a lot more like counters of encapsulated/decapsulated and encrypted/decrypted packets.
If you dont see that I doubt it can work. But seems wierd to me that the VPN would even be connected if you didnt see anything in the output of that command.
I really want to thank you for taking your time to help.
I am not certain of the Crypto commands but I did look at some of the results and there does not appear to be anything going on. Based on the config can you see what may be missing?? The device works internally with no problem and you can connect externally but that is as far as you can go. Is there a different encryption method I can try to test with that you can recommend. Can I send the unit to you?? I am using it with one PC connected to the switch port which obtains IP from DHCP on the unit and I connect to the WAN port from my PC where I set the IP address to another public IP on the same subnet as the external address of the PIX. Then I also run a hyperterminal session on the serial port to make config changes and run some diags. I think I have tried this every way possible. Any thoughts on the ecryption and once again thank you for your time.
I vaguely remember having problems while labing some VPN Client setup when I was connected directly to the firewalls external connected network. I added a router in between the firewall and the client the connection worked just fine.
Is this PIX actually connected to the public network? If not then I would suggest trying to add some router/l3switch in between and connect the VPN Client PC to its own subnet and then try the connections again. If you have the PIX connected to public network then I would test the VPN from behind another Internet connection rather than from the directly connected public network.
I dont know if you sending the unit to me would really help the situation I don't work for Cisco and Cisco doesnt even offer any support for the PIX firewalls anymore (to my understanding atleast) since they are very old models.
If the PIX is connected to public network then I could always try to check the configurations remotely and test the VPN Client connection at the same time.
But as I said, if you are just testing this setup as a lab them I would suggest adding a router between the Client and PIX and testing again.
OK I got to work and thanks to you! The FIXUP Protocol ICMP error seems to have solved the problem however I still
need the following:
access-list outbound permit IP any any
and this is tied to the internal interface.
I am going to try to make it specific for the external network. Any thoughts? I read if you set up an access list outbound on the internal interface then the same is set for the external coming in - is this true?. If this is so, I am not worried about what people access from the inside going out, just want people can access from the Internet to hack the system coming in.
Just made a change to the access list:
access-list outbound permit IP any THE INTERNAL NETWORK 255.255.255.0
And it is still working. Any thoughts?
Thank you very much for the ICMP fixup. I tried the config that is working now before and without it, the VPN did not work. Now it is working perfectly.
You dont actually need an ACL on the "outside" interface in your situation so you could remove it to avoid any breach in security of the network. You would only need the ACL on the "outside" interface if you have some Static NAT or Static PAT configuration required to host an internal servers service/port. You dont seem to have any so you dont need that ACL. You can leave the "inside" interface ACL.
The reason why you dont need an ACL on the "outside" interface is the fact that traffic coming from a VPN Connection is handled differently.
You have this setting on your PIX
sysopt connection permit-ipsec
This setting essentially enables all traffic coming from VPN to bypass the interfacel ACL of the interface that is terminating the VPN Connection. So in your case the "outside" interface. As I said, this setting only applies to traffic coming through a secure VPN Connection and nothing else.
I am not sure if the "fixup" command solved the case. It wouldnt seem likely but I am not sure. The main thing ofcourse is that connections work. Again if needed I can check the PIX configurations remotely and test the VPN Client if you run into problems.
Hope this helps
Please do remember to mark a reply as the correct answer if it has answered your question and/or rate helpfull answers.
Feel free to ask more question if needed though.
I tried the sysopt connection permit-ipsec and removed the access-list statement and it did not work.
Then I inserted the access-list back and things went back to normal. Is this something to be concerned with?
Please let me know. Thank you
Please provide the current configuration.
Please also provide the exact configurations you changed related to the above situation.
Although the sysopt connection permit-ipsec did not work and the access-list statement did after a power cycle I discovered the the sysopt statement must be working -even though the access-list was active there were no hits on the hit counter when accessing the internal network. Before the sysopt comman every ping resulted in an increment in the hit counter on the access-list to allow the .40 network in on the outside interface. All is working well and the only thing that was changed was the fixup for the icmp. Another thing I noticed was the transparent tunneling -some times it is active and other times it is not. Can you let me know the advantage of having it running and also was the syntax is to enable it via the cli. Thank you for all of your help I really appreciate it. Take care.