• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 589
  • Last Modified:

Cisco ASA seeing return traffic as spoofed

I have an ASA 5510 running 8.3 code. A 3rd party vendor that manages some servers in our network via a VPN connection is trying to get 2 of these servers setup on WSUS through the VPN tunnel. I've ensured that HTTP and HTTPS as well and SSH services are open on the Firewall page on the Outside Interface.

I seem to be able to telnet to port 80 to the server on the far side of the tunnel without issue but when it comes to 443 traffic it looks like the traffic is somehow being blocked. As you can see in the screen shot below it looks like the Firewall is having an issue with the return traffic - it seems to think that it is being spoofed and is therefore dropping it. Any ideas on how I can correct this?

Packet Trace from WSUS server on other side of VPN to local server
RealTime Log Viewer
0
ITGeneral
Asked:
ITGeneral
  • 3
  • 3
1 Solution
 
neilpage99Commented:
Verify your crypto access lists on BOTH sides of the VPN tunnel, and be sure that the source and destination networks are considered "interesting" (i.e. encrypted) on both sides. This error could actually be caused by traffic on one side or the other arriving/sending in clear text rather than IPSEC encrypted.
0
 
neilpage99Commented:
Also, check both sides for what is called a "split return" path; meaning that when packets egress from point 'A' to point 'B' - they somehow return to point 'A' from a different source other than point 'B'.

Static routes, default route, and network IP's that are left out of an important access-list can cause symptoms like these.
0
 
ITGeneralAuthor Commented:
Would not having "Reverse Route Enabled" selected cause this?

CryptoMap
0
Managing Security Policy in a Changing Environment

The enterprise network environment is evolving rapidly as companies extend their physical data centers to embrace cloud computing and software-defined networking. This new reality means that the challenge of managing the security policy is much more dynamic and complex.

 
neilpage99Commented:
My first hunch would be "no" - Reverse Route Injection would not seem necessary for a successful IPSEC tunnel. Since it is an easy test, try using it and see if the problem improves, my guess is no.

When a tunnel is created properly, all participating sides share an identical crypto map (apart from the peer address naturally), access-lists and Phase attributes. I've setup hundreds of tunnels and I have made a few common mistakes in the past that resulted in symptoms similar to yours. In all cases, it was a mismatched tunnel attribute(s) on one side. Either the access-lists didn't mirror each other, or some other attribute didn't match.

Can turn up logging, then reproduce the problem several times - then provide the log output (scrubbed) ?  -maybe something there will narrow down the troubleshooting.

Try the "Reverse Route" first - and if there is no improvement, move on to my suggestions above.
0
 
ITGeneralAuthor Commented:
So I finally got this resolved - the problem was the VPN traffic was still being routed through our Ironport so it was stopping all of the HTTPS traffic - I didn't believe that was how it was configured but once I was able to get a trace on the traffic I could see it being shipped to that device first. Once I added that network as an exception on the Ironport everything started working as it should.

Thanks for the suggestions/help.
0
 
ITGeneralAuthor Commented:
Not really any fault of yours I left out the part about having an Ironport so there was no way you could have known. You did mention split return path and you were sorta right on that - only it involved an Ironport vs some kind of routing issue (though technically I guess you could say it was a routing issue). Anyway figured it was worth the points.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now