RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1566132 - ipsec.conf logip=no config setup option doesn't seem to work
Summary: ipsec.conf logip=no config setup option doesn't seem to work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-11 15:17 UTC by Martin Zelený
Modified: 2018-04-17 16:43 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-17 15:19:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Martin Zelený 2018-04-11 15:17:01 UTC 
Description of problem:
When trying to hide peers IP address, the address is still visible in logs.

Version-Release number of selected component (if applicable):
libreswan-3.23-3.el7

How reproducible:
On both CLIENT and SERVER there is the same /etc/ipsec.conf:

version 2.0

config setup
 plutodebug="none"
 logappend=no
 plutostderrlog="/var/log/pluto/pluto.log"
 protostack=netkey
 virtual_private=
 oe=off
 logip=no

conn test-logip
 authby=secret
 left=<CLIENT>
 right=<SERVER>
 keyingtries=1


Steps to Reproduce:

SERVER:
1. service ipsec start && sleep 5
2. ipsec auto --add test-logip

CLIENT:
1. service ipsec start && sleep 5
2. ipsec auto --add test-logip
3. ipsec auto --up test-logip


Actual results:

Both SERVER and CLIENT IP addresses are visible in /var/log/pluto/pluto.log:
"test-logip" #1: Peer ID is ID_IPV4_ADDR: '<SERVER>'

output of CLIENT's command "ipsec auto --up test-logip"
002 "test-logip" #1: Peer ID is ID_IPV4_ADDR: '<SERVER>'

output of "ipsec auto --status":
000 "test-logip": <ip address><CLIENT>...<ip address><SERVER>; erouted; eroute owner: #

- CLIENT and SERVER are real IP addresses


Expected results:
Opposite peer's IP address will be hidden.

Additional info:
If behavior is correct, please tell how the "logip=no" option is meant to be used.
Comment 2 Paul Wouters 2018-04-12 14:30:15 UTC 
The ipsec status command is not further protected. Only the logging is censored, and only when not enabling any kind of debugging.

It does seem that you found one issue where the peer uses its IP as ID, and since we don't filter ID's, the IP leaks there.

The usual deployment for this option is where the administrator uses either a groupid and preshared key, or certificate based ID's. These would not reveal the IP address.
Comment 3 Martin Zelený 2018-04-16 12:59:27 UTC 
(In reply to Paul Wouters from comment #2)
> The ipsec status command is not further protected. Only the logging is
> censored, and only when not enabling any kind of debugging.

Ok, I will not test output of the status command.

> It does seem that you found one issue where the peer uses its IP as ID, and
> since we don't filter ID's, the IP leaks there.

Can we consider this issue as a bug? Do we want to track it in this BZ or another one?

> The usual deployment for this option is where the administrator uses either
> a groupid and preshared key, or certificate based ID's. These would not
> reveal the IP address.

Should I enrich testing for this type of use or is the presumption correct that "logip=no" means no IP in the log even not in the ID value?

Thanks
Comment 4 Paul Wouters 2018-04-17 14:16:05 UTC 
logip= is really to prevent simple IP logs for large deployments that need to keep privacy. It is meant to ensure there are no log entries binding the (pseudo anonymous) ID with an IP address. So this prevents user344324324 leaving traces of their IPs in the logs.

This is mutually exclusive with using ID type IP. There you are always on the same static IP and there is no privacy issue here of tracking a single user through a cloud of VPN servers.

So speaking with my upstream hat on, I believe the option is working properly.

I added the following sentence to the man page for logip=

    When using ID of type IP address, this option will not hide 
    the actual IP address as part of the ID.
Comment 5 Martin Zelený 2018-04-17 15:19:24 UTC 
Thanks for explanation. Closing this as NOT A BUG.
Comment 6 Paul Wouters 2018-04-17 16:43:37 UTC 
Thanks for the testing and reporting! If you find other things you are unsure about, please keep reporting them!
Note You need to log in before you can comment on or make changes to this bug.