Attendant Console Behind NAT

[dnelson]

I have an attendant console user that is running on a pc behind a natted firewall. The CCM box is on the outside of the firewall. The attendant console can log and take calls, transfer calls etc.. . All seems to work except the line appearance state only shows a question mark (?). If I move the attendant console pc to the outside of the firewall then the line status infor works correctly.

What is needed to pass line status through a firewall?

Please help.

[kthorngr]

The Line State is supplied over UDP. If the UDP port is not spcified the port is selected at random. The UDP port can be specified on the client PC using the using Advanced Settings Dialog. You can specify a free UDP port as "IP Address:UDP port" in the "Local Host IP Address (for line state)" field: under Advanced Tab of Attendant Settings Dialog Box.

For example: 128.108.170.222:1239

Allow this UDP port in your PIX.

HTH,

Kevin

[dnelson]

I tried to do a one to one static nat assignment. I statically assigned the ip address of attendant pc to a public address. I didn't specify tcp or udp but an entire ip address one for one. I don't have any accesslists or filters blocking incoming traffic to the public address that is natted to the attendant's pc.

Still no line status.

Any other ideas? Have you tried this successfully?

Thanks for you help

[jdiegmueller]

I currently have TAC case F206015 open regarding this same issue. The technical answer is "this is not supported", however, I am in the process of filing a PERs in order to help my customer out.

Working theory I have is that the registration process (where the AC client tells the LSS server where to send the updates to) is within the payload, and thus is not NATd. So the LSS server sends LSSs to the non-NATed (and hence, unreachable) address.

I have a theory that you could do this, but have yet to test it: create an aliased host address with the same IP that you have the static 1:1: NAT for, netmask /32. Manually bind AC Client's LSS to that IP address. This will succeed since that IP actually exists on the local machine. Then when the AC client registers with the LSS, the packets will end up going to the outside (NAT'd) address, then get NAT'd in.

The only catch here is if the AC Client is bound specifically to that feigned IP; when the packet arrives it is destined for the normal address (per the NAT rue) and not the spoofed /32, so this may or may not work. It's just a theory at this point.