Difference between revisions of "Router Info"

From IPitomy Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 17: Line 17:
 
= Fortigate<br/> =
 
= Fortigate<br/> =
  
I found this online about solving issues with Fortigate routers and NO AUDIO with remote SIP:
+
==Disable SIP ALG==
  
In the command line of the fortigate type the following:
+
====Check the ID of the SIP session helper====
  
*<code>config system settings</code>
+
  config system session-helper
*<code>set sip-helper disable</code>
+
      show
*<code>set sip-nat-trace disable</code>
 
  
Reboot the device
+
Among the displayed settings will be one similar to the following example:
  
In the command line type the following:
+
edit 13
 +
      set name sip
 +
      set protocol 17
 +
      set port 5060
 +
    next
  
*<code>config system session-helper</code>
+
Here entry 13 is the one which points to SIP traffic which uses UDP port 5060 for signaling.
*<code>show</code>
 
  
(now look for SIP, mostly it will be "12")
+
In this example, the next commands to remove the corresponding entry would be:
  
*<code>delete 12</code>
+
delete 13
 +
    end
  
Don't use any protection profiles on the firewall of the sip rules.
+
Note that it is not necessary for the SIP entry to be 13, so cross verify which entry has the sip helper settings.
 +
 
 +
====Change the default–voip–alg-mode to disable SIP-ALG====
 +
 
 +
By default, SIP-ALG is enabled, if you run "show full" you will find it is set to "proxy-based" as shown below:
 +
 
 +
config system settings
 +
    set default-voip-alg-mode proxy-based
 +
    end
 +
 
 +
Run the following command to disable SIP-ALG (proxy-based) and use SIP-helper (kernel-helper-based):
 +
 
 +
config system settings
 +
    set default-voip-alg-mode kernel-helper-based
 +
    end
 +
 
 +
====Either clear sessions, or reboot the FortiGate to ensure changes take effect====
 +
 
 +
- To clear sessions
 +
 
 +
Ideally, sessions related to VoIP traffic are deleted.
 +
 
 +
However, in the case of SIP, this means not only deleting the SIP control sessions but also all sessions opened to handle the audio (RTP) traffic.
 +
Knowing the port-range used for the audio traffic, sessions clear can be selected by first applying a filter as follows:
 +
 
 +
diagnose system session filter ...
 +
 
 +
The command to clear sessions applies to ALL sessions unless a filter is applied, and therefore will interrupt all traffic!
 +
 
 +
diagnose system session clear
 +
 
 +
-  Alternatively, reboot the FortiGate using either GUI or CLI. The CLI command is:
 +
 
 +
execute reboot
 +
 
 +
==Disable NAT on IPv4 Policy==
 +
 
 +
A common mistake is to create an IPv4 policy for UDP ports 5060 and UDP ports 10000-20000 and to leave the NAT switch on.<br/>
 +
This makes all incoming traffic on those ports appear to come directly from the private IP address of the Fortigate.<br/>
 +
If you see this behavior, disable the NAT switch on the IPv4 policy.<br/>
 +
 
 +
[[File:fortigatenat.png]]
 +
 
 +
==Ensure Outbound Traffic is Allowed from PBX==
 +
 
 +
Many Fortigate configurations I've seen have most outbound traffic blocked.<br/>
 +
In these configurations you will need to create an outbound rule allowing the PBX to talk to our SIP servers from source port 5060 UDP and 10000-20000 UDP.<br/>
 +
Ideally you would allow the PBX to go outbound on any port it chooses so it can check for updates, provide web and SSH access, etc.<br/>
  
 
= Cisco Pix 506/501/515 and Cisco ASA<br/> =
 
= Cisco Pix 506/501/515 and Cisco ASA<br/> =

Latest revision as of 19:58, 18 November 2021

This page contains general information about port forwarding and disabling application layer gateways on particular routers.

Router Compatibility List

Sonicwall

Disable SIP Header Transformations and Enable Consistent NAT

SonicWALL SIP ALG is called SIP Header Transformations, this should be Disabled and Consistent NAT should be Enabled:
Sonicwallcnsht.png

Create Outbound NAT Policy and Disable Source Port Remap

In some cases the SonicWALL will remap the 5060 and 10000-20000 UDP source ports causing one way audio and calls dropping after 30 seconds.

To resolve this, create an inside to outside rule like the following:

Original Source:
Translated Source:
Original Destination:
Translated Destination:
Original Service:
Translated Service:
Inbound Interface:
Outbound Interface:

PBX Private IP
IP of the WAN interface (X1 IP for example)
Address Group for our SIP servers (52.5.220.123 or 54.200.236.200)
Original
Service Group including 5060 UDP and 10000-20000 UDP
Original
Any
WAN interface (X1 for example)

After that go to the Advanced tab and check the box for "Disable Source Port Remap" and click OK.
File:Sonicwallspr.PNG
Once completed the PBX will always use the proper source ports on the WAN side.

Create Access Policy with Increased UDP Timeout

Most often seen in cloud deployments you will see phones going REACHABLE/UNREACHABLE with complaints of calls going directly to voicemail and BLFs not lighting properly.

To fix this add a LAN to WAN Access Policy as follows:

From Zone:
To Zone:
Service:
Source:
Destination:
Users Allowed:
Schedule:

LAN
WAN
SIP (UDP 5060)
Any
Any
All
Always On

Navigate to the Advance tab and increase the UDP timeout to 300 seconds, once saved phones should remain REACHABLE.

Mikrotik

This router has an ALG that can be disabled with the following command

  • /ip firewall service-port disable sip

The info was found at the following two links Mikrotik Wiki Mikrotik Forum

Fortigate

Disable SIP ALG

Check the ID of the SIP session helper

 config system session-helper
     show

Among the displayed settings will be one similar to the following example:

edit 13
      set name sip
      set protocol 17
      set port 5060
    next

Here entry 13 is the one which points to SIP traffic which uses UDP port 5060 for signaling.

In this example, the next commands to remove the corresponding entry would be:

delete 13
    end

Note that it is not necessary for the SIP entry to be 13, so cross verify which entry has the sip helper settings.

Change the default–voip–alg-mode to disable SIP-ALG

By default, SIP-ALG is enabled, if you run "show full" you will find it is set to "proxy-based" as shown below:

config system settings
   set default-voip-alg-mode proxy-based
   end

Run the following command to disable SIP-ALG (proxy-based) and use SIP-helper (kernel-helper-based):

config system settings
   set default-voip-alg-mode kernel-helper-based
   end

Either clear sessions, or reboot the FortiGate to ensure changes take effect

- To clear sessions

Ideally, sessions related to VoIP traffic are deleted.

However, in the case of SIP, this means not only deleting the SIP control sessions but also all sessions opened to handle the audio (RTP) traffic. Knowing the port-range used for the audio traffic, sessions clear can be selected by first applying a filter as follows:

diagnose system session filter ...

The command to clear sessions applies to ALL sessions unless a filter is applied, and therefore will interrupt all traffic!

diagnose system session clear

- Alternatively, reboot the FortiGate using either GUI or CLI. The CLI command is:

execute reboot

Disable NAT on IPv4 Policy

A common mistake is to create an IPv4 policy for UDP ports 5060 and UDP ports 10000-20000 and to leave the NAT switch on.
This makes all incoming traffic on those ports appear to come directly from the private IP address of the Fortigate.
If you see this behavior, disable the NAT switch on the IPv4 policy.

Fortigatenat.png

Ensure Outbound Traffic is Allowed from PBX

Many Fortigate configurations I've seen have most outbound traffic blocked.
In these configurations you will need to create an outbound rule allowing the PBX to talk to our SIP servers from source port 5060 UDP and 10000-20000 UDP.
Ideally you would allow the PBX to go outbound on any port it chooses so it can check for updates, provide web and SSH access, etc.

Cisco Pix 506/501/515 and Cisco ASA

This is for Pix 506/501/515 but it should work with any Cisco Pix, and possibly other Cisco
routers.
  1. access-list 101 permit udp any host 64.238.XXX.XXX range 10000 20000
    (Note: Replace 64.238.XXX.XXX with your public IP assigned to be forwarded to the IPitomy PBX)
  2. access-list 101 permit tcp any host 64.238.XXX.XXX range 10000 20000
    (Note: Replace 64.238.XXX.XXX with your public IP assigned to be forwarded to the IPitomy PBX)
  3. static (inside,outside) 64.238.XXX.XX 172.16.2.129 netmask 255.255.255.255 0 0
    (Note: Replace 64.238.XXX.XXX with users public IP, replace the 172.16.2.129 with users private IP that is assigned to the IPitomy PBX)
  4. no fixup protocol sip 5060
  5. no fixup protocol sip udp 5060

Adtran

From a recent interaction with an AdTran tech, it was shown to us there is a setting for "proxy transparency" that needs to be enabled in order for all of the SIP traffic to pass unhindered. This was when the Adtran was the routing device at the remote site, but likely would need to be enabled when the Adtran is at the PBX site. Its worth trying for sure.

PepLink

Here is a document sent to a dealer from PepLink regarding configuration settings that may be required for Remote SIP to function properly:


File:Peplink Config.pdf

FIOS ActionTec

We have found the following article that outlines some possible configurations that are available on the Actiontec Modem/Router combo that FIOS is installing. This gives some options on ways to configure to optimize VoIP and SIP traffic passing to remote.

http://www.dslreports.com/faq/verizonfios/3.0_Networking#16077

Comcast Modem

We have received some information from our dealers that if your site has a Comcast modem/router, you should request a SMC and not a Linksys, as the reports are that the SMC handles VoIP more consistently. Additionally, there may be issues with Comcast modem/routers ability to handle multiple concurrent NAT sessions, limiting the number of remote phones you can install at a remote site.

Sophos

Some Sophos models have a hidden SIP module that is not in any way indicated, nor accessible, from the webgui. It must be disabled from the command line console. If left enabled, it attempts to override any rules you may have in place for sip/rtp traffic and can result in one-way audio, and other issues with calls successfully connecting.