Re: [Ipsec-tools-users] Problem when setup SA with port manually using setkey

[Mick <mic...@gm...>]

Hi Nideson,

I am not sure why the port is zero'ed when you add the second SA and what 
parameters take precedence between SAs and SPs.  This is beyond my limited 
knowledge and may require a developer to answer it; or someone who's more 
knowledgeable on how the kernel determines SA priorities; or at least some 
patient experimentation with different values.

I would at least try specifying ports only on SPs, then only on SAs, then on 
both to see if it changes anything.

As I understand it, an outgoing packet will follow the SPD directive to 
determine if it needs to be processed further.  What type of processing will 
take place thereafter is then determined by any suitable SAs.  Suitability is 
established by matching the content of packet headers with candidate SAs.  I 
think these checks consist of SPI, dst IP and protocol selectors (actually 
their hashes) to determine a corresponding SA.  The dst includes the port in 
this case, but I don't know if the port is included in the hash - so I would 
not omit this in the first instance.

The SP *must* match the header of the packet exactly, or it won't be processed 
further by IPSec.  SPD entries are checked for matching selectors, 
sequentially and in order of priority.  So, as soon as a SPD entry's selectors 
are matched it will proceed to be processed by an SA.

The inbound packets are first matched against an SA (the outer IP address is 
used, then IPsec protocol, and SPI) and if selectors are matching the packet 
is processed and authenticated/decrypted.  Then the next header is checked to 
determing the inner IP address and the process is repeated.  If it requires no 
further decryption it is matched against an SPD entry and routed accordingly.

Unless your experiments lead you to some combination of SPIs/port selectors 
that work as intended, I would suggest to try using the -u <number> option 
when specifying SAs and the //unique:<number> parameter when you set up SPD 
entries so that you bind a particular SA to a corresponding SP.  

Hope this helps.


On Wednesday 31 Jul 2013 02:43:16 SUN Nideson wrote:

> Following your suggestion, I run CLI with -v option.
> 
> And the configure file is accepted without error.
> 
> 
> 
> But I found that, each SA is manipulated twice on PF_KEY socket. Please see
> blow verbose info.
> 
> 
> 
> For the first time, port number is consistent with the configure file.
> 
> But the second time, port number is reset to 0.
> 
> 
> 
> Do you know why?
> 
> 
> 
> sadb_msg{ version=2 type=3 errno=0 satype=3
> 
>   len=19 reserved=0 seq=0 pid=28201
> 
> sadb_ext{ len=4 type=9 }
> 
> sadb_key{ bits=192 reserved=0
> 
>   key= 00000203 40000000 02001300 00000000 00000000 00000000 }
> 
> sadb_ext{ len=3 type=8 }
> 
> sadb_key{ bits=128 reserved=0
> 
>   key= 02009dda 8702cfcb 00000000 00000000 }
> 
> sadb_ext{ len=2 type=1 }
> 
> sadb_sa{ spi=1445 replay=0 state=0
> 
>   auth=2 encrypt=3 flags=0x00000040 }
> 
> sadb_ext{ len=2 type=19 }
> 
> sadb_x_sa2{ mode=0 reqid=0
> 
>   reserved1=0 reserved2=0 sequence=0 }
> 
> sadb_ext{ len=3 type=5 }
> 
> sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
> 
> sockaddr{ len=16 family=2 port=40410
> 
> 8702cfcb  }
> 
> sadb_ext{ len=3 type=6 }
> 
> sadb_address{ proto=255 prefixlen=32 reserved=0x0000 }
> 
> sockaddr{ len=16 family=2 port=60410
> 
> 87025795  }
> 
> 
> 
> 
> 
> sadb_msg{ version=2 type=3 errno=0 satype=3
> 
>   len=34 reserved=0 seq=0 pid=28201
> 
> sadb_ext{ len=2 type=1 }
> 
> sadb_sa{ spi=1445 replay=0 state=1
> 
>   auth=2 encrypt=3 flags=0x00000000 }
> 
> sadb_ext{ len=4 type=3 }
> 
> sadb_lifetime{ alloc=0, bytes=0
> 
>   addtime=0, usetime=0 }
> 
> sadb_ext{ len=4 type=4 }
> 
> sadb_lifetime{ alloc=0, bytes=0
> 
>   addtime=0, usetime=0 }
> 
> sadb_ext{ len=4 type=2 }
> 
> sadb_lifetime{ alloc=0, bytes=0
> 
>   addtime=1375152843, usetime=0 }
> 
> sadb_ext{ len=3 type=5 }
> 
> sadb_address{ proto=0 prefixlen=32 reserved=0x0000 }
> 
> sockaddr{ len=16 family=2 port=0
> 
> 8702cfcb  }
> 
> sadb_ext{ len=3 type=6 }
> 
> sadb_address{ proto=0 prefixlen=32 reserved=0x0000 }
> 
> sockaddr{ len=16 family=2 port=0
> 
> 87025795  }
> 
> sadb_ext{ len=3 type=7 }
> 
> sadb_address{ proto=255 prefixlen=0 reserved=0x0000 }
> 
> sockaddr{ len=16 family=2 port=0
> 
> 00000000  }
> 
> sadb_ext{ len=3 type=8 }
> 
> sadb_key{ bits=128 reserved=0
> 
>   key= 00000000 00000000 00000000 00000000 }
> 
> sadb_ext{ len=4 type=9 }
> 
> sadb_key{ bits=192 reserved=0
> 
>   key= 00000000 00000000 00000000 00000000 00000000 00000000 }
> 
> sadb_ext{ len=2 type=19 }
> 
> sadb_x_sa2{ mode=1 reqid=0
> 
> 
> 
> And regarding your question.
> 
> >           ## SP, in file spdb.conf
> >           
> >           spdadd 135.2.87.149[60410] 135.2.207.203[40410] any -P out
> >           ipsec
> > 
> > esp/transport//require ;
> > 
> > spdadd 135.2.207.203 135.2.87.149[50411] any -P in ipsec
> > 
> > esp/transport//require ;
> 
> Have you omitted the port for 135.2.207.203 on purpose in the above?
> 
> 
> 
> [NDS] Yes, I omit the port for 203 on purpose. Does the SP configuration
> impact the SA?
> 
> I tried adding the port to 207.203, and got the same result.
> 
> > spdadd 135.2.87.149[50411]
> > 
> > 135.2.207.203[30411] any -P out ipsec esp/transport//require ;
> > 
> > spdadd 135.2.207.203 135.2.87.149[60410] any -P in ipsec
> > 
> > esp/transport//require ;
> 
> Again, have you omitted the port for 135.2.207.203 on purpose here too?
> 
> [NDS] Yes, Same as above.
> 
> > After I run "sudo setkey -f sadb.conf" and "sudo setkey -f spdb.conf".
> > 
> > And display the SAs using "sudo setkey -Dp", I found the port numbers are
> > 
> > all 0 instead of what I configured.
> 
> I think that if you run setkey with just -D it will show you what ports are
> 
> actually being used by the connection, rather than what the kernel is able
> to
> 
> set/accept connections from.  The 135.2.87.149[0] notation is a wildcard
> for
> 
> any ports.  Have you confirmed that the correct ports are being used with
> 
> tcpdump?
> 
> [NDS] Yes, the real socket connection uses the correct port. But the SA is
> not selected based on the port.
> 
> 
> 
> So after I set up two SAs on 135.2.87.149:
> 
> 1) 135.2.87.149[50411] --> 135.2.207.203[30411]
> 
> 2) 135.2.87.149[60410] --> 135.2.207.203[40410]
> 
> 
> 
> The #1 SA will always be selected no matter when I send message from port
> 50411 to 30411,
> 
> Or from port 60410 to 40410.
> 
> > Whenever message is sent from 87.149 to 207.203, the SA with spi 8445
> > will
> > 
> > be used, as it is displayed as the first one from server 87.149 to server
> > 
> > 207.203. But actually, the message is sent from 87.149[50411] to
> > 
> > 207.203[30411], the SA with spi 8440 shall be used.
> 
> See if this problem remains, after you enter ports consistently for both
> 
> endpoints in your spdb.conf and after you check that corresponding SA ports
> 
> and policies have been set up in the other server too.
> 
> [NDS] I have tried this several times between two Linux servers, or one
> Linux server and one solaris server.
> 
> The result is same. So I wonder if the port can be supported in SA setup. I
> will try it more.
> 
> 
> 
> Have a nice day,
> 
> Nideson

-- 
Regards,
Mick