Fortigate allows unwanted SIP traffic

[MateuszP]

Good morning,
The case concerns the FG100F.
After upgrading from 6.2 to 7.2.5 there were problems with SIP traffic.
The policy that allows SIP traffic only from Poland (geolocation) and from a few selected ip addresses from abroad also allows SIP traffic from other countries that are not on the list.
When I check through the policy lookup, I have information that the traffic should go to the implicit deny, but the logs show that the traffic goes to this policy and is allowed. At first I thought geolocation was the problem, but I tested it and it seems to be working fine. The problem is only with SIP. What could be the reason? The policy is in proxy mode and does not have a VOIP profile so it uses default.

config firewall policy
   edit 87
      set uuid 1c0ffe44-254f-51ee-4c1c-b82b6b9b89ca
      set srcintf "OUTSIDE"
      set dstintf "SIP_PUB"
      set action accept
      set srcaddr {Poland + ip list)
      set dstaddr "SIP_GRP"
      set schedule "always"
      set service "serwis_10000-65535_RTPproxy" "serwis_5060_5061_siptcp" "serwis_5060-5062_sip"
      set inspection-mode proxy
      set logtraffic all
next

config voip profile
   edit "default"
   set comment "Default VoIP profile."
   config sip
      set status disable
   end
next

SIP helper has been removed and SIP disabled in VOIP profile as customers have reported problems with SIP traffic. Currently, this setup works fine except for one client. The problem is that the policy allows SIP traffic from addresses that are not on the allowed list.

[charley672]

Not sure what I'm doing wrong here, but SIP traffic won't match my LAN->WAN policy, or my traffic shaping policy. RTP traffic matches just fine but I get no hits on SIP.

I've done a packet capture just to verify my IP PBX is actually using port 5060 for SIP and that the destination matches what I have in the policy, and it all looks fine to me.

I do have a VIP policy that forwards SIP traffic to my PBX, but I'm not sure if/why this would prevent outbound SIP traffic from matching my policy.

[ede_pfau]

Hi @charley672 , your post looks like unrelated to OPs problem. If indeed hijacking this thread, please open a new one on your own. If only to increase the chances that someone sees your posts and offers a solution. Thx.

[mpeddalla]

Hello MateuszP,

Thank you for reaching out on Fortinet forums.

Can you please confirm whether are you using any VIP for the destination address "SIP_GRP" on the 87 ID firewall policy if yes please create a test firewall from any source to that VIP destination and enable

set match-vip enable from CLI.

Make sure you place that block policy below Poland allow policy

reference article you can use below :

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-block-VIP-access-using-GEO-Location...

The article which can explain why default deny is not blocking if you are using VIP:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Firewall-does-not-block-incoming-WAN-to-LA...

Regards,

Manasa

[MateuszP]

Thank you for your answer.

No, I don't use VIP, there are several regular IPs in the SIP_PUB group.
I don't have an explicit deny policy, traffic should go implicit deny.

I know about "set match-vip enable" in VIP policies.

[mpeddalla]

Hi Mateusz,

Thank you for the update.

I noticed there is also ip-list that you allowed i am assuming none of the above ip from the screenshot are not part of them I guess.

Do you still see the entries ? Just for testing Did you try creating a policy above ID 87 to block traffic for the same services?

-Have you configured any local-in-policy on the firewall to allow access?

Thanks,

Manasa

[MateuszP]

Yes, those IPs are not on the allowed list.
The problem still occurs.
There are several VDOMs on this FG and the problem also occurs on the others VDOMs. On one of them I added a deny policy above allow and block addresses correctly.
This does not change the fact that addresses that are not on the allow list should not match into allow.

There is no local-in-policy.

The problem is only with SIP traffic so I'm pretty sure the cause is somewhere on the side of SIP helper / ALG / voip profile.