cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question

VoIP - Problem

I am trying to replace Checkpoint 1490 to Checkpoint 5200 with GAIA-R80.10 Standalone deployment.

Unfortunately SIP is not passing through over checkpoint. It was dropping SIP 5060 port and I used SIP Security Rule for Proxy in DMZ Topology and created to related rules.

Topology:

Topology of Network

- DMZ Network, A-Network and B-Network direct connected to Firewall
- PBX Located On DMZ network (Included other servers. Example: AD)
- Branch-1 connected IPSec Site2Site VPN
- A-Network and B-Networks Included hosts and they can connect to each other and for DMZ
- Branch-1 Network has included Hosts and they can to connect DMZ Network

ERROR

dropping packets Reason: post lookup verification failed. and fwconn_key_init_links (OUTBOUND) failed

I followed sk65072:

No drop log on Firewall... (using: fw ctl zdebug )

Known Issues

  1.  IP-Phones are Registering to PBX. But sometimes cannot.
  2. Call from B-Phone-1 to B-Phone-2, B-Phone-2 receiving call from B-Phone-1 and cannot hear each other.(no voice) Sometimes only one way voice. Issue is same with other side.
  3. Usually receiving call from external sources to Call Center. Sometimes cannot receive...
  4. If Call Center receive call from outside. They transferring call to B-Phones or Branch Phones. But Cannot receive the destination IP-Phones and connection active with Call Center with external source...
  5. And lot of known and unknown issue...

No any drop and prevent logs on appliance. Working without issue with Checkpoint 1490 and any other 3rd party firewall. We tested it...

Created service request on support center 45 days ago. Connected 10 more times remote over session with support engineers. They are escalated to Diamond Service engineers. We connected remote session few times again and debugged appliance, monitored, collected to related log files.

But still same point.

Sorry for my poor English.

I hope you understand the topology and can help to me..

15 Replies

Re: VoIP - Problem

Look at this article, maybe this will help:

VoIP Issue and SMB Appliance (600/1000/1200/1400)  from Heiko Ankenbrand.

Re: VoIP - Problem

I tried this guide.

But still same Smiley Sad

0 Kudos

Re: VoIP - Problem

Hi Gomboragchaa,

check this:

1) create two udp port range objekts (range 1025-5059 and 5061-65535)

2) create a rule from all internal networks (PBX and fon-network) to SIP Proxy and drop outgoing port ranges objekts from point 1.

Thus only the SIP-Proxy can establish connections to the Fon and PBX via RTP. So the issues "fwconn_key_init_links (OUTBOUND)" should be gone.

This error occurs when the direction is changed. For example, if a connection from the Fon to the SIP proxy is opened via RTP and the SIP proxies tries to establish a new connection to the Fon. In this moment, the errors "fwconn_key_init_links (OUTBOUND)" begin.

By blocking the RTP ports to the outside, you force the SIP proxy to establish connections to your network and the failures are gone. 

I tried this behavior in our firewall and fon LAB for about 4 hours and came across this solution approach.

Regards

Heiko

Re: VoIP - Problem

Dear Heiko Ankenbrand

Thank you for your reply.

I found the issue. But don't know the how to fix it. It isn't rule and any other configuration issue.

  1. I disabled all Hide NAT of the internal networks.
    It was working everything without issue.
  2. Then re-enabled Hide NATs.
    Same issue again.

Actually I haven't any Static and Manual NAT rules and Auto-Generated Hide NAT rules working between internal networks while using SIP Protocols.

Other TCP connections fine.

Sorry for my bad English..

Maarten_Sjouw
Platinum

Re: VoIP - Problem

First of all make sure you have a No NAT rule above all Automatic NAT rules that disables NAT for all internal networks to each other. something like create a group for all RFC1918  networks and put it in the original source and dstination and leave the translated to original. unless you have a really good reason to NAT all traffic going between your own networks.

For all Voice traffic, the control connection to the PBX will tell calling Phone to directly start a voice connection to receiving phone, so when your control connections, from a PBX point of view, are all hidden behind the FW, where does it need to send its voice connection to?

Regards, Maarten
0 Kudos

Re: VoIP - Problem

I received information from TAC and R&D team.

They told:

this is an unsupported topology configuration that is leading to an issue with the correct establishment of the data connection used in the VoIP call.

OMG. I cannot believe that.

0 Kudos

Re: VoIP - Problem

Dameon Welch Abernathy‌ Do you have any clue?

0 Kudos

Re: VoIP - Problem

Hi John, I had some problems with a SIP trunk after upgrading to R80.10, what objects did you include in Services and Applications in the access rule? Could you share a print of this rule?

0 Kudos

Re: VoIP - Problem

Hi Yuri Dutra

I using only sip_any service on any to any rule. Make sure that in the "Advanced" properties of the service, the "Accept Replies" option is checked.

Also I activated "Hide NAT changes source port for sip over udp" option from "Inspection Settings > SIP General>Default Inspection>Advanced"

If you using multiple network. It is complicated. Currently, I am using manualt nat between internal networks. 

0 Kudos

Re: VoIP - Problem

I have a simular problem, running R80.10 with Soft IP Phones behind the firewall in the internal network, SIP Proxy is on the other side of the firewall. I have configured access rules with the proper protocols like sip-tcp, udp-high-ports and so on. When haveing Hide NAT enable nothing works, with Static one-to-one NAT there is one way audio in the phones. With no NAT at all phones work just fine in both directions. As for us the Static one-to-one NAT is a prefered solution, but how do we get it to work?

0 Kudos

Re: VoIP - Problem

Hi Johan Rudberg

1. In that case, please use only SIP_ANY service on the rule.

2. Activate "Hide NAT changes source port for sip over udp" option from "Inspection Settings > SIP General>Default Inspection>Advanced".

3. Create NAT Rule. See from below table.

Original SourceOriginal DestinationOrig.ServiceT.SourceT.DestinationT.Service
Internal_SubnetSIP_PROXY_IPAnyOriginalOriginalOriginal
SIP_PROXY_IPInternal_SubnetAnyOriginalOriginalOriginal

4. Clear Connection Table or reboot gateway.

I hope its work on your environment. I solved my issue like that method, even through over IPSec VPN.

NAT enforce works between internal networks(Some High Ports) when activated hide nat on subnet.

0 Kudos

Re: VoIP - Problem

Hi Gomboragchaa

I´ve tried this but, I have to use NAT that translates internal network ip range to a mapped ip range, thats cus our Voip ISP require us to use those paticular ip adresses. As of now the NAT is configured like this:

Orginal Source: Internal network, Orginal Destination: SIP Server Network, Org and TsService Orginal, TsSource: Our mapped ip range.

Doing NAT from x.x.x.x/14 to x.x.x.x/14 we get one way audio as best in the softphones.

0 Kudos

Re: VoIP - Problem

Hello,

I have the same problem and i've done some troubleshooting. 

Setup is with SIP_PROXY_IP in the internet. Everything looks good, call is setup but the RTP traffic coming from outbound dies on the firewall public interface and is never NAT-ed to the inside phone. The outgoing calls work fine because the NAT is performed correctly. The call setup phase works as we see both that the phone is registered on the SIP_PROXY_IP and that it is showing the call as working for around 60 seconds. The call itself is performed but nothing can be heard when doing inbound calls. This leads me to believe that the voice traffic itself is dropping. Outbound calls work just fine in this setup.

I am using INSIDE_PHONE_IP to SIP_PROXY_IP and reverse in a rule with sip_any allowed.

Output of "fw tab -t sip_state -f" shows mappings

Output of "fw tab -t sip_registration -f" is only ever showing table header

Packet capture is showing SIP traffic going on (there are some 489 Bad Event and 401 Unauthorized messages, but those appear in outgoing calls also and it still works) but RTP incoming traffic is never going through NAT, it dies on the O of the fw monitor. Outgoing RTP is clearly doing i I o O as supposed and leaving with the correct source IP.

Any idea what i missed? And of course if "fw tab -t sip_registration -f" should be showing any output?

If i configure a simple one-on-one NAT with SIP_PROXY_IP and INSIDE_PHONE_IP (mapped to FW_PUBLIC_IP) we have full functionality. There is more than one phone on the inside so this rules out a workaround with NAT unless i can spare 100 Public IPs.

What bugs me the most is that the customer tested with an ASA firewall and that one worked out of the box. It has NAT and a fixup configured pretty much.

0 Kudos

Re: VoIP - Problem

I have an one odious idea. Maybe you can try to use only 1 Public Ip address. 

Original SourceOriginal DestinationOrig.ServiceT.SourceT.DestinationT.Service
Internal_SubnetSIP_InternalAnySIP_ExternalSIP_PROXYOriginal
SIP_PROXYSIP_ExternalAnySIP_InternalInternal_SubnetOriginal

SIP_Internal - Internal ip of NATed SIP_Proxy IP.

(For example: Your SIP_Proxy IP is 2.2.2.2, your local subnet is 192.168.0.0/24, you prepare 1 free local ip (192.168.0.254) to use on nat rule. Also another one public IP (7.7.7.7.)  ) need to on this case 

Internal Subnet - Extensions IP addresses (192.168.0.0/24)

SIP_External - Public IP(7.7.7.7) 

SIP_PROXY - Your SIP Proxy.(2.2.2.2)

You have to change extension sip ip from Sip_External to Sip_Internal

Toplogy:

SIP_Extensions --- SIP_Internal_IP -- Firewall -- SIP_External_IP -- SIP_PROXY_IP

Nat works between only SIP_Internal_IP -- SIP_External_IP (one-to-one)

I just hope it could solve your SIP Issue...

Re: VoIP - Problem

Hello,

Your workaround sounds quite like a good suggestion. I would say this a valuable solution to overcome all issues when Proxy is External.

We finally solved the issue with the help of CP Support. It looks like the service was Asterisk and this was using some malformed packets.

First step is to make sure you use  service 'sip' and then the behavior has changed instead of 'sip_udp'. (This should be enough, unless you have some non-compliant traffic, like we had)

After this step internal to external traffic started to work fine, but external to internal works only on the second attempt (On the first attempt there is no voice at all for both sides). 

According to sk116126 which describes the customer configuration we created custom service for 'sip udp' and added 'high ports udp' service, and the issue has been resolved.