Is sip fixup needed if the remote extension is connecting via VPN? Also should the extension still use nat=yes if it is connecting via VPN? I'm having some connectivity issues and am wondering if this could be the issue.
Thanks
 
Cisco Pix sip fixup
Submitted by necits on Wed, 04/15/2009 - 11:38am.
fixup must be off, nat must
Wed, 04/15/2009 - 1:41pm
fixup must be off, nat must be off.
If you have an outside ip defined in sip_nat.conf then you need to set up a localnet statement for each remote vpn subnet.
--
Scott
aka "Skyking"
 
Thanks Scott,
Quote:
If you
Wed, 04/15/2009 - 2:27pm
Thanks Scott,
Quote:
If you have an outside ip defined in sip_nat.conf then you need to set up a localnet statement for each remote vpn subnet.
Yup, I've done that and I Have nat set to no. I haven't turned off the sip fixup yet.
I should problably elaborate on the issue a little more. Here's the setup-
Main Location- there are 15 55is that are working perfectly. The switches have beend configured for QOS(DCSP) and Vlans. The phones are in VLAN20 and the Computers are in VLAN1, the default VLAN. There are two nics in the trixbox server, one connecting to VLAN20 and one connecting to VLAN1. THe switch port uplinking to the pix firewall is in VLAN one. There is no VLAN or QOS setup on the pix. I'm not sure if this is correct. Right now the remote phone is connecting to the trixbox via VLAN1. Is it possible to make the phone at the remote location part of VLAN20?
Remote Location- There is one pix with one 55i plugged in directly and 3 computers plugged into the other ports. There is no VLAN or QOS Setup.
There is a site to site VPN tunnel between both locations using the pix firewalls. The VPN is used only for Terminal server sessions(Usually only one at a time) and the one phone. Both locations have ADSL 384K/1.5Mb.
Here's the issue- On the remote side the 55i will display No Service several times throughout the day. It usually comes back on line in about 5 minutes. The user is still able to make calls eventhough the No Service is displayed however he cannot recieve calls. The user seems to think it is happening when he downloads a large file from the internet. I plan on sending out a device to the remote location that will prioritize traffic but I wanted to make sure that was the problem. I was able to capture a sip debug from asterisk while this was happening-
[2009-04-13 13:14:29] NOTICE[2553] chan_sip.c: Correct auth, but based on stale nonce received from '<sip:300@192.168.0.10:5060>' [2009-04-13 13:14:29] VERBOSE[2553] logger.c: <--- Transmitting (no NAT) to 192.168.1.230:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.230:5060;branch=z9hG4bKde64c7a9ba0cc5acf.e84359fd0d96b14a9;received=192.168.1.230 From: <sip:300@192.168.0.10:5060>;tag=3cf0c2f699 To: <sip:300@192.168.0.10:5060>;tag=as57c56ea5 Call-ID: 550216187e27d645 CSeq: 24460 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="79a7cc8e", stale=true Content-Length: 0
Phones all runnung 2.5 firware (latest) Trix is running 2.6.10 with asterisk 1.4.21.
Vlan1- 192.168.0.0
Vlan20- 192.168.25.0
Remote VPN Subnet- 192.168.1.0
Trix eth0- 192.168.25.3
Trix eth2- 192.168.0.10
Any help would be greatly appreciated. I tried to give as much info as possible but let me know if you need something else.
Thanks,
 
Always disable sip fixup on
Wed, 04/15/2009 - 2:45pm
Always disable sip fixup on cisco equipment.
Run:
sip no fixup
no fixup protocol sip udp 5060
no fixup protocol sip 5060
Just to be safe! Any "SIP Fixing up" solution Cisco offers, never works with the standard SIP protocol. Same goes to any router that offers "SIP ALG" always disable these types of features.
 
Thank you, I am going to
Wed, 04/15/2009 - 3:41pm
Thank you, I am going to disable it tonight.
 
Should the timeouts for sip
Wed, 04/15/2009 - 9:41pm
Should the timeouts for sip and sip media also be disabled on the pix?
 
Without the ALG the timeouts
Wed, 04/15/2009 - 10:39pm
Without the ALG the timeouts are not relevant.
If the PIX is closing connections it is generally a result of contention between the SIP registration timer on the UA and the PIX's housecleaning of embryonic connections.
--
Scott
aka "Skyking"
 
Member Since:
2008-02-23