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 01:55 PM
Can you http to 192.168.10.5?
I would also recommend adding logging to the inside ACL's of the UC so you can see what it's doing.
You can test the packet size theory by increasing your ICMP packet sizes to see where it kaks
06-18-2010 02:02 PM
Yes, i actually can.. This is getting more and more weird
The HTTP-service responds with a small error-page (as intended, i'm not accessing a page that exists). I can't access HTTP-service on 192.168.10.11 though
Could it be some kind of packet-size related problem?
06-18-2010 02:06 PM
Hmm, nevermind my packet-size speculations. Tried to access a page that actually exists (plenty of graphics) - worked without any problems.
Can't access HTTPS to 192.168.10.5 though
06-18-2010 02:09 PM
The packet size one I have had before the MTU should be set lower on the inside to accomodate the
overhead of IPSEC 1430 or something. Anyway I think the only way to know for sure what is happening is to
get logs off the UC that's why I suggested adding a deny any any log on the inside ACL's
Bob
06-18-2010 02:21 PM
I just added a 5 permit ip any any log to the access-list 101 (for inside interface) - here is what i get when accessing
HTTP on 192.168.10.5:
000743: Jun 18 21:18:14.463: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.10.5(0) -> 10.10.0.75(0), 1 packet
Here is what i get when accessing HTTPS or RDP on 192.168.10.5: (Which doesnt work)
000765: Jun 18 21:20:24.831: %SEC-6-IPACCESSLOGP: list 101 permitted tcp 192.168.10.5(0) -> 10.10.0.75(0), 1 packet
However, the logs show nothing when i try to access 192.168.10.11 (or .31 and .12) via HTTP.
Any clue?
06-18-2010 02:34 PM
Nothing shows up when adding 5 deny ip any any log and then trying to access 192.168.10.11 via HTTP
This is showing up when doing RDP to 192.168.10.5:
000947: Jun 18 21:36:27.907: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.10.5(0) -> 10.10.0.75(0), 1 packet
As well as HTTPS to 192.168.10.5:
000954: Jun 18 21:37:02.923: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.10.5(0) -> 10.10.0.75(0), 1 packet
But nothing with HTTP 192.168.10.11 or 192.168.10.31
06-18-2010 02:38 PM
Take a look at your " ip nat inside source static" statements. There are entries for the .5 and so on that may be nating the source addresses to the address of your public interface. Remove them and give it a try.
06-18-2010 02:44 PM
Thanks, clearing all ip nat entries except this one:
ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0/0 overload
Made everything to 192.168.10.5 work.
However, i still can't access 192.168.10.11, .12, .31 through HTTP
06-18-2010 02:26 PM
I am sure you have already, but have you removed any firewalls from the hosts themselves?
06-18-2010 02:28 PM
Yes, 192.168.10.11 is actually a printer with a webinterface - so no firewall here
06-18-2010 02:47 PM
Did you say you could ping the .11, .12, and .31 from the host on the ASA side?
06-18-2010 02:50 PM
Yes, no problems pinging those
06-18-2010 02:57 PM
Do you still have the statics for 10.10.0.75 defined on the ASA?
static (Inside,Outside) tcp 77.66.XX.XX www 10.10.0.75 www netmask 255.255.255.255
06-18-2010 02:59 PM
No, those are all gone now
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?
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