10-17-2012 12:06 PM
Have an issue with return traffic from an ips managment interface across a vpn tunnel. Phase 1 and Phase 2 works fine
but the return traffic does not get back to the ASA (IPS gateway). The IPS 4260 (v 7.08) was even plugged directly into the ASA
but still no return traffic (#pkts encaps: 0)
#pkts decaps: increments as expected (testing with icmp) so I know the request is getting there.
I believe the rules are properly set up as #pkts encaps: increments when testing to a switch ( IP address moved over from IPS).
Ran debugs on the ASA but did not see anything.
IPS has the simple config with allowed ACLs 0.0.0.0/32
Is there something that the IPS is doing or a combination thereof with the ASA to not reply?
Thanks,
Pete
Solved! Go to Solution.
10-17-2012 02:30 PM
Hello,
It should be:
0.0.0.0/0
Regards,
Julio
10-17-2012 02:25 PM
Can someone verify whether an IPS 4260 ACL written as 0.0.0.0/32 actually means allow all ?
or should it be wriiten as 0.0.0.0/0
Thanks,
Pete
10-17-2012 02:30 PM
Hello,
It should be:
0.0.0.0/0
Regards,
Julio
10-22-2012 09:30 AM
That was correct Julio. Now I see the (#pkts encaps:) increment. But the echo-replys do not reach the intended source on the other tunnel end. I assume if the traffic is getting encrypted back across then it is the other end issue ..
I also did not see the # of hits on the ACL for the no NAT for the VPN increase at all. I would expected this to increment if traffic is making it to the crypto map to be encrypted. Why would the ACL hit # not show the echo-reply ?
10-22-2012 09:35 AM
Hi,
What if you run a packet-tracer?
Do you see anything in the logs after testing the VPN communication?
Thanks.
Portu.
Message was edited by: Javier Portuguez
10-22-2012 10:01 AM
Glad to hear that one worked
Please share the configuration so we can analize it,
Remember to rate all of the helpful post, that is as important as a thanks
10-25-2012 12:12 PM
With the ICMP tests, I could not get the data I wanted. Replied came back across the ASA to be encrypted but couldn't see beyond that. So I had to test using tcp to generate the 3way shake.
Getting error Drop-reason: (tcp-not-sync) First TCP packet not SYN
I will have to figure this out and come back with specifics. Sorry I do not control both endpoints.
Closing this one out. Thanks for your help.
10-25-2012 12:26 PM
It sounds like asymmetric routing issues.
Please keep this setting handy just in case:
ASA 8.2.X TCP State Bypass Feature Configuration Example
HTH.
Portu.
Please rate any helpful posts
Message was edited by: Javier Portuguez
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: