UC520 Site-to-Site VPN

[Simon Guldager Andersen]

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

[bjames]

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

[Simon Guldager Andersen]

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?

[Simon Guldager Andersen]

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

[bjames]

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

[Simon Guldager Andersen]

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?

[Simon Guldager Andersen]

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

[djh278778]

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.

[Simon Guldager Andersen]

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

[djh278778]

I am sure you have already, but have you removed any firewalls from the hosts themselves?

[Simon Guldager Andersen]

Yes, 192.168.10.11 is actually a printer with a webinterface - so no firewall here

[djh278778]

Did you say you could ping the .11, .12, and .31 from the host on the ASA side?

[Simon Guldager Andersen]

Yes, no problems pinging those

[bjames]

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

[Simon Guldager Andersen]

No, those are all gone now

[djh278778 · Accepted solution]

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?