06-17-2010 03:14 PM - edited 03-21-2019 02:41 AM
Hi All
I have this very weird problem (at least for me)
I have a UC520 connected to an ASA5510 via Site-to-Site VPN.
I can ping from clients behind UC520 to client behind ASA5510.
I can ping from clients behind ASA5510 to client behind UC520
I can access services (like RDP) from clients behind UC520 to client behind ASA5510
I can't access services (like RDP, HTTP) from clients behind ASA5510 to client behind UC520
Does anyone have a clue where i need to look? I tried to rule out all access list by (temporarily) making a permit ip any any line in these.
I think it must be some kind of NAT issue, but im not sure.
Thanks in advance
Solved! Go to Solution.
06-18-2010 02:56 PM
You said your UC logs showed nothing when trying to connect to .11 and .12, this means the traffic either never got to the UC at all, got to the UC and was dropped before entering the LAN, or the traffic got to the hosts but was never returned.
Do the internal hosts have other outbound routes defined on them (doubtful but possible), and can you verify the traffic is through the UC outside interface at least?
06-17-2010 04:02 PM
It's hard to say without looking at the configs but the first things I would look at is the ACL for the policy. This should be under "Crypto-map" > "match address". This ACL determines which traffic is to be encrypted and placed into the tunnel. Since you can already ping from the ASA to the UC it must be built but make sure the ACL's are permitting IP (all protocolls) and not just ICMP in the proper source-to-destination direction. You may have a problem with the ACL defined on the "nat0" as well (make sure it is permiting IP like above). When you ruled out the ACL's for the firewalls, did you place the permit any any at the top of the ACL. And did you do this on all filters (inbound to ASA and outbound of ASA...inbound to UC and outbound of UC)? If not the filters may still be killing the traffic.
06-17-2010 04:23 PM
06-17-2010 04:36 PM
It sounds like the problem may be on the ASA side not necessarily the UC side. At quick glance everything looked good to me for the UC config.
06-18-2010 10:03 AM
I was taking another look at your config and there are a few possibilities. First of all I hope that all of your tests from the ASA side to the UC are from the 10.10.0.75 host because that is the only host defined in the ACL 199 for the policy. So assuming that is indeed how you are testing, here is my assumed scenario:
Host 10.10.0.75 trys to establish an RDP session to 192.168.10.X,
I noticed your ACL 104 is permiting RDP to the 87.63.xxx.70. According to my assumptions, you are trying to establish this session to a destination address of 192.168.10.x, not 87.63.xxx.70. So the this destination value would have to change on the protocols that you want to get THROUGH the router not TO the router.
It could be too that these protocols are not even being filtered seperately by ACL 104 because their within the tunnel thats already being allowed through and maybe there is an issue on the ASA side.
I would start by isolating ACL 104 by removing it completely from the interface and see where you stand.
06-18-2010 12:48 PM
Simon,
What are the logs on the ASA telling you?
I assume you have a NAT exception for the subnet inside the ASA going to the subnet inside the UC?
If you still cannot get it post a cleaned ASA config and I can take a look.
Bob James
06-18-2010 12:48 PM
Thanks alot for taking the time to help - i appreciate it alot.
Yes, every testing is being done from the client having 10.10.0.75 as IP on the ASA-side
I tried to remove access-list 104 completely. Still the same symptoms (as in, cant access RDP to 192.168.10.5, but i can ping it)
The lines allowing RDP to 87.xxxx is leftovers from older configuration without VPN
Do you think we need to have a look at things on the ASA-side ? The reason for me thinking that this should be a UC500-issue is, that i can easily access RDP from say 192.168.10.5 to 10.10.0.75, but not the other way around.
06-18-2010 12:52 PM
Need ASA config to see for sure
Make sure on the ASA side the crypto map addressing matches the UC exactly;
example: access-list inside_nat0_outbound extended permit ip host 10.10.0.75 192.168.10.0 255.255.255.0
06-18-2010 01:06 PM
06-18-2010 01:18 PM
I take a harder look in a couple of minutes, but a quick glance shows me you are also using the IP as a static PAT on the outside interface:
static (Inside,Outside) tcp 77.66.XX.XX 3389 10.10.0.75 3389 netmask 255.255.255.255
Try removing this entry and try RDP again, let me know what happens
Bob
06-18-2010 01:30 PM
Hi Bob
I tried to remove the static PAT (both for 3389 aswell as ftp), however no luck.
Just to be clear, it is not only RDP from 10.10.0.75 to say 192.168.10.5 that is failing. It is basically everything from 10.10.0.75 to 192.168.10.x, except from ICMP-packets
06-18-2010 03:46 PM
No prob, good to hear.
06-18-2010 01:35 PM
Also, one thing worth noting (perhaps), is that i can access the UC520 via SSH from 10.10.0.75 - kinda weird, more and more looks like a problem with accessing clients behind the UC520
06-18-2010 01:46 PM
What IP can you access on the UC via SSH?
Is there anything showing up in the log files?
I will look at the configs more in a little while
06-18-2010 01:51 PM
UC520 has an internal IP address of 192.168.10.1, which i can access via SSH from 10.10.0.75
The logs from ASA when doing this is:
6 | Jun 18 2010 | 22:49:36 | 302013 | 192.168.10.1 | 22 | 10.10.0.75 | 50092 | Built outbound TCP connection 46378447 for Outside:192.168.10.1/22 (192.168.10.1/22) to Inside:10.10.0.75/50092 (10.10.0.75/50092) |
Which matches the log entries i get when trying to RDP to 192.168.10.5 or access HTTP on 192.168.10.11:
6 | Jun 18 2010 | 22:50:56 | 302013 | 192.168.10.5 | 3389 | 10.10.0.75 | 50099 | Built outbound TCP connection 46378681 for Outside:192.168.10.5/3389 (192.168.10.5/3389) to Inside:10.10.0.75/50099 (10.10.0.75/50099) |
6 | Jun 18 2010 | 22:50:34 | 302013 | 192.168.10.11 | 80 | 10.10.0.75 | 50096 | Built outbound TCP connection 46378631 for Outside:192.168.10.11/80 (192.168.10.11/80) to Inside:10.10.0.75/50096 (10.10.0.75/50096) |
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide