This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 734103 - openswan ignores destination protocol set in protoport option
openswan ignores destination protocol set in protoport option
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan (Show other bugs)
6.1
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Avesh Agarwal
Ondrej Moriš
:
Depends On:
Blocks: RHEL62CCC 846801 846802
  Show dependency treegraph
 
Reported: 2011-08-29 09:22 EDT by David Spurek
Modified: 2015-03-02 00:26 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-17 17:24:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Spurek 2011-08-29 09:22:27 EDT
Description of problem:

Consider the following use case:

* host to host and 
* we want to secure any communication TO destination port 1111 over TCP,
* the other protocols are not secured (e.g. UDP)

Let 192.168.122.179 be the left side, ipsec.conf is as follows:

conn test
        auto=route
        authby=secret
        type=transport
        left=192.168.122.179
        right=192.168.122.60
        ike=aes256-md5
        phase2=esp       
        rightprotoport=tcp/1111

Command service ipsec start creates the following SPD:

src 192.168.122.179/32 dst 192.168.122.60/32 dport 1111 
	dir out priority 2080 ptype main 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport

Protocol is missing. Thus any communication to destination port 1111 will be secured no matter what protocol it is using. We found out that openswan always ignores destination protocol in protoport pair (i.e. rightprotoport on the left and leftprotoport on the right node). But it does not ignore source protocol, hence there is the following workaround (how to achieve use case goal):

conn test
        auto=route
        authby=secret
        type=transport
        left=192.168.122.179
        right=192.168.122.60
        ike=aes256-md5
        phase2=esp       
        rightprotoport=tcp/1111
        leftprotoport=tcp/0

This will lead to the desired SPD (zero port <=> any port):

src 192.168.122.179/32 dst 192.168.122.60/32 proto tcp dport 1111 
	dir out priority 2080 ptype main 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport

We consider this to be a bug in openswan.

Version-Release number of selected component (if applicable):

openswan-2.6.32-6.el6

How reproducible:

100%

Steps to Reproduce:

1. See above.
  
Additional info:

Obviously a destination protocol must be the same as a source protocol, thus if one tries to configure ipsec with e.g. leftprotoport=udp/11111 and rightprotoport=tcp/11111, openswan ought fail to start. But at the same time, it should be possible to choose protocol from each side (now it is possible only from "my" side).
Comment 1 Ondrej Moriš 2011-09-29 05:53:47 EDT
Any progress here? Although this bug has a flag 6.3.0? only, it might be important.
Comment 2 Ondrej Moriš 2011-10-17 10:36:29 EDT
This might be a blocker for CCC (added BZ#584498 tracker). Well, there is a workaround working for CCC (mentioned in Additional info section), but it would be great to have it resolved so that we can get rid of the workaround. 

Avesh, it is up to you - if there is an "easy" fix, it makes sense to ask for exception and 6.2.0 inclusion, otherwise not (but we would like to hear why).
Comment 3 Avesh Agarwal 2011-10-17 10:43:19 EDT
This is not a bug neither a work around instead an intendend design. You must specify leftprotoport=tcp (not leftprotoport=tcp/0.) since protocol must be same betwen left and right peer.

Please close this as not a bug.
Comment 4 Avesh Agarwal 2011-10-17 10:46:20 EDT
(In reply to comment #0)

> one tries to configure ipsec with e.g. leftprotoport=udp/11111 and
> rightprotoport=tcp/11111, openswan ought fail to start. But at the same time,

In what situation in this world, one has 2 peers where one is UPD and another is TCP and they are able to communicate.?

So again please close this as not a bug.
Comment 5 Ondrej Moriš 2011-10-17 11:12:10 EDT
Then you should at least correct documentation, because for instance if I would
like to have the following IPsec connections:

a) A <--- tcp/4300 [AH]  ---> B
b) A <--- udp/4300 [ESP] ---> B

And configure them as follows (on A):

conn test-ipv4-1
        auto=route
        authby=secret
 type=transport
        left=10.34.35.194
        right=10.34.35.198
        ike=3des-sha1
        phase2=ah
        phase2alg=sha1
        labeled_ipsec=yes
        policy_label=staff_u:lspp_test_r:lspp_harness_t:s0
        rightprotoport=tcp/4300

conn test-ipv4-2
        auto=route
        authby=secret
        type=transport
        left=10.34.35.194
 right=10.34.35.198
        ike=3des-sha1
        phase2=esp
        phase2alg=3des-sha1
        labeled_ipsec=yes
        policy_label=staff_u:lspp_test_r:lspp_harness_t:s0
        rightprotoport=udp/4300

Then the first one will be overwritten by second:

src 10.34.35.194/32 dst 10.34.35.198/32 dport 4300 
 security context staff_u:lspp_test_r:lspp_harness_t:s0 
 dir out priority 2080 ptype main 
 tmpl src 0.0.0.0 dst 0.0.0.0
  proto esp reqid 0 mode transport

And hence AH on tcp/4300 won't work (!), because SPD does not contain any
protocol information, it will apply for borh TCP and UDP.

If I will add leftprotoport=tcp and leftprotoport=udp to configuration, it will
work finally:

src 10.34.35.194/32 dst 10.34.35.198/32 proto udp dport 4300 
 security context staff_u:lspp_test_r:lspp_harness_t:s0 
 dir out priority 2080 ptype main 
 tmpl src 0.0.0.0 dst 0.0.0.0
  proto esp reqid 0 mode transport
src 10.34.35.194/32 dst 10.34.35.198/32 proto tcp dport 4300 
 security context staff_u:lspp_test_r:lspp_harness_t:s0 
 dir out priority 2080 ptype main 
 tmpl src 0.0.0.0 dst 0.0.0.0
  proto esp reqid 0 mode transport

The point of this bug is that if I do not set leftprotoport together with
rightprotoport, then resulting SPD does not contain protocol. Honestly I do not
care if this is a design decision or not, it is quite confusing. And hence it
should be said man page of ipsec.conf at least. There should be said that "if
you are using rightprotoport, you should use leftprotoport as well, otherwise
protocol will not appear in SPD rule (even though port will [confusion]). 

However, from the QA point of view, the best solution would be if SPD rule
contains procotol even if I am specifying just right/leftprotoport.
Comment 6 Avesh Agarwal 2011-10-17 11:27:10 EDT
(In reply to comment #5)
> Then you should at least correct documentation, 
Which documentation you are talking about? 

> However, from the QA point of view, the best solution would be if SPD rule
> contains procotol even if I am specifying just right/leftprotoport.
Its not about what QA wants, its about how networking works and how Openswan is designed based on that.
Comment 7 Ondrej Moriš 2011-10-17 16:44:40 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Then you should at least correct documentation, 
> Which documentation you are talking about? 

Man page ipsec.conf(5).

> > However, from the QA point of view, the best solution would be if SPD rule
> > contains procotol even if I am specifying just right/leftprotoport.
> Its not about what QA wants, its about how networking works and how Openswan is
> designed based on that.

Avesh, I agree with your point, I used too offensive words and tone in the previous comment, sorry about that. It is definitely not about what QA wants. Just let me ask you:

If I want to specify protocol and port on the right side via rightprotoport option, should I specify leftprotoport as well? Because now, I should do that, otherwise IPsec does not create correct SPD rules. In other words:

To achieve this:

a) A <--- tcp/4300 [AH]  ---> B
b) A <--- udp/4300 [ESP] ---> B

Is the following configuration correct or not?

# a) A <--- tcp/4300 [AH]  ---> B
conn test1 
        auto=route
        authby=secret
        type=transport
        left=A
        right=B
        ike=3des-sha1
        phase2=ah
        phase2alg=sha1
        rightprotoport=tcp/4300

# b) A <--- udp/4300 [ESP] ---> B
conn test2
        auto=route
        authby=secret
        type=transport
        left=A
        right=B
        ike=3des-sha1
        phase2=esp
        phase2alg=3des-sha1
        rightprotoport=udp/4300
Comment 8 Avesh Agarwal 2011-10-17 16:56:11 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Then you should at least correct documentation, 
> > Which documentation you are talking about? 
> 
> Man page ipsec.conf(5).
> 

I looked at ipsec.conf man page but I did not see it saying that you should not specify leftprotoport. Which part specifically you are referring to?

> > > However, from the QA point of view, the best solution would be if SPD rule
> > > contains procotol even if I am specifying just right/leftprotoport.
> > Its not about what QA wants, its about how networking works and how Openswan is
> > designed based on that.
> 
> Avesh, I agree with your point, I used too offensive words and tone in the
> previous comment, sorry about that. It is definitely not about what QA wants.
> Just let me ask you:
> 
> If I want to specify protocol and port on the right side via rightprotoport
> option, should I specify leftprotoport as well? 

You must use leftprotoport, and the reason you have 2 connections and openswan needs to differentiate which connection is for which protocol/port. 

Because now, I should do that,
> otherwise IPsec does not create correct SPD rules. In other words:
> 
> To achieve this:
> 
> a) A <--- tcp/4300 [AH]  ---> B
> b) A <--- udp/4300 [ESP] ---> B
> 
> Is the following configuration correct or not?
> 

As I said above you must specify leftprotoport, otherwise openswan can not distinguish locally which local protoport belongs to which connections.
 
> # a) A <--- tcp/4300 [AH]  ---> B
> conn test1 
>         auto=route
>         authby=secret
>         type=transport
>         left=A
>         right=B
>         ike=3des-sha1
>         phase2=ah
>         phase2alg=sha1
>         rightprotoport=tcp/4300
> 
> # b) A <--- udp/4300 [ESP] ---> B
> conn test2
>         auto=route
>         authby=secret
>         type=transport
>         left=A
>         right=B
>         ike=3des-sha1
>         phase2=esp
>         phase2alg=3des-sha1
>         rightprotoport=udp/4300
Comment 9 Ondrej Moriš 2011-10-17 17:24:57 EDT
(In reply to comment #8)

> > Man page ipsec.conf(5).

> ... Which part specifically you are referring to?

You're right that there is not said that you _should not_ use both {left,right}protoport (if using any). But at the same time, it is not said that _should_ use them together. It was not clear from the context for me and I think it is an important information. 

> > Just let me ask you:
> > 
> > If I want to specify protocol and port on the right side via rightprotoport
> > option, should I specify leftprotoport as well? 
> 
> You must use leftprotoport, and the reason you have 2 connections and openswan
> needs to differentiate which connection is for which protocol/port. 

OK, this is the argument I need to hear, now I agree with you that the issue described in this bugzilla is not a bug and I will close it immediately. 

Anyway, this discussion was helpful for me, thanks for your clarification.

Note You need to log in before you can comment on or make changes to this bug.