[asterisk-users] Asterisk SIP/IAX peers can't connect after Firewall change?

[Chris Brentano]

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 'portland at 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 'paloalto at 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