Solved

Cisco ASA seeing return traffic as spoofed

Posted on 2013-11-06
6
571 Views
Last Modified: 2013-11-13
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
Comment
Question by:ITGeneral
  • 3
  • 3
6 Comments
 
LVL 9

Expert Comment

by:neilpage99
ID: 39629057
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
 
LVL 9

Accepted Solution

by:
neilpage99 earned 500 total points
ID: 39629062
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
 

Author Comment

by:ITGeneral
ID: 39631208
Would not having "Reverse Route Enabled" selected cause this?

CryptoMap
0
Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

 
LVL 9

Expert Comment

by:neilpage99
ID: 39631630
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
 

Author Comment

by:ITGeneral
ID: 39644742
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
 

Author Closing Comment

by:ITGeneral
ID: 39644748
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

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Secure VPN Connection terminated locally by the Client.  Reason 442: Failed to enable Virtual Adapter. If you receive this error on Windows 8 or Windows 8.1 while trying to connect with the Cisco VPN Client then the solution is a simple registry f…
Hi All,  Recently I have installed and configured a Sonicwall NS220 in the network as a firewall and Internet access gateway. All was working fine until users started reporting that they cannot use the Cisco VPN client to connect to the customer'…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now