SYNPROXY connections fail on IPFire

I am attempting to use SYNPROXY to protect my mail server from an ongoing SYN Flood attack. The mail server is on my green network for which I have generated this port forwarding rule:

A NAT_DESTINATION -d a.b.c.d/32 -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.X,X

To enable SYNPROXY I use the following:

sysctl -w net/netfilter/nf_conntrack_tcp_loose=0
echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize
sysctl -w net/netfilter/nf_conntrack_max=2000000

iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

This works OK when applied to the mail server but when applied to IPFire all connections on port 25 are dropped.

From what I can find out the problem is the NAT modules and Conntrack tracking table need to be kept synchronised with a rule similar to:

iptables -t nat -A PREROUTING -p tcp -o eth1 -j DNAT –to 192.168.X.X:25

but I’m not sure how this should be applied to IPFire.

Would appreciate some help here since my knowledge of iptables is rather limited.

In future releases would it be possible to add an option in IPFire to enable SYSPROXY in Firewall Options?

IPFire 2.23 (i586) - Core Update 136

Hey Rob,

I am generally interested in this, but I do not follow entirely where this is going wrong.

So you want IPFire to not forward those TCP connections just yet, but rather have it establish it first and then forward it to the internal mail server. Makes sense.

Did you run these commands exactly like this? IPFire has many things in those INPUT/PREROUTING chains which should always be processed first.

The last command is just a port forwarding rule (or half of it).

Continuing the discussion from SYNPROXY connections fail on IPFire:

Hi Michael,

In my (ongoing) SYN Flood attack my server is being sent SYN packets with a spoofed source address which obviously don’t get the SYN-ACK reply because they are being sent from a foreign address. I have been getting up to 70,000 of these per day and have managed to block them with iptables so far but now the spoofed address are from /17 net blocks and the block list has become unmanageable.

I have enabled SYNPROXY on my debian server which is blocking the unreplied connection attempts at the server but since I am port forwarding from my firewall the connections are still being made to IPFire first. If I can enable synproxy in IPFire the bogus connections should be rejected at the firewall.

The details for enabling synproxy on debian are here:

but this failed to forward any genuine smtp packets through the firewall when I applied the above commands to IPFire although I did confirm that synproxy was enabled OK.

I am pretty sure that the problem is caused by a conntrack / nat conflict as advised here:

but I am not sure how the rules in this article should be applied to IPFire.
I am fairly confident that if suitable INPUT/PREROUTING can be applied it should work OK.

If you have any ideas, I would be more than happy to test them here.

Thank you


Hi all,
IPFires firewall WUI do have the “Rate-Limit new Connections” which is also outlined as useful in the wiki --> for Syn-Flood attacks. May “Concurrent-Connections” can also serves some protection ?

Did you seen or tested this ?



I have Rate-Limit new Connections set to 2 per second but at last count I still had over 100 “SYN” SMTP connections to IPFire. It’s a difficult setting to get right because I don’t want to prejudice legitimate mail.
I need an automated way of blocking connections and have had some success with FAIL2BAN running on the server but that is only really effective when they are targetting specific IPs but it isn’t very useful when they are cycling IPs around a netblock . I have also had some success with ‘Banish’ which I ported over from IPCop and can block netblocks with iptables but entries need to be manually added.

SYNPROXY running on the server is doing a good job of rejecting the flood from the server but would be much better if I could get it to work on IPFire.


Would your employer be able to sponsor some work to add this to IPFire?

Sadly there is only me as I am a retired engineer :frowning_face:


Ah okay. That would have helped us to prioritise this topic.

From what it looks like, the IPFire kernel has everything we need enabled, but it will be slightly tricky to get it into the firewall scripts and avoid any interference with other things.

That was my impression and as I said above it looks like synproxy is working OK when enabled, it looks like just not playing very nice with port forwarding.
I would be very pleased if I can help in any way if I can.

Incidently synproxy is an option from the gui in pfSense although I have never used it.

If it is of any help I found this shell script on GitHub which may be of use.


Yes, that pretty much sums it up what has to be done. However, IPFire has a hundred other features here which mark packets for NAT and other things and we need to take care of them.

It is not super-major work, but it will be at least half a day and of course needs to be added to the UI.

1 Like