CUPS over VPN (PPTP)

[loganseth]

Versions

UCM 6.1.2.1002-1

Presence 7.0.2.10000-36

CUPS client 7.0(1.13056)

Windows 2003 VPN (PPTP/GRE)

The CUPS client works wonderfully on LAN/WAN, but when using VPN, it logs in and shows status, but LOGON SERVER and LDAP SERVER show unavailable.

When try to start a chat, says 'An Instant Message could not be started because the network appears to be disconnected.'

Interestingly, Presence phone (UPC[username]) and TFTP are green.

Routing works and more, so, the LDAP server is in the same L2 network as the VPN server's interface.

I read through several posts regarding this issue, including:

- validate profile is set to Cisco SIP Proxy TCP Listener (this was under App --> CUPS --> Settings for v7)

- validating our FW does not do SIP inspection (though moot, since our FW isn't the terminating point for the VPN tunnel, so it's all encapsulated through the tunnel)

- acknowledge the known bug/caveat (CSCsf26033) in the CUPSr7 release notes which says to use TCP for the profile.

I even used Wireshark to validate the frames were TCP and the servers are talking and they appear to be!?

Yet, RED for both those servers.

I'm stuck and could use some suggestions.

(Love this site, by the way)

Thanks, all.

Logan

[htluo]

At this point, I think you'd better open a TAC case. You'll need the TAC engineer engage CUPC dev team to find out the workflow.

[Johann Aicher]

I'm also wondering about the DNS lookups for:

Name: _sip._udp.CUPS....

Name: _sip._tcp.CUPS....

Name: _stun._udp.CUPS....

I also see this behaviour in my lab and there is no information in the Cisco docu about correct DNS entries for CUPS / CUPC!

If you use "ipconfig /flushdns" then you get an empty DNS cache. This is allways good before capture packtes.

We had the same error with CUPC over Checkpoint VPN! Since I opened all ports without Firewalling to CUPS it runs and all are happy!

[loganseth]

Nice recommendation on the DNS flush...yea, man, what is that call!?

From several posts it sounds like FW tweaking is necessary, but I've struggled with that solution since our endpoint is a Windows device that sits behind a FW, so the VPN client traffic is tunneled through the FW - so how would the FW inspect it?

ARGH!

In all sincerity, I really appreciate this conversation and everyone's assistance. It is refreshing to be in the company of other I.T. folks who are interested in solving problems and supportive. I look forward to 'paying it forward.'

[Johann Aicher]

Have you ever tried DRTCP021.exe to reduce the MTU size of your Test-PCs eth interface - for example to 1400 or 1300 Bytes ?

This has resolved some of the GRE / PPTP / IPSec VPN / DSL issues I had before.

It depends on your VPN tunnel device how it handles larger packets than it can transport ( cut or devide or drop ).

[loganseth]

woah...DrTcp? Man, that's a new one to me...I'm testing on WWAN card from Verizon, so I will try and run it to reduce the MTU size on that interface...

Do you have any more information to the theory behind this change? What is the default MTU size? What adjust?

[Johann Aicher]

The default MTU of Eternet is 1500. So if you have any tunnel to pass the tunnel devices has to handle that to big packets. Because any tunnel has one or more headers ( GRE / PPTP / IPSec / SSL .. ), the packets have to be handled correct. One bad thing is when a device cuts the packet and drops the rest of it. It depends also on the IP protocol ( UDP or TCP ) and the implementation of the IP-stack on the machines.

I had allways a good result with an MTU of 1400 bytes.

[loganseth]

Nice!

Ok, I just tried it, left all the 'general settings' alone, changed the 'Adapter Settings' for the WWAN interface to 1300 MTU (that was the drtcp default), rebooted, re-connected and received the same result.

Do you think I missed a step or should I have adjusted anything else in the drtcp app?

[Johann Aicher]

Sorry, I've been looking into your "ldap_bind_working_2.cap". On frame 23 in the options field your client uses only 1260 Bytes. So this cannont be the problem.

You can take a capture at the internal side of your VPN tunnel device and compare the results.

Cisco says that they are having problems with NAT inside the communication between CUPS and CUPC.

[mike]

Hello.  I was just following through this link, and have a similar problem/resolution that might shed some light on these problems.

I was working with a customer with CUPS 7.0.5, CUPC 7.0.2.  Within they're network, CUPC will connect and work fine.  Once we vpn we can authenticate, but the client would show conneted(Limited) and the Presence server health would show connecting/disconnecting/pending etc.

I did a packet capture on my PC with CUPC loaded, not on the VPN connection, but on the interface that was providing the transport for the VPN connection, IE the LAN Interface, not the PPTP interface.

What showed in capture was several DNS lookups to my LAN dns server, rather than the PPTP provided dns server.  The lookups were for _sip._udp.cups.domain.name, and _sip.tcp.cups.domain.name, and _stun.udp.domain.name.

My local dns was responding with no such name, since my local isp would not have the cups server domain name, and this was is a private ip address, not a public address.

This points to a problem with the CUPC client requesting the DNS information from the LAN, not the PPTP interface.  All ping requests/web requests for the cups.domain.name worke fine, and can resolve the cups address from the name as expected.

As a test, I setup a temporary dns server, added the remote customers domain as a zone, with the private ip address/hostname for the cups server, and used this for my LAN interfaces DNS server.  Now when vpn'd in, the CUPC client will connect and work just fine.

I don't think this is a good solution in any means, but it does show that the CUPC client is the issue.

Any Tips/Tricks that the Author of "Deploying Cisco Unified Presence" can add?  I got a well used copy that I've gone through in troubleshooting, and know the writter lurks in these forums....