Fortinet Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
gt
New Contributor

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

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.

4 Solutions
emnoc
Esteemed Contributor III

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

 

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

oheigl
Contributor II

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.

View solution in original post

tbec2017
New Contributor II

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/

 

 

View solution in original post

MikePruett
Valued Contributor

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

View solution in original post

15 REPLIES 15
MikePruett
Valued Contributor

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

gt
New Contributor

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
New Contributor

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
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

peterse
New Contributor

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
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"