Link to home
Create AccountLog in
Avatar of bodineperry
bodineperry

asked on

Cisco 79XX phones unable to see XML data over a SonicWALL VPN

Hi everyone,

I'm having a bit of a hard time with my new SonicWALL TZ 100 that I installed at our corporate office.  We use Cisco 7940 and 7960 SIP phones at all of our offices.  The phones connect to our main PBX (trixbox) at the corporate office via IPSEC site-to-site VPNs.  All calls are getting through and working properly, but ever since the SonicWALL installation, all phones at remote locations are no longer able to properly view the phone directory.  The phone directory is located at http://192.168.1.xxx/directory.  Phones on the local network are able to view the XML directory just fine, but the remote phones are getting a "BTXML error - XML Parse Error."  The remote phones are also no longer receiving the corporate logo on their screens upon bootup, which is located at http://192.168.1.xxx/cisco/logo.bmp.

This worked just fine with our previous router, which was a Linksys RV082.  I've been experimenting with several SonicWALL settings, created allow-all policies, and even disabled IDS temporarily to no avail.  I've read that sometimes phones would get this error if they were sitting behind a NAT and connecting to the WAN port of the PBX, and that designating the phone as DMZ would resolve it, but since we're on a VPN with all traffic allowed both ways, I can't see why the ports are not communicating properly.  

If I repeatedly try to display the directory several times, I will sometimes get the initial page of the directory, but going any further from there invariably gives me another BTXML error.

Any ideas?  Am I missing something, or is this kind of network behavior between SonicWALL and Cisco's phones a common occurrence?  Any light shed on this would be greatly appreciated!

UPDATE:  Inspecting the access_log and error_log on the trixbox shows no activity whatsoever when a BTXML error is displayed on the phones.  When I do make it through for a successful connection, access_log shows this:

192.168.25.xxx - - [10/Aug/2011:22:50:02 -0400] "GET /directory/PhoneUI/index.php?name=SEPXXXXXXXXXXXX HTTP/1.1" 200 4763 "-" "Allegro-Software-WebClient/3.10b1"

Open in new window

Avatar of digitap
digitap
Flag of United States of America image

What have you seen on the sonicwall logs when you try to access the directories? If you aren't getting enough logging information then increase your log feedback by:

Log > Categories and click the check box at the top of each column to select all the check boxes. Then, make sure the logging level is set to debug, which it is by default.

Then, go back to log and access the directory.
Avatar of bodineperry
bodineperry

ASKER

Weird.  Though I'm trying to access the directory over and over again, it's like pulling teeth to see anything in the log.  After about 20 or so attempts, I finally got a log entry on the Sonicwall:

	08/10/2011 20:29:29.464	Debug	Network	TCP packet received on non-existent/closed connection; TCP packet dropped	192.168.25.xxx, 4553, X1	192.168.1.xxx, 80, X0	TCP Flag(s): ACK

Open in new window

And here's an RST from the PBX:

08/10/2011 20:32:07.352	Debug	Network	TCP connection abort received; TCP connection dropped	192.168.1.xxx, 80, X0	192.168.25.xxx, 4557, X1

Open in new window

Hmmm, makes me thing the TCP timeout needs to be increased. Let's try this, increase the TCP timeout on the firewall rule for VPN > LAN. Go to Firewall > Access Rules and edit the matrix VAN > LAN. Select the Source as the VPN and click the Edit link at the far right. Click the Advanced tab and change the TCP timeout to something like 60 minutes.

Then, try again. If you have further issues, change the TCP timeout LAN > VAN also.
Made sense, but still a no-go.  
Curious. If you go to Network > Zones, what security services are enabled on the VPN zone?
None.  That's what's got me scratching my head.  It's as if *something* is blocking these requests, but I can't find any evidence.  
Have you updated the firmware on the TZ100 yet?
Yes.  SonicOS Enhanced 5.6.0.11-61o
Load the 5.8 early release. By the way, early release doesn't mean beta. I've seen that version resolve issues before. If you have issues still with 5.8, then load 5.8.1.

Makes sure you get a settings backup before hand. Go to System > Settings and export the settings.
Well, it was a valiant effort, but the issue persists.  I just inspected the logs and applied filters.  When filtering the source as the phone, I got absolutely no entries.  When filtering it with the source as the PBX, I got a few RSTs and other such dropped packet notices.  Those only seemed to occur, though, when I made successful connections to the webserver.
do you think it might be safe to say that the traffic isn't being sent at all? another thought, what subnets are defined in your vpn policy?
I'm beginning to think that that is a very good possibility.  Cisco phones have shown me very odd behavior in the past, and they seem to dislike many common network setups.  Go figure - prominent network manufacturer not supporting the norms - another reason I'll never buy Cisco again.

The subnets defined in the VPN policies include the local network to the router: 192.168.1.0/24.  The remote subnets are as follows:  192.168.10.0/24, 192.168.25.0/24, 192.168.0.0/24, and 10.1.1.0/24.
Does the directory have any integration with Active Directory?
I downloaded it and browsed through the code, but I haven't messed with this stuff in a while. I'm not going to be much help there. Can you confirm for me what is configured for VoIP settings on the Sonicwall? Go to VoIP > Settings. What's checked?

I'm at a loss. It appears the Sonicwall is dropping SOME traffic but uncertain why we're not seeing more traffic appearing dropped. You could perform a packet monitor from the sonicwall to see what IS coming over. Perhaps a clue there will tell us what's going on.

System > Packet Monitor > Configure. Configure a monitor filter for the source IP of the whatever device is trying to access the directory at the time. Then, click OK and go back to the monitor and enable it. You have to manually refresh to see results.
I have no options selected in the VoIP -> Settings section.  

I did perform some packet monitoring last night on the Sonicwall and came up empty-handed.  Received the same as I saw in the logs - nothing until a connection was actually established, then just RSTs.  I think I'm going to Wireshark the phone itself when I get back to the remote network and see what is happening from there.  

I appreciate your help and will keep you posted with my findings.
Sure. On the sonicwall, please check to enable both the SIP and H.323 settings.
ASKER CERTIFIED SOLUTION
Avatar of bodineperry
bodineperry

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Only marking my fix as a partial solution because admins shouldn't have to roll back to versions of firmware published in 2005 to make their browsing functions work!
good to know. glad you got it!