[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    [Ipsec-tools-devel] addendum to patch p5a
From:       "Wolfgang Schmieder" <wolfgang () die-schmieders ! de>
Date:       2011-11-29 19:10:00
Message-ID: 0658CC6A026C4F4B95D8151CCCC02C5D () Avitos
[Download RAW message or body]

Hello Timo

I would appreciate if you could give me any feedback about the acceptance of
my previous work. If you would reject one patch, which is a prerequisite for
a following one or a future one, it would mean more rework for me the more I
am progressing with other stuff like the 'listen' enhancement.

Anyway, I need to provide an addendum to my patch
p5a-p4c_getrmconf_ambigous.patch. This patch
p5b-p5a_getrmconf_ambiguous_adminport.patch covers 2 issues which I missed:

1) I didn't set the flag GETRMCONF_F_FILTERPH1ID in all necessary cases,
which was to 90% compensated by the fact, that I also forgot to evaluate
this flag in getph1(..).

2) Unfortunately I forgot to cover racoonctl at all and it didn't compile.
Now there will appear adaptions in racoonctl for the following cases:
-) ADMIN_DELETE_ALL_SA_DST
This will still delete all SA's which match a remote IP independent 
of the associated isakmp port (as before).

-) ADMIN_ESTABLISH_SA for protocol ADMIN_PROTO_ISAKMP
Now since we can have remotes in the config file with same IP
address, but different ports, the remote block lookup will be as follows:
if there is a port specified in the dst of 
saopts (e.g. 172.16.90.1/[590]) the remote block with
this port is preferred for the SA to be established.
if there is no port specified in the dst of saopts, the 
remote block with the default port (specified with the -p switch
when racoon was started or port 500) is preferred. If 
no remote block matching either above ports is found, then
any remote block which fit's to the IP address with
any port is used. Note that a matching port with 'anonymous'
takes precedence over non matching port with matching IP
address.
Nobody really seemed to use a port specification for dst up
to now, because there was a bug in the parser, which I fixed as well.
			
-) ADMIN_GET_SA_CERT
Now since we can have remotes in the config file with same IP
address, but different ports, there will be phase 1 handlers
with the same src and dst IP, but different ph1id.
To decide on the SA, for which the certificate should
be dumped, the ph1id of the must be provided. This is done
indirectly via the remote block. First there is a remote
block lookup like in the example above. ph1id of the 
found remote block is then taken to decide on the SA.
Nobody really seemed to use this racooncfg feature up to now, because the
man page states, that the command should be get-sa-cert, while
it was coded as get-cert. This command does not appear in the usage
output at all.

I did't update the racoonctl man page, because it doesn't cover this level
of detail anyway. I will update the man pages with these details and fix
other bugs there in a later step.

Regards
	Wolfgang

P.S.: I removed the macro getph1bydstaddr(..) completely, because it was
called only once and it made the code less understandable.


-----Ursprüngliche Nachricht-----
Von: Wolfgang Schmieder [mailto:wolfgang@die-schmieders.de] 
Gesendet: Donnerstag, 24. November 2011 06:31
An: 'Timo Teräs'
Cc: ipsec-tools-devel@lists.sourceforge.net
Betreff: Re: [Ipsec-tools-devel] patch supporting several racoon VPNgateways
behind a natt router via different IP ports

Timo,

as a substitute for my 'destinations' approach, I did configure racoon as
you proposed to 
address multiple VPN gateway's behind a NAT router (here your porposal as a
reminder):

-------------------
>The remote block should have sainfo specific variables in them.
>
>The racoon way would be to have two separate remote blocks like (with your
earlier patch):
> remote 172.16.90.1 [590],[4590] {
>   remoteid 1;
> }
> remote 172.16.90.1 [591],[4591] {
>   remoteid 2;
> }
> sainfo anynomous 192.168.90.2/24 {
>   ph1id 1;
> }
> sainfo anynomous 192.168.91.2/24 {
>   ph1id 2;
> }
>
>This way racoon knows which remote is used with which sainfo.
>
>To me the intent of this patch looks completely as overlapping
functionality written in the wrong place.
>
>- Timo
--------------------

With my most recent V2 patch on the 'individual natt ports' and some minor
corrections the final configuration looks as follows:
remote 172.16.90.1 [590] {
  ph1id 1;
  nat_traversal [4590] on;
}
remote 172.16.90.1 [591] {
  ph1id 2;
  nat_traversal [4591] on;
}
sainfo anynomous 192.168.90.2/24 {
  remoteid 1;
}
sainfo anynomous 192.168.91.2/24 {
  remoteid 2;
}

Unfortuneatly racoon couldn't handle this configuration, because the above
remote blocks are treated as duplicates and
the key negotiation is aborted.
getrmconf(..) is retrieving a 'multiple match', because it just uses the
address to distinuish between the first and
second remote block. 

What I had to do was, to make both entries unique for getrmconf(..). I did
this by using the ph1id as a filter when being 
the initiator and by using the port as a filter when being the responder.

So my patch adds an additional filter parameter to getrmconf(..) which has
some implications on getph1(..) and
getsainfo(..) and some other functions.

After applying my patch, the configuration worked perfectly in my testbed (5
Virtual Machines simulating 2 NATT routers,
3 racoon VPN gateways). I think my patch doesn't have bad impact on other
existing configurations.

Man page update comments:

I had a look into the "Remote Nodes Specifications" chapter of the man page
racoon.conf.5 and found the
following description: 
>For received acquires (kernel notices traffic requiring a new SA) the
>remote IP
>and remoteid from matching sainfo block are used to decide the remoteblock.
>If no uniquely matching remote-
>block is found using these criteria, no connection attempt is done.

This is very fuzzy may be almost incorrect, since remote IP and destination
address are different in tunnel mode. 
When you look into the function of isakmp_get_sainfo(..) before my patch,
the description should have been somehow 
like this (still fuzzy but closer to the truth):
For received acquires (kernel notices traffic requiring a new SA) the
destination address of the required SA is used
to decide on the remote block. The security policy which generated the new
SA request and the ph1id of the selected 
remote block is used to decide on the sainfo block. If there is no unique
match for either, no connection attempt is done. 

What I changed with my patch to get my above configuration working is:
For received acquires (kernel notices traffic requiring a new SA) the
security policy
which generated the new SA request is used to decide on the sainfo block.
The remoteid of the selected
sainfo block and the destination address of the required SA are used to
decide on the remote block. If no 
uniquely matching remote block is found using these criteria, no connection
attempt is done.

In short words:
1) the orignal behaviour decides first on the remote block and takes it's
ph1id to look for the sainfo block.
2) the patch does decide on the sainfo block first and uses it's remoteid to
decide on the remote block.
I don't think that the order of checking will cause any issue for existing
configurations, because the 
sainfo block can still only go with it's corresponding remote block.

What I could change if you don't feel comfortable with this is, do the
original check order first, and if
this fails do the check as explained in 2). This would cause a more
complicated description in the
man page. Please let me know.


Another behaviour change will come with my patch which impacts the man page:
>When acting as responder, racoon picks the first proposal that has one or
>more acceptable remote configura-
>tions.  When determining if a remote specification is matching the
following information is checked:
>   ·       The remote IP is checked against remote_address.

needs to be changed to:

When acting as responder, racoon picks the first proposal that has one or
more acceptable remote configurations.  When determining if a remote
specification is matching the following information is checked:
   ·       The remote IP and the reception port is checked against
remote_address and port of the remote block.


My patch will have impact on the following situation. Assume you have:

On node A with IP 172.16.80.2:

remote 172.16.90.2 [1960] {
..
}

listen {
	isakmp 172.16.80.2 [500];
}

On on node B with IP 172.16.90.2:

remote 172.16.80.2 [500] {
..
}

listen {
	172.16.90.2 [500];
}

Without my patch, if node A would act as a responder, the block with the
port 1960 would match even if the
initiator is sending on port 500. With my patch, the port of the remote
block of the first node needs
to be 500 in order to match. I guess it wouldn't impact too may users,
because most of them would go anyway
either with the default ports or would use a consistent port assignment in
their config file.

If you don't feel comfortable, what I could change it similar to what I
described above. I could first 
do the old match strategy, and if it fails with a 'multiple match' error, I
could try the new match strategy 
considering the port. This would require again a more complex man page
description. Please let me know.
   
The patch is based on my previous patch
V2_p4c-p4b_individual_remote_natt_ports.patch.

Regards
	Wolfgang

-----Ursprüngliche Nachricht-----
Von: Timo Teräs [mailto:timo.teras@gmail.com] Im Auftrag von Timo Teräs
Gesendet: Samstag, 12. November 2011 13:48
An: Wolfgang Schmieder
Cc: ipsec-tools-devel@lists.sourceforge.net
Betreff: Re: [Ipsec-tools-devel] patch supporting several racoon VPN
gateways behind a natt router via different IP ports

On 11/08/2011 09:13 PM, Wolfgang Schmieder wrote:
> Now I must somehow tell the racoon client VPN Gateway that it should use
> port 590/4590 for the tunnel to remote network 192.168.90.0/24 and port
> 591/4591 for the tunnel to remote network 192.168.91.0/24.
> 
> Therefore I introduced a configuration extension in cfparse.y/racoon.conf
> which looks as follows:
> remote 172.16.90.1 { ...
> ...    
>     destinations {
>         192.168.90.2/24 [590], [4590]; # [port], [natt port]
>         192.168.91.2/24 [591], [4591]; # [port], [natt port]
>     }
> ...
> }

The remote block should have sainfo specific variables in them.

The racoon way would be to have two separate remote blocks like
(with your earlier patch):
 remote 172.16.90.1 [590],[4590] {
   remoteid 1;
 }
 remote 172.16.90.1 [591],[4591] {
   remoteid 2;
 }
 sainfo anynomous 192.168.90.2/24 {
   ph1id 1;
 }
 sainfo anynomous 192.168.91.2/24 {
   ph1id 2;
 }

This way racoon knows which remote is used with which sainfo.

To me the intent of this patch looks completely as overlapping
functionality written in the wrong place.

- Timo

["p5b-p5a_getrmconf_ambiguous_adminport.patch.tar.bz2" (application/octet-stream)]

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel


[prev in list] [next in list] [prev in thread] [next in thread]