Bug 12808 - Core Update 165 (testing): charon logs iptables warnings while establishing an IPsec connection
Summary: Core Update 165 (testing): charon logs iptables warnings while establishing a...
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: Will affect most users Balancing
Assignee: Michael Tremer
QA Contact: Peter Müller
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-20 09:34 UTC by Peter Müller
Modified: 2022-05-18 15:33 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.