Since its working fine when reloading the ASA, could be a defect with 8.2.1 code.
There is bug where duplicate asp table entries form for ipsec l2l tunnels causing the ASA not to encapsulate for particular tunnels.
Bug id is: CSCtb53186. Preferably get to latest interim for 8.2.1
But just to be sure it is this bug, does the vpn traffic work fine after reloading?Also in the show asp table vpn-context detail do you see duplicate entries for the remote subnet in the out direction?
I am kinda sure thats the bug since you say its a random subnet getting affected each time and only reloading solves the issue.
do a show asp table vpn-context detail | begin
Ideally for a single remote subnet you should see 1 incoming and 1 outgoing context each associated with the right SPI s formed for the ipsec sa. But in your case you should see an extra outgoing one for the remote subnet in question. In those two contexts see if you see any packets encrypted counter >0 for the right SPI ( SPI can be found from the show crypto ipsec sa peer ). If there are no packets for the right SPI, then it likely that the packets are getting hit in the wrong context( having different SPI). The fix for this issue is to go to 18.104.22.168.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
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...