Bug 12808

Summary: Core Update 165 (testing): charon logs iptables warnings while establishing an IPsec connection
Product: IPFire Reporter: Peter Müller <peter.mueller>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: CLOSED FIXED QA Contact: Peter Müller <peter.mueller>
Severity: Balancing    
Priority: Will affect most users CC: michael.tremer
Version: 2   
Hardware: unspecified   
OS: Unspecified   
See Also: https://bugzilla.ipfire.org/show_bug.cgi?id=12866

Description Peter Müller 2022-03-20 09:34:52 UTC 
After upgraded to Core Update 165 (testing), I noticed charon emits these log messages while establishing an IPsec N2N connection:

Mar 20 10:26:16 maverick charon: 11[CHD] updown: iptables v1.8.7 (legacy): unknown protocol "ip" specified 
Mar 20 10:26:16 maverick charon: 11[CHD] updown: Try `iptables -h' or 'iptables --help' for more information. 

While they do not seem to have a substantial effect, they are ugly, and did not appear before C165. Perhaps they are related to the firewall changes made in C165.
Comment 1 Michael Tremer 2022-03-21 16:00:52 UTC 
I have noticed this too. Can you find out what the full command line was that lead to this problem?
Comment 2 Peter Müller 2022-03-21 16:15:25 UTC 
I believe this is caused by lines 109 and 117 in our strongSwan patch: https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/patches/strongswan-ipfire.patch;h=0f137ca2a821630c482d428e57f78d32aaf6bf2d;hb=HEAD#l109

However, I do not completely understand what we are doing here, but creating an iptables rule for the protocol "IP" does not seem to make sense indeed.
Comment 3 Michael Tremer 2022-03-21 19:15:35 UTC 
(In reply to Peter Müller from comment #2)
> I believe this is caused by lines 109 and 117 in our strongSwan patch:
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/patches/strongswan-
> ipfire.patch;h=0f137ca2a821630c482d428e57f78d32aaf6bf2d;hb=HEAD#l109

Yes, this is the place where this goes wrong.

> However, I do not completely understand what we are doing here, but creating
> an iptables rule for the protocol "IP" does not seem to make sense indeed.

It does if you are using any IPinIP encapsulation.

This bug has been introduced with the iana-etc update in:

> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=fb3e1c82c8b5e12314e87ea4641479bd1f4052fd

/etc/protocols contains a list of protocols and "IP" has been removed from it. I will send a patch that changes the iptables command in this script so this will work.

Give me some time for this to check whether we need the AH and ESP rules still.