Pix blocks Microsoft Office Communicator
Cisco, Firewalls, Forensics, Incident response, Instant Messaging, Intrusion management, Network security, VPN, Wireless
We are running Cisco VPN (3000 headend) clients (4.7.0) through a Cisco Pix 515 (6.3).
Our VPN clients are unable to connect to Windows Live Commnications Server 2005 using Windows Office Communicator. The communication is set for TCP (not TLS).
Looking at the PIX logs we see that the initial SIP message (Pre-Allocate) is permitted but then the client seems to send an acknowledgement before establishing the session. The PIX drops this because this packet is out of state.
Some references seem to hint that using TLS will solve this. It appears that the Microsoft client is not following protocol standards or am I missing something?
P.S. We tested that LCS does work through the VPN without a firewall.
Software/Hardware used:
Software/Hardware used:
ASKED:
November 4, 2005 12:31 PM
UPDATED:
January 8, 2006 10:17 AM
Answer Wiki:
It sounds like it could possibly be a PAT issue on the client end. This is a longshot but could it be that the clients are sitting behind a PAT (PAT not NAT) device and the expected port number for return traffic has been changed by a PAT device?
When you check the Syslog messages on the PIX are the dropped packets being dropped due to an ACL match or is the session just not setting up?
Chris Weber
Layer9corp.com
P.S I would put a sniffer in front of the server and the client and examine the communication setup.
To see all answers submitted to the Answer Wiki: View Answer History.
You can try enabling “any” to connect to your LCS server (from the IP range which your VPN clients are coming in from) to verify that its not a routing issue (in case its an LCS issue). Then if if does work correctly start re-locking down which routes are allowed to connect to that device.
Its a hard one to trouble shoot with such limited info about your PIX (you could have a 3 page list of access lists for nodes and protocols…)
Are you using the PIX IOS 6.3.4 or have you moved to 7?
We avoided 7 because of initial major problems (although they have patched it up quite a bit since its release, we are still holding off for a while).
Layer9 – the session is just not setting up (get a deny on unexpected ACKs)
We are using 6.3.4 since 7 is not supported on the smaller PIX systems and we don’t want to support two different code bases across the enterprise.
This is definitely not a client problem since we work through the VPN with no PIX just fine but die when using a VPN that passes through a PIX (the PIX reside toward the interior of the network not within the VPN tunnel).
We will try TLS soon – let you know if this resolves things (since I suspect TLS will require a bonafide session to be established).
I am not familiar with Live Communication Server but if it is using TCP why is the ACK unexpected? I am just curious. Are they arriving out of sequence? If so what data do you have to support that fact? ACKs as you know are normal in TCP communications. If TLS helps it would seem the Live Server application would be the culprit. TLS uses encryption and uses a record protocol that encrypts data and a handshake protocol for setup that sits on TCP. I am not sure how that would help unless the Live Server relies on it for correctly timed authentication in which case you of course should add it in the application.
I don?t suspect MTU issues as other encrypted data is getting through the PIX. Beside these ACKS are small and it would not happen just to the ACKs.
One area I would look at is the relative time on these ACKs with regards to the initial handshake. If they are arriving out of sequence then the timestamps will reflect this. If so, we need to understand why they arrive out of sequence.
At this point all I can do is speculate. This is an advanced issue obviously or you would have solved it by now and Protocol Analysis is not something that can be done or in a few posts. If I could see the PIX configuration like a Write Terminal and maybe some packet captures taken simultaneously in front of the Live Server and also in front of the client system I would be better informed at least, and could offer better insight.
If you want to send me a sanitized copy of the PIX config along with some packet captures I will be happy to take a look.
One other thing you can try is placing your Concentrator lateral to the PIX.
Chris Weber
Layer9corp.com
Sorry for being unclear – the client software (Microsoft Office Communicator) sends an ACK without sending a SYN (handshake) first. There is an initial prenotification for SIP that the PIX detects however.
I know this from watching the PIX logs.
I suspect that using TLS will require the formal three way handshake first.
Thanks for everyone’s help.
We enabled TLS (installed a digital certificate on the LCS server and on each client) and now the messages work through the PIX firewall just fine.
TLS provides for authentication and encyption of each session so we desire this protocol rather than the standard TCP option. Martyman also found that you can disable the SIP fixup protocol to support LCS, but we prefer to force a TLS deployment since it gives us a security position we prefer. Microsoft has based much of their forward security architecture on digital certificates and we gladly embrace this.