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 733021 - Openswan parametr type=drop doesn't work
Summary: Openswan parametr type=drop doesn't work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Avesh Agarwal
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-24 13:24 UTC by David Spurek
Modified: 2015-03-02 05:26 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-29 09:51:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description David Spurek 2011-08-24 13:24:56 UTC 
Description of problem:


Version-Release number of selected component (if applicable):
openswan-2.6.32-4.el6_1.1

How reproducible:
always

Steps to Reproduce:
1.Setup /etc/ipsec.conf with:

conn testA
        auto=add
        authby=secret
        type=reject
        left=127.0.0.1
        right=127.0.0.1
        ike=3des-sha1
        loopback=yes

2.service ipsec restart
3.ipsec auto --up testA
  
Actual results:
Packets aren't dropped and command ipsec auto --up testA has output:
030 "testA": cannot initiate an authby=never connection

Expected results:
Packets are dropped

Additional info:
Same behaviour has type=passthrough and type=reject
Comment 1 David Spurek 2011-08-25 06:53:24 UTC 
Sorry for mistake, ipsec.conf should be:

conn testA
        auto=add
        authby=secret
        type=drop
        left=127.0.0.1
        right=127.0.0.1
        ike=3des-sha1
        loopback=yes
Comment 2 Avesh Agarwal 2011-08-25 18:21:11 UTC 
Whatever you are trying to achieve, you have to do following:

ipsec auto --route testA

And then observe if it does whatever you want to achieve.

In addition, why are you testing with openswan-2.6.32-4.el6_1.1 instead of openswan-2.6.32-6.el6?
Comment 3 David Spurek 2011-08-31 07:50:56 UTC 
Funcionality is ok with command ipsec auto --route testA with openswan-2.6.32-6.el6.

But I find another problem with combination different types of connections.

ipsec.conf look like this:

conn testA
        auto=add
        authby=secret
        type=transport
        left=127.0.0.1
        right=127.0.0.1
        ike=3des-sha1
        phase2=esp
        loopback=yes

conn testB
        auto=add
        authby=secret
        type=passthrough
        left=127.0.0.1
        right=127.0.0.1
        ike=3des-sha1
        leftprotoport=tcp/10000
        loopback=yes

It is important the order of calling ipsec auto --route testA and ipsec auto --route testB commands.

1. If ipsec auto --route testB called first and then ipsec auto --route testA, the behaviour is as I expecting (packets on port 10000 are without ipsec)

2. But if I call ipsec auto --route testA first and then ipsec auto --route testB (stricter rule). All packets are with ipsec (on port 10000 too).


I am not sure that it is a bug or expected behaviour, but records in ip xfrm policy are same in both cases and in manual pages isn't describe that the order of calling ipsec auto --route is important.
Comment 4 Ondrej Moriš 2011-09-29 09:51:19 UTC 
Avesh, we have double-checked this and it turns out that all types of connection (ie. option 'type' in conn settings) works fine. But, it appears to an issue with an order in which different types are 'routed'. Please see BZ#742126 [1]. As this bug seems not be valid anymore, I am closing is as NOTABUG.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=742126
Note You need to log in before you can comment on or make changes to this bug.