Iptables info re: SIP attacks on DPT=5060

Getting attempted intrusions from some specific ip addresses, some with 10s of thousands of attempts w/ DPT=5060. I’ve attempted to block those specific ip addresses by using the WebUI. I added a rule to DROP all incoming packets from a few of those specified ip address, but the packets continue to be accepted.

Those rules were being added to the filter table, so, from a bash command line I added a rule to the PREROUTING chain in the RAW table and that is successfully dropping the packets.

Michael Tremer suggested I bring up this issue here.

Now, I’m not an iptables guru, but in my research, here is what I’ve discovered. In order to determine why the rule I created in the WebUI (to DROP all packets coming from those specific IP address) wasn’t working, I first needed to understand the flow a packet takes through the iptables tables, chains, and targets. Reading through several iptables tutorials I gained an understanding of that flow. I found a reasonable flowchart which I found instructive:

From the command line, the command “iptables -t raw -L -v --line-numbers” we get the following:

The first chain listed in the output is the PREROUTING chain, which only has one entry with the target CONNTRACK. Now, if I’m reading this information correctly, all packets are sent to the CONNTRACK chain. (If I am wrong on this presumption, please let me know as the rest of this post relies on this presumption).

Now, looking at the first two rules in the CONNTRACK chain:

Again, if I am interpreting this correctly, then this accepts all SIP connections (incoming and outgoing). Presuming this is correct, then this is occurring in the packet flow well before we get to the INPUT chain of the filter table.

This would, to me at least, explain why the rule created by the WebUI is ineffective, while entering the iptables rule at the command line into the PREROUTING chain of the RAW table is effective.

After manually entering, at the command line, the iptables rules to DROP the packets from the attacking IP addresses into the PREROUTING chain of the RAW table, the PREROUTING chain then looks like this:

which actually DROPs all the packets from the subject IP addresses.

OK, this post is way more long winded that I had anticipated, however, could someone more knowledge about iptables please respond to my understanding here. And, if I am correct, what can be done in the WebUI to address this issue?

Also, this is my first post, so I hope it is formatted well enough.

Thank you,


1 Like

I can confirm this issue. I ran into the same situation when I wanted to block an IP address by adding a firewall rule in the WUI.
Any hints or explanations appreciated to solve this situation.


This is correct.

This is incorrect. SIP packets are sent to the Application Layer Gateway and potentially being rewritten.

You should not be dropping anything in the raw table. That is why we have the filter table. You simply do not even want to look at every single packet at this stage.

I cannot say why any SIP packets would be forwarded to your devices without seeing the rest of your firewall ruleset. You probably have a rule somewhere that accepts them.

And our firewall is indeed blocking packets. We would have noticed if it was Swiss cheese.


Please accept my apology in regard to your closing remark. I had no intent of disparaging ipfire or its abilities. I believe it to be a wonderful product and I’ve been using it for over 6 years. I just have an insatiable desire to learn and that is all I am trying to do here. At no time did I mean to imply there was anything wrong with the firewall. I’m just trying to better learn how it works. My intent was to announce my ignorance of what I was trying to do, and get some help to better understanding how the the firewall works in order to accomplish my project.

Part of the reason it has taken me so long to respond here is that you mentioned that I was incorrect about what the SIP helper does in the CONNTRACK chain, and, I had to do some more research in order to understand how to respond. I absolutely believed you when you said I was incorrect, but I didn’t know enough about it to be able to ask you and intelligent question about how it does work. So, I’ve learned a lot more about nf_conntrack and modules (extensions) and helpers, but only enough to formulate my follow up questions. Where can I find out more about what the sip helper does and what happens to the packets it matches? Is there a RETURN target (or something like it) that sends them back to next rule after they are sent to the CONNTRACK chain? if not, how do the packets enter the filter table from the raw table in order to pass through the filter table’s INPUT chain? I hope my questions make sense.

I would appreciate your help. Again, I am trying to learn, not to disparage.

I didn’t take this personally at all. IPFire has bugs. We could indeed not drop packets that we should be dropping - theoretically. But yes, we would have noticed this before.

I am using very plain and very clear language here, because generally speaking, people find solutions that simply are not correct. They expose them to risks that they are often not aware of. That is why I need to make it very clear if something is a bad idea. Of course everyone is free to still shoot themselves into the knee if they are into that.

And I am happy to help you learning how this whole process works. However, I need data to work with.

No, packets will just follow the path that you are showing on that diagram until they hit a rule that either accepts the packets for forwarding or drops it. All other rules will (potentially change the packet but then) let it pass.

Eventually every packet will land in the filter table and then go through all the rules.

OK, thank you. I believe the topic that I’ve introduced here is a complicated one, so, I’m going to present one that, I think, is less complicated as an example for a learning experience. If you think I should start a new thread with it, please let me know.


clark@sip->cat resolv.conf
# Generated by NetworkManager
nameserver 2620:0:ccc::2
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2620:0:ccd::2

The firewall is dropping the packets coming from the Orange network machine that is attempting to access the DNS service on the ipfire machine.

Attempted resolution:

Apr 2 06:01:55 router kernel: DROP_INPUT IN=orange0 OUT= MAC=b8:97:5a:ef:49:33:74:d0:2b:2f:b7:97:08:00 SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26933 DF PROTO=UDP SPT=43744 DPT=53 LEN=40

Apr 2 06:01:55 router kernel: DROP_INPUT IN=orange0 OUT= MAC=b8:97:5a:ef:49:33:74:d0:2b:2f:b7:97:08:00 SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26934 DF PROTO=UDP SPT=43744 DPT=53 LEN=40

Apr 3 06:00:39 router kernel: DROP_INPUT IN=orange0 OUT= MAC=b8:97:5a:ef:49:33:74:d0:2b:2f:b7:97:08:00 SRC= DST= LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=56854 DF PROTO=UDP SPT=59848 DPT=53 LEN=42

Apr 3 06:00:39 router kernel: DROP_INPUT IN=orange0 OUT= MAC=b8:97:5a:ef:49:33:74:d0:2b:2f:b7:97:08:00 SRC= DST= LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=56855 DF PROTO=UDP SPT=59848 DPT=53 LEN=42

Apr 3 06:00:45 router kernel: DROP_INPUT IN=orange0 OUT= MAC=b8:97:5a:ef:49:33:74:d0:2b:2f:b7:97:08:00 SRC= DST= LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=59479 DF PROTO=UDP SPT=40733 DPT=53 LEN=46

  • Using the “iptables-save” command, I found the rules that were added in the filter table (showing the “–dport 53” rules only)

/# Completed on Fri Apr 3 13:19:34 2020
/# Generated by iptables-save v1.8.3 on Fri Apr 3 13:19:34 2020
-A CAPTIVE_PORTAL_CLIENTS -p udp -m udp --dport 53 -m hashlimit --hashlimit-upto 3kb/s --hashlimit-burst 1mb --hashlimit-mode srcip --hashlimit-name dns-filter -j RETURN
-A CAPTIVE_PORTAL_CLIENTS -p tcp -m tcp --dport 53 -m hashlimit --hashlimit-upto 3kb/s --hashlimit-burst 1mb --hashlimit-mode srcip --hashlimit-name dns-filter -j RETURN
-A FORWARDFW -s -d -p udp -m udp --dport 53 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "FORWARDFW "
-A FORWARDFW -s -d -p udp -m udp --dport 53 -j ACCEPT

Now, because of my limited understanding, I am not able to decipher what these rules do, so, I hope you can help me figure out how to get the ipfire machine to accept the packets and, hopefully, provide a meaningful response to the DNS request.

Hope I have provided enough information. If not, let me know what’s missing and I’ll provide it.


In the example sited (just above), I changed the configuration of the machine so that the orange0 interface ( on the ipfire machine is the network gateway, and the primary DNS server, for the machine. With this configuration, as well as with the previous configuration, when I “ping yahoo.com” from a bash command line it takes 10+ seconds to have the first reply from yahoo.com displayed on the monitor.

After entering the ping command, 6-7 seconds later the DNS resolution completes; ping reports on the monitor, “PING yahoo.com ( 56(84) bytes of data.”, and 3-4 seconds after that the first reply is displayed, “64 bytes from media-router-fp1.prod1.media.vip.gq1.yahoo.com ( icmp_seq=1 ttl=51 time=73.9 ms.”; note the ping time of 73.9ms".

Then, removing the ipfire machine as a DNS server, leaving the Frontier DNS server as the only available DNS server for the machine, repeating the “ping yahoo.com” command works with immediate response, with no delay, of the DNS resolution or the display of the first reply, still at the 73-74ms ping time.

To me, if I am interpreting this correctly, the DNS request directed at ipfire machine times out and the request is moved on to the seconday DNS server at Frontier. But, that still doesn’t explain the 3 second delay of the first reply after ping displays the DNS resolution when the ipfire machine is the primary DNS server.

I’m certain the issue is due to the ipfire firewall dropping all the --dport 53 packets coming from the ORANGE network, whose destination is the ipfire machine. As of yet, I haven’t figured out how to resolve this issue.

From the GREEN network, there is no issue with the ipfire machine immediately resolving the DNS requests, so, the issue appears to only exist when the DNS requests originate from the ORANGE network.