[Swan-dev] interop-ikev2-strongswan-39-mobike-responder puzzle

Andrew Cagney andrew.cagney at gmail.com
Sun Nov 4 19:44:09 UTC 2018


I'm puzzled by some of pluto's inner workings when running
interop-ikev2-strongswan-39-mobike-responder.  On the face of it
(console), everything looks straight forward:

road# ipsec auto --up road-eastnet
...
002 "road-eastnet"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADDRESS 192.0.3.1
002 "road-eastnet"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADDRESS 192.0.3.2
002 "road-eastnet"[1] 192.1.2.23 #2: negotiated connection
[192.0.3.1-192.0.3.1:0-65535 0] -> [192.0.2.0-192.0.2.255:0-65535 0]
004 "road-eastnet"[1] 192.1.2.23 #2: STATE_V2_IPSEC_I: IPsec SA
established tunnel mode {ESP=>0xESPESP <0xESPESP
xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=passive}
road #
 ping -W 1 -q -n -c 2 192.0.2.254
PING 192.0.2.254 (192.0.2.254) 56(84) bytes of data.
--- 192.0.2.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time XXXX

In the logs, first the CP payload's first address 192.0.3.1 is used
(matching above):

| #2 road-eastnet[1] parsing ISAKMP_NEXT_v2CP payload
...
"road-eastnet"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADDRESS 192.0.3.1
| setting host source IP address to 192.0.3.1
...
"road-eastnet"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADDRESS 192.0.3.2

but then when it gets to the TS payloads the initiator's connection is
showing the second address (I=192.0.3.2...) - how!

| Checking TSi(2)/TSr(1) selectors, looking for exact match
|   ikev2_evaluate_connection_fit evaluating our
conn="road-eastnet"[1] 192.1.2.23 I=192.0.3.2/32:0/0
R=192.0.2.0/24:0/0  to their:

the code then tries to match the TS's against the connection.  First
it just looks at the IP addresses, and the second TSi matches:

|     tsi[0]=192.0.3.1-192.0.3.1 proto=0 portrange 0-65535,
tsr[0]=192.0.2.0-192.0.2.255 proto=0 portrange 0-65535
|     tsi[1]=192.0.3.2-192.0.3.2 proto=0 portrange 0-65535,
tsr[0]=<invalid>-<invalid> proto=0 portrange 0-65535

so the code then sees of port/protocol match (but completely ignores
the IP address) so the first TSi matches (one with the address that
doesn't match the connection):

| ei->port 0 tsi[tsi_ni].startport 0  tsi[tsi_ni].endport 65535
|       has ts_range1=0 maskbits1=32 ts_range2=8 maskbits2=24 fitbits=8224 <> -1
| prefix fitness found a better match c road-eastnet
|    tsi[0] 0-65535: exact port match with 0.  fitness 65536
|    tsr[0] 0-65535: exact port match with 0.  fitness 65536
|     best ports fit so far: tsi[0] fitrange_i 65536, tsr[0]
fitrange_r 65536, matchiness 131072
|    tsi[1] 0-65535: exact port match with 0.  fitness 65536
|    tsr[0] 0-65535: exact port match with 0.  fitness 65536
|     port_fitness 131072
| port fitness found better match c road-eastnet, tsi[0],tsr[0]
| protocol 0 and tsi[0].ipprotoid 0: exact match
| protocol 0 and tsr[0].ipprotoid 0: exact match
|     best protocol fit so far: tsi[0] fitrange_i 255, tsr[0]
fitrange_r 255, matchiness 510
| protocol 0 and tsi[1].ipprotoid 0: exact match
| protocol 0 and tsr[0].ipprotoid 0: exact match
|     protocol_fitness 510
| protocol fitness found better match c road-eastnet, tsi[0], tsr[0]
| found an acceptable TSi/TSr Traffic Selector

but that's ok 'cos it the stuffs the TSi into the connection forcing
192.0.3.2 back to 192.0.3.1.

| printing contents struct traffic_selector
|   ts_type: IKEv2_TS_IPV4_ADDR_RANGE
|   ipprotoid: 0
|   port range: 0-65535
|   ip range: 192.0.3.1-192.0.3.1
| printing contents struct traffic_selector
|   ts_type: IKEv2_TS_IPV4_ADDR_RANGE
|   ipprotoid: 0
|   port range: 0-65535

It feels like we've two bugs - connection being given wrong address +
TS code matching wrong TS - compensating for each other.

Andrew


More information about the Swan-dev mailing list