And slight update:

With regards to Case 2, which happened last night. After I noticed that SIP 
registrations were failing between two of the offices, I commented out the 
register line in sip.conf on each box, reloaded SIP, and called it good for the 
night. After re-enabling it and reloading SIP this morning they successfully 
re-registered.

Is there some sort of TTL, cache, saved salt value, or other time/session 
related tidbit saved that is expiring here? 

- Chris


On Jun 17, 2010, at 10:21 AM, Chris Brentano wrote:

> Hi all,
> 
> I tried searching, so if this has already been discussed please point me in 
> the right direction.
> 
> On separate occasions I've seen cases where Asterisk boxes will be unable to 
> register with each other via SIP or IAX2 when a Firewall is replaced. I'll 
> describe two different cases. In both we have three offices connected via 
> IPsec tunnels.
> 
> 
> Case 1: High Availability firewall fail-over
> 
> We have two Palo Alto Networks PA-4020 firewalls in one office setup in an 
> active/passive pair. Sessions and traffic are automatically maintained and 
> moved to the passive firewall in case the active one dies/loses power/etc. 
> When I was doing routine maintenance and had to fail over to the passive 
> firewall purposely, the SIP connections between offices broke, and failed to 
> re-register. What I see is:
> 
> [Jun 17 10:09:40] NOTICE[3311]: chan_sip.c:7783 sip_reg_timeout:    -- 
> Registration for 'portl...@10.xx.x.25' timed out, trying again (Attempt #2273)
> 
> And similarly on the other side:
> 
> [Jun 17 10:09:16] NOTICE[17102]: chan_sip.c:10169 sip_reg_timeout:    -- 
> Registration for 'paloa...@10.xx.x.10' timed out, trying again (Attempt #1660)
> 
> Restarting Asterisk and even both servers doesn't seem to change anything. 
> The last time this happened, for some reason setting srvlookup=yes in the 
> [general] section of sip.conf *seemed* to fixed it. The previous time this 
> occured, the servers were trunked via IAX2 instead of SIP, but I switched to 
> SIP trunks because it solved the problem (for the meantime anyway).
> 
> 
> Case 2: Entire firewall replacement
> 
> In one office I recently replaced a Cisco ASA 5505 with a Palo Alto Networks 
> PA-2020. This completely broke SIP connections to the two other offices. Same 
> errors as above. Again, restarting Asterisk and even the servers sees no 
> change.
> 
> 
> It seems as if somewhere there's something that is cached with regards to the 
> old firewall (or perhaps IPsec/IKE session). I've been digging around but 
> can't find anything obvious. Has anyone else seen this behavior and 
> potentially found a fix? This happens with Asterisk 1.6.1.6 and Asterisk 
> 1.4.26.2.
> 
> Much thanks.
> 
> - Chris
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users


-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
               http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to