I have a PIX515 between me IntraLAN and the Internet. VPN access is configured (crypto map and isakmp with a pre shared key) for remote access to the IntraLAN. My WinXP laptop has some IPsec policy's set and the remote access works fine.. accept, before my laptop can reach hostA on the LAN hostA on the LAN must send a ping to the laptop to get the traffic going. (very inconvenient as you might imagine.)
Once hostA triggers the vpn, the Laptop can make every connection to hostA. Communicating from the laptop to hostB fails until hostB sends a ping (I have not tried other types of packets) through the tunnel.
The PIX forgets the triggered tunnel after some time. During this time a VPN disconnect and reconnect does not require the trigger ping.
To make sure that we understand your scenario... you are not connecting to the PIX with the Cisco VPN client, but with the Microsoft IPSEC client? If with the VPN client, you should not have to generate a ping any ip traffic destined to your internal lan should count as a "trigger" for the phase 2 SAs to come up after you have established the IKE negotiation with the VPN client.
If you are using the microsoft client we will not be able to shed any lights without looking at your configuration and IPSEC debugs from your PIX.
I'm not connecting using the Cisco VPN client. And Im not quite sure what you mean with the Microsoft Client. Im using the IPsec support built in Windows XP Professional. (Using Linux with Freeswan shows the exact same problem). Phase 2 SA after IKE negotiation is not the problem, works perfectly, but getting the packets flowing requires a, as I call it, trigger from the LAN to the remote. NAT is not the issue here. After the trigger from the LAN to the remote everything works fine. Everything is in me first message and Ill be happy to share my PIX config with you:
PIX Version 6.1(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dialin security40
nameif ethernet3 ent security30
enable password ***** encrypted
passwd ***** encrypted
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
access-list outside2pix permit tcp any host 18.104.22.168 eq smtp
access-list outside2pix deny ip any any
access-list dialin2pix permit ip 172.17.64.0 255.255.240.0 any
access-list dialin2pix permit icmp any any
access-list dialin2pix deny ip any any
access-list ent2pix permit ip any host 172.17.1.2
access-list ent2pix permit ip host 22.214.171.124 host 172.17.1.0
access-list ent2pix permit ip host 126.96.36.199 host 172.17.1.1
access-list ent2pix permit icmp any any
access-list ent2pix deny ip any any
access-list inside2pix permit ip 172.17.0.0 255.255.252.0 host 188.8.131.52
access-list inside2pix permit ip 172.17.0.0 255.255.252.0 host 184.108.40.206
access-list inside2pix permit ip 172.17.0.0 255.255.252.0 host 220.127.116.11
access-list inside2pix permit udp host 172.17.1.20 any eq domain
access-list inside2pix permit tcp host 172.17.1.20 any eq domain
access-list inside2pix permit tcp host 172.17.1.20 any eq ftp
access-list inside2pix permit tcp host 172.17.1.20 any eq www
access-list inside2pix permit tcp host 172.17.1.20 any eq 443
access-list inside2pix permit udp host 172.17.1.20 any eq ntp
access-list inside2pix permit tcp host 172.17.98.2 any eq smtp
access-list inside2pix permit tcp host 172.17.98.2 any eq ftp
access-list inside2pix permit tcp host 172.17.98.2 any eq www
access-list inside2pix permit tcp 172.17.0.0 255.255.252.0 any eq telnet
access-list inside2pix permit tcp host 172.17.1.29 any eq lpd
access-list inside2pix permit tcp host 172.17.1.44 any eq lpd
access-list inside2pix permit esp host 172.17.0.2 any
access-list inside2pix permit ip host 172.17.2.51 any
access-list inside2pix permit udp host 172.17.1.23 any eq bootps
access-list inside2pix permit icmp any any
access-list inside2pix deny ip any any
access-list wtunnel permit ip host 18.104.22.168 192.168.100.0 255.255.255.0
This sounds like an issue with dynamic translations in the PIX. I notice you're not assigning addresses to the remote client from an address pool, and that you have a "nat (inside) 0" command for your 172.17.0-3 subnets. Ordinarily one would disable NAT for VPN traffic by using the "nat 0 access-list" command and specify the client pool as the destination in the access-list. One side effect of this version of the "nat" command is that it bypasses the need for static translations for incoming traffic, but the regular "nat 0" command doesn't have this feature. This is an important feature because dynamic translations are only created for outbound traffic, not inbound, which I think matches the symptoms of your problem.
So, I suspect that if you created an access-list like "access-list NO_NAT permit ip 172.17.0.0 255.255.252.0 any" and changed your existing "nat (inside) 0" command to be something like "nat (inside) 0 access-list NO_NAT" then that will fix your problem.
ddawson replied a few days ago. This reply solved my dark problem (thanks again ddawson!) but I forgot to login before rating the post. I missed the opportunity to put a red checkmark. So, please consider this converstion as solved and next time I'll login before rating the posts..
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :