Showing results for 
Search instead for 
Did you mean: 

UC520 Site-to-Site VPN

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


Accepted Solutions

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?

View solution in original post


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.


Thanks for your answer - i have attached the running-config, figured that might be a lot easier.

I checked that all access-list was not only icmp, but ip


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.


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 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 trys to establish an RDP session to 192.168.10.X,

I noticed your ACL 104 is permiting RDP to the According to my assumptions, you are trying to establish this session to a destination address of 192.168.10.x, not 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.



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


Thanks alot for taking the time to help - i appreciate it alot.

Yes, every testing is being done from the client having as IP on the ASA-side

I tried to remove access-list 104 completely. Still the same symptoms (as in, cant access RDP to, 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 to, but not the other way around.


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


Thanks alot, i have attached the ASA config here


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 3389 netmask

Try removing this entry and try RDP again, let me know what happens



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 to say that is failing. It is basically everything from to 192.168.10.x, except from ICMP-packets


No prob, good to hear.


Also, one thing worth noting (perhaps), is that i can access the UC520 via SSH from - kinda weird, more and more looks like a problem with accessing clients behind the UC520


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


UC520 has an internal IP address of, which i can access via SSH from

The logs from ASA when doing this is:

6Jun 18 201022:49:36302013192.168.10.12210.10.0.7550092Built outbound TCP connection 46378447 for Outside: ( to Inside: (

Which matches the log entries i get when trying to RDP to or access HTTP on

6Jun 18 201022:50:56302013192.168.10.5338910.10.0.7550099Built outbound TCP connection 46378681 for Outside: ( to Inside: (

6Jun 18 201022:50:34302013192.168.10.118010.10.0.7550096Built outbound TCP connection 46378631 for Outside: ( to Inside: (