Rule blocking communication with specific netblock seems to not be working.

[gt]

The brief overview is we have someone attempting to, I assume compromise, phones in our VOIP system from an IP originating in the Russian Federation. I have attempted to block their IP, the /24 range of IPs, ports used and i'm still seeing packets on the internal interface from their IP. I cannot for the life of me figure out why this is happening and isn't being blocked, it's even using a rule configured for outbound communication to get in, according to FortiView.

So I suppose the first question is, will the packet capturer, "diag sniffer packet internal 'net 185.22.155.0/24' 6" show packets that are dropped? I typically set it up so I have one set on wan1 and a separate one set on internal to see if the packet is actually getting to internal from wan1. So if I'm seeing a packet from wan 1 with src=185.22.155.18 and dst =8.27.x.x. then at the same time one on the internal showing src=8.27.x.x and dst=192.168.x.x that, to me, means the packet is getting through. As a note I also use the gui packet capturer to do the same so I can view the .pcap since I haven't gotten the script that converts ssh output to work yet.

If there's some information I can get from the CLI that will best help diagnose this please let me know, I'm still learning all the commands. For now though, here are some images from the gui showing what I'm talking about.  This image shows in FortiView that these connections are being accepted using a rule designed for outbound communications (Source interface: Internal. Destination interface: Wan1 & 2) 

This image shows two rules, the first is set to block this ip range on outbound communications and then the other for inbound. I initially didn't specify the interfaces, but that wasn't working so I tried specifying them and it's the same situation, both rules showing 0 bytes. I also initially had the service as ALL but thought maybe it needed to specify protocols, so I did that on the inbound. If I ping the offending IP the first rule shows its blocking data, but if an internal phone tries to communicate with the offending IP, like to respond "405 Registration Method Not Allowed" since they're attempting to register with our VOIP phones using SIP, it doesn't block the communication and no bytes appear on the rule.

For a more detailed look at the rule FortiView is saying the connections are using. I have checked to ensure the offending ip is not within the desination address netblock, as that one is in the 184.x.x.x range with a /24 CIDR.

Another portion that is confusing about this, I cannot for the life of me find the offending ip on any logs within the 90E's gui or within FortiCloud's interfaces. I have ensured its set to log all, so I would think it would be showing. The catchall syslog we save locally, however, does show the hits. Every line that has their IP is showing what I've quoted below. The part that confuses me is that it's only showing the dstip as being the internal IP its communicating with rather than any lines showing the initial connection with our public ip(wan1: 8.27.x.x). I don't know if that's indicative of anything or if that's just standard.

srcip=185.22.155.18 src_port=59944 dstip=192.168.X.X dst_port=5060 proto=17 src_int="wan1" dst_int="internal" policy_id=23 profile="default" voip_proto=sip kind=register action=permit status=failed

So at this point I'm not sure what is going on and why I'm unable to block communication to/from this IP. Any assistance would be greatly appreciated. Also apologies if I blocked out too much information, I'm really not sure what should/should not be shared publicly and just decided to err on the side of caution.

[emnoc · Accepted solution]

If there's some information I can get from the CLI that will best help diagnose this please let me know,

Yes the cli cmd diag debug flow and a correct filter is what you should be looking at. This will ensure your hitting the policy in question.

Qs you need to ask

Q1?  What is  fwpolicy-id configuration

Q2?  Where is it in the sequence of "other" policies

[oheigl · Accepted solution]

In the WAN -> Internal Policy which should block the rule, can you try to set the destination address to all or the VIP (DNAT 8.27.X.X:65476->192.168.X.X:5060) which is used for the SIP gateway? It seems like the application layer on the FortiGate allows it through an expectation session, like it's explained in this KB article: http://kb.fortinet.com/kb/documentLink.do?externalID=FD36565

But please try these two things and let us know if it helps.

[tbec2017 · Accepted solution]

The traffic is passing through because of the SIP session helper or SIP ALG (most likely).  

diagnose sys sip status - use this command to display the current SIP session helper activity including information about the SIP dialogs, mappings, and other SIP session help counts

diagnose sys sip-proxy stats list - use this command to display status information about the SIP sessions being processed by the SIP ALG. 

Detailed info on how VOIP is handled by a FG: http://docs.fortinet.com/uploaded/files/3611/fortigate-sip-56.pdf

*****BEFORE PERFORMING THE STEPS IN THE LINK BELOW MAKE SURE YOU READ THE ABOVE GUIDE AS THE BELOW STEPS MAY BRING DOWN VOIP IF YOU DO NOT HAVE ALL OF THE CORRECT PORTS OPENS/NAT TRANSLATIONS SET UP*****

You can disable the SIP session helper and SIP ALG by following the steps here: https://www.vatacom.com/knowledge-base/disable-sip-alg-fortigate-firewalls/

[MikePruett · Accepted solution]

So this is incoming traffic? (WAN to inside?) if so, make sure the vip match is enabled. That may be causing issues

[gt]

It is both incoming and outgoing, I'm more concerned with the incoming as the outgoing are just unauthorized registration responses, so once that is dealt with the outgoing will stop.

In regards to match-vip I looked it up and none of my rules had it set, so I can see how that could cause a problem although as of now I don't have any inbound rules set with the destination of "all". I created one with match-vip enable to see if that works. 

I'm reading up on SIP ALG, as tbec2017 stated, and I think that may be the culprit here. It's a bit of a lengthy read but it makes sense with everything I'm seeing and I remember that being part of the configuration our VOIP provider needed changed. I just need to make sure I do it correctly without breaking anything. I'll update once I've been able to get time to implement a change.

Thanks everyone for the help, even if the issue as of now is still happening I'm learning a lot and I appreciate it.

[peterse]

It is because of the voip profile - SIP ALG. We are facing the same problem, it seems that the voip profile has a higher priority than firewall rules, which is weird.

[emnoc]

You know this post was offer  1+ years old ;)

Also the SIP voip profile comes into play after a rule match, so I don't buy that the voip profile was the issue.

Ken

[peterse]

Noticed later that the thread is so late and didn't see all the responses. My problem was caused by a misconfigured policy rule. As SRC was a FQDN entry, which was not resolvable anymore. One might assume that no traffic would be allowed, but the opposite was correct. All the traffic was allowed in. After exchanging the FQDN to IP, clearing all the sessions, unwanted traffic is blocked as it should be.

[ede_pfau]

Actually, policies with FQDN source or destination should have been removed (!) during the firmware upgrade. You should therefore always check config changes after an upgrade with 'diag debug conf read'.

Too bad this one was missed. I agree that the default action in this case should have been to block everything.