EM API problem with NAT environment

[grant11]

We seem to be having a problem getting a response back from CUCM and we suspect its a NAT issue. We are accessing CUCM from our PC with an IP of 20.1.20.103, this is a NAT IP and the CUCMs actual IP is 10.4.20.103. I can successfully browse to CUCM from the PC on ports 8443 and 8080 so NAT is working and configured correctly.

I run the following Query:

https://20.1.20.103:8443/emservice/EMServiceServlet?xml=<query><userDevicesQuery><userID>tom</userID></userDevicesQuery></query>

The response comes back as:

<?xml version="1.0"?>

<!DOCTYPE response SYSTEM "http://20.1.20.103:8080/emservice/jsp/LoginQueryResults.dtd"><response>

<failure>

<error code="1">XML Query Validation Error: Parser Error: Connection timed out</error>

</failure>

If I run the same query on a CUCM which does not have this NAT setup I get a response like this which is expected.

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<response>

<failure>

<error code="1">

XML Query Validation Error: Validation error: The content of element type "query" must match "(appInfo,(deviceUserQuery|userDevicesQuery|checkUser|deviceProfileQuery))".

</error>

</failure>

</response>

It seems like CUCM is forwarding the request to the NAT IP address internally instead of the actual IP address. Has anyone seen this problem before and is there a work around as this seems like a Call Manager Bug. I have tested using CUCM 9.1.2 and CUCM 10.0.1.10000-24

Thanks

[dstaudt]

Can you clarify exactly how the network topology is setup here.  From this:

We are accessing CUCM from our PC with an IP of 20.1.20.103, this is a NAT IP and the CUCMs actual IP is 10.4.20.103

and the URL request given (https://20.1.20.103:8443/emservice/EMServiceServlet?xml=) it seems like the application is trying to make a request to a UCM that is behind NAT..?  Or is the application/client behind NAT?  Why is the request sent to 20.1.20.103 if the UCM is actually at 10.4.20.103?  Is this a port-forwarding situation?

If you can get a network packet capture of the request/response sequence (e.g. via Fiddler) that may be helpful...

[grant11]

Hi dstaudt,

This has been picked up by the Cisco test team and has been assigned a JIRA case. I will try get the details and post here.

To answer your question the Call Manager is behind a firewall, I believe port forwarding has been enabled. I will see if I can get the logs via a webex and post them here.

I was hoping there was a quick answer from someone in the community who may have encountered this issue before but I think its a bit more complicated.

[grant11]

Here is the JIRA case number INFYAPPS-905