Skip to main content
Jamr
Jamr
New Member
December 18, 2015
Question

Firewall seems to start blocking SIP after several minutes for all WAN2 Traffic

  • December 18, 2015
  • 4 replies
  • 15222 views

Hi,

 

We've recently setup a Fortigate 60D (FW: v5.0,build0292 (GA Patch 9)) in one of our datacenters and are running into some issue's with our SIP (Asterisk) Server.

 

First of, let me explain the setup we have here;

 

We have one Asterisk server living on "internal" on a local IP 192.168.21.101.

We have WAN1 which holds our uplink to the datacenter / internet and hosts our public IP range.

We have setup 1 Virtual IP (let's say 1.1.1.1) on interface WAN1 that binds to 192.168.21.101 (on internal), this works fine. All SIP traffic to 1.1.1.1 is received and handled on the Asterisk server (no disruptions at all).

 

On WAN2 we have a dedicated uplink to one of our carriers that terminates all VoIP traffic for us. It's a dedicated VLAN that is not publicly accessable. 

We have setup another Virtual IP (call this 2.2.2.2) on interface WAN2 that also binds to 192.168.21.101 (internal).

This way our Asterisk server can send SIP to our carrier, and vice versa.

This is where we're having issues, the connection to our carrier works fine for about 10-15 minutes. After that, the carrier is having trouble routing SIP to our Asterisk machine. In my tests I was able to speed up the time it takes to fail by spamming a lot of SIP-Invites (random calls) to our Asterisk server, which then forwards these INVITE's to our carrier.

 

Restarting the Fortigate fixes the problem, and it will work for another 15 minutes.

I've tried the following (none of which seemed to solve this problem for us);

 

 
set sip-helper disable
set sip-nat-trace disable
Deleted session-helper (12) SIP
Disable RTP Processor
 
 
I've already debugged the issue thoroughly with our carrier and our equipment provider (on the Asterisk/VMWare side). There are no misconfigurations anywhere and this setup should be working.
Additionally, when we take the Fortigate out of the equation and connect the Carrier's uplink directly to our VMWare machine and just configure the IP locally on the VM; the whole setup works perfectly. 
Only when the fortigate is routing traffic from / to our Uplink do things seem to break.
 
I have attached a schematic layout of our setup in this datacenter to help you visualize.
Also I have pastebin'd (http://pastebin.com/vkpcLXxp) the (relevant) parts of the configuration we have tried to setup (and failed).
I had to edit some parts for security reasons, should anyone require to see the full config or if I deleted something that might be relevant, feel free to PM.
 
I'm hoping someone on here can point us in the right direction.
If not, we'll be looking to hire a Fortigate engineer to come troubleshoot this issue for us (we have about 2 weeks to get this setup operational).
 
Thanks and best regards,
Jeroen
 
 
 
 
 
 
    4 replies
    Jamr
    JamrAuthor
    New Member
    December 21, 2015
    I hate bumping but I find it hard to believe no one has had any similar or related issues before? 
    shehan8787_
    shehan8787_
    New Member
    February 11, 2016
    Hi,
     
    Have you  had a solution for this.. I have the same exact problem..
    The local VOIP phones are supposed to be registered in a PABX in the cloud.
    These are the steps happens when I plug in the Fortigate 90D between the router and the core switch.
     
    1. All phones starts to register with the PABX which is in the cloud.
    2. Some phones can take outbound calls and local calls between the LAN. Some phones can only take local calls.
    3. After 2, 3 minutes, one by one, the phones becoming unable to take calls.
    4. After about 10 minutes, phones starts to unregister from the PABX (Registration fails).
    5. After about 30 minutes, all the phones are unable to register with the PABX..
     
    Did you have any solution for this..
    I've also created a Ticket, but after several tries, the TAC engineer is also claiming that there is no issue in the Fortigate..
    But, this happens when the Fortigate is plugged in, so the SIP traffic is obviously being blocked by the Firewall...
     
    nnBluestemfiber
    nnBluestemfiber
    New Member
    February 12, 2016
    Find a tool and search on ALG.
    Could also be a Codec Issue?
     
    Common things I run:
     config voip profile edit default config sip set status disable end end  config system settings set sip-helper disable set sip-nat-trace disable end  config voip profile edit default config sip set rtp disable end end  config system session-helper show delete 12 (whatever sip is) end  reboot the firewall   THE BELOW IS THE INFO ON THE VOIP PHONES AND THE SERVICES THEY USE  the most common ports are:  5060 + 5061 UDP : Signaling  7000 UDP : Signaling  8080 TCP : Signaling  16384 – 32768 : Audio / RTP
    tclark
    tclark
    New Member
    March 4, 2016
    Do you have a route for your Carrier's SBC (or whatever IP you register to) that points to the gateway on WAN2?
     
    You can set up a packet capture on the 60D by going to this hidden page
    http://<ip_of_fortigate>/p/firewall/sniffer/
     
    Sniff on the WAN2 interface and try to re-create the issue. Once the issue occurs, check to see if you are receiving the packets on the WAN2 interface. If you are receiving them, compare the SIP msgs to when the calls were working.
     
    I have a very similar setup in my lab here at the office where I have a private link to our SBC over the WAN2 port. I just had to set up a route for our SBC to point at the gateway on WAN2.
    
        
                                                
    
        
    
    
    

            
    
                                        
    
            
                        
    
                                                                                                            
            
    

    

    

        
    
                    
    
    
    
    

    

    
    
    

                                        
    
                                                        
    
            
        
    
    

    

    

                                    
    Terms & ConditionsAccessibility statement