[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPsec lookup selects wrong SA



I'm having troubles with the SA lookup, or the IPsec route lookup in the
OpenBSD kernel. I previously ran 2.7 and started seing these problems when
upgrading to 2.9. It seems like the the IPsec route lookup somehow selects the
same SA all the time (for multiple networks behind the same gateway). Between
two OpenBSD boxes nothing happens (except that only one SA and one pair of
SPIs are being used) because they use the same lookup routine, but when I switch
the client to IRE it does not accept the return traffic from some of the
networks as they are being encrypted under the wrong SA by the gateway.

Any suggestions on where I should try to dig this one out in the code? A patch
would be even better :)

Angelos, maybe you are the one to ask?



More details below:
-------------------

I have a test network set up as follows:

 --                           ----                             ------
|  |-10.10.1.2-----10.10.1.1-| GW |-10.10.10.1-----10.10.10.2-|Client|
 --                           ----                             ------

Both the gateway (GW) and the client runs OpenBSD 2.9. I have configured 
isakmpd on the gateway to accept any connections from the client (10.10.10.2)
and the client is configured to set up two connections with 10.10.10.1 as IPsec
gateway:
10.10.10.2/32 to 10.10.1.1/32, gw/peer = 10.10.10.1
and
10.10.10.2/32 to 10.10.1.2/32, gw/peer = 10.10.10.1

This is just one of my test setups, I get the same results when using say
10.10.3.0/24 and 10.10.4.0/24 as destination networks.

When I now fire up the isakmpd on the client it properly sets up the SAs.

However when I start to ping 10.10.1.1 and 10.10.1.2 from the client,
and at the same time look at the output from the kern/ipsec on the gateway
machine, I can see that only one pair of SAs are being used (look at bytes
processed):

Hashmask: 127, policy entries: 4
SPI = b526b811, Destination = 10.10.10.1, Sproto = 50
        Established 0 seconds ago
        Source = 10.10.10.2
        Flags (00001082) = <tunneling>
        Crypto ID: 2
        xform = <IPsec ESP>
                Encryption = <3DES>
                Authentication = <HMAC-SHA1>
        0 bytes processed by this SA
        Expirations:
                Hard expiration(1) in 1080 seconds
                Soft expiration(1) in 960 seconds

SPI = 352f5312, Destination = 10.10.10.1, Sproto = 50
        Established 0 seconds ago
        Source = 10.10.10.2
        Flags (00001082) = <tunneling>
        Crypto ID: 4
        xform = <IPsec ESP>
                Encryption = <3DES>
                Authentication = <HMAC-SHA1>
        20944 bytes processed by this SA
        Expirations:
                Hard expiration(1) in 1080 seconds
                Soft expiration(1) in 960 seconds

SPI = 13398554, Destination = 10.10.10.2, Sproto = 50
        Established 0 seconds ago
        Source = 10.10.10.1
        Flags (00001082) = <tunneling>
        Crypto ID: 3
        xform = <IPsec ESP>
                Encryption = <3DES>
                Authentication = <HMAC-SHA1>
        19992 bytes processed by this SA
        Expirations:
                Hard expiration(1) in 1080 seconds
                Soft expiration(1) in 960 seconds

SPI = 93e55983, Destination = 10.10.10.2, Sproto = 50
        Established 0 seconds ago
        Source = 10.10.10.1
        Flags (00001082) = <tunneling>
        Crypto ID: 1
        xform = <IPsec ESP>
                Encryption = <3DES>
                Authentication = <HMAC-SHA1>
        0 bytes processed by this SA
        Expirations:
                Hard expiration(1) in 1079 seconds
                Soft expiration(1) in 959 seconds

When running this between two OpenBSD boxes you don't spot this easily, as they
tend to lookup the same SA, but when I use a windows client (IRE) it gets
totally confused as to why ping responses are being sent back under a different
SA (when sending to the second network/ip-address).

Any suggestions?

regards
Erik Liden



Visit your host, monkey.org