Firewall rules for IPsec network apparently generated multiple times

Security Firewall Rules
1

Running iptables --list IPSECOUTPUT -n I get ~6.800 lines, most of which is:

ACCEPT esp – ipfire_IP remote_IP_1
ACCEPT ah – ipfire_IP remote_IP_1
ACCEPT 94 – ipfire_IP remote_IP_1

Currently, there are three ipsec connections established. I can see rules for the other two connections multiple times as well, but not nearly as much as for the first one mentioned.

See # iptables --list IPSECOUTPUT -nChain IPSECOUTPUT (1 references)target - Pastebin.com

I have reloaded the firewall rules via the GUI, so I guess those ipsec should have also been rebuilt. Haven’t tried a reboot. Anyhow, if those were to be created the right way on restart, there probably still would be a problem of them accumulating over time.

Has someone noticed this behaviour, too?

IPFire 2.29 (x86_64) - Core-Update 200

2

Hello Lars,

I’ve seen this as well. I haven’t had the time to research the reason but can confirm that it’s been going on for a while - not new in CU 200.

Regards,

Stephen

3

on my CU198 i can’t second this

1 IPSec Connection →

[root@XXX ~]# iptables --list IPSECOUTPUT -n Chain IPSECOUTPUT (1 references) target prot opt source destination ACCEPT esp -- 149.xxx.xxx.xxx 178.xxx.xxx.xxx ACCEPT ah -- 149.xxx.xxx.xxx 178.xxx.xxx.xxx ACCEPT 94 -- 149.xxx.xxx.xxx 178.xxx.xxx.xxx ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:500 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 [root@XXX ~]#

4

On my CU200 vm network running with a n2n ipsec connection I also can’t confirm this.

Here is my output.

[root@XXX yyy]# iptables --list IPSECOUTPUT -n
Chain IPSECOUTPUT (1 references)
target     prot opt source               destination         
ACCEPT     esp  --  192.168.26.200       192.168.26.222      
ACCEPT     ah   --  192.168.26.200       192.168.26.222      
ACCEPT     94   --  192.168.26.200       192.168.26.222      
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:500
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:4500
5

Core-Update 201 Development Build: master/7f0ed6b7
Core-Update 201 Development Build: master/a5909296

IPSec N2N

iptables --list IPSECOUTPUT -n
Chain IPSECOUTPUT (1 references)
target     prot opt source               destination         
ACCEPT     esp  --  a.b.c.d          u.v.w.y       
ACCEPT     ah   --  a.b.c.d          u.v.w.y       
ACCEPT     94   --  a.b.c.d          u.v.w.y       
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:500
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:4500

Regards

6

Hello,

I pushed a fix for this here:

Please install the development build as soon as it becomes available and let me know if this fixes the problem.

7

@ms Great catch!

I’m on vacation next week, and will try to apply the changes to our version afterwards.

8

As always, I was held up by something else, also a problem with /boot being too small, so I just two days ago was able to install CU 201. The fix does not seem to be implemented there, and I don’t know where to apply that patch. Probably needs the source to be patched and compiled/distributed which is out of my scope.

However, CU 202 seems to include the fix, so I am going to wait for this.

9

Yes. That was the version that the patch was merged with and it is released for testing.

10

You can’t apply it directly on your installed ipfire system.

It is a patch that is used in the building of strongswan as part of building ipfire.

11

Actually, I have found that I was wrong with the above statement.

The patch shown is applied in the building of strongswan but that includes the creation of some scripts and the following one

/usr/libexec/ipsec/_updown

includes the lines modified by the patch that was shown.

I still think the simplest is to use CU202 when it is released.

12

Thanks, I have manually patched the code in that file starting at line 393.
After restarting an IPsec connection from the GUI, the output of iptables --list IPSECOUTPUT -n | wc -l has gone down from 2209 to 7.