I think You are unable to initiate the VPN tunnel from ASA/PIX interface, and after the tunnel establishment, the remote end/VPN Client is unable to ping the inside interface of ASA/PIX on the VPN tunnel. For example, the vpn client can be unable to initiate a SSH or HTTP connection to ASA's inside interface over VPN tunnel.
The inside interface of the PIX cannot be pinged from the other end of the tunnel unless the management-access command is configured in the global configuration mode.
You will want to enable logging on the IPSec VPN client to see why the session is being disconnected. You will also want to debug ISAKMP and IPSec on the ASA. I run into this problem frequently with customers where DPD is enabled but the local firewall policy on the client is dropping the packets.
No I have not resolved this problem yet. I log into an ssh session on the server and run TOP to keep the activity going, which keeps the connection up. When I disconnect the ssh session the connection dies within a few minutes.
Can you confirm tat the client is actually connecting via IPSEC/NAT-T or if its just negotiating a straight IPSEC connection?
On the vpn client turn on all the logging at the HIGH level and then fire up a vpn connection. You'll see in the connection logs whether your client negotiates IPSEC/NAT-T or just IPSEC by the line "Automatic NAT detection status" in the client logs.
If the client negotiates IPSEC only try this little test. Run the client, then fire up a ping to some server within the tunnel for about 5 mins. Kill the ping and see if the keepalive start coming back in the client side log. I'd assume that the keepalives will not come back and your client will start sending alot of keepalive but nothing coming back from VPN endpoint.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...