Solved

Cisco ASA seeing return traffic as spoofed

Posted on 2013-11-06
6
584 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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
Are You Headed to Black Hat USA 2017?

Getting ready for Black Hat next week? Kick things off with the WatchGuard Badge Challenge and test your puzzle and cipher skills. Do you have what it takes to earn our limited edition Firebox Badge? Get started today - https://crimsonthorn.net

 
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

Connect further...control easier

With the ATEN CE624, you can now enjoy a high-quality visual experience powered by HDBaseT technology and the convenience of a single Cat6 cable to transmit uncompressed video with zero latency and multi-streaming for dual-view applications where remote access is required.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

How to set-up an On Demand, IPSec, Site to SIte, VPN from a Draytek Vigor Router to a Cyberoam UTM Appliance. A concise guide to the settings required on both devices
When speed and performance are vital to revenue, companies must have complete confidence in their cloud environment.
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses

627 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