Hello all,
I have seen from http://wiki.strongswan.org/projects/strongswan/repository/revisions/master/changes/src/pluto/ipsec_doi.c that the sequence of code below is present in strongswan project code since the file was under version control. static stf_status quick_inI1_outR1_tail(struct verify_oppo_bundle *b, struct adns_continuation *ac) { ......................... if ((st->nat_traversal & NAT_T_DETECTED) && (st->st_esp.attrs.encapsulation == ENCAPSULATION_MODE_TRANSPORT) && (c->spd.that.has_client)) { /** Remove client **/ addrtosubnet(&c->spd.that.host_addr, &c->spd.that.client); c->spd.that.has_client = FALSE; } ......................... } I wanted to ask you if you know the reason behind this change, becouse I get some problems at rekey time, in the case when the initial IPSec responder, initiates the Quick Mode to re-establish the Phase 2 SA, as a result of Phase 2 SA lifetime expiration. The problem is that the client address of the peer gets changed for the connection, and when the connection initiator receives the first Quick Mode message from the responder (that is now the initiator) the following situation arise: // This is on the initial initiator, now the responder of the first Quick Mode message from initial responder. ................................. | ***parse ISAKMP NAT-OA Payload: | next payload type: ISAKMP_NEXT_NONE | length: 12 | ID type: ID_IPV4_ADDR | removing 4 bytes of padding | HASH(1) computed: | c9 03 43 ba 50 ce 55 c7 8d fa 55 58 aa ed ad 66 | ###### CUSTOM_DEBUG: quick_inI1_outR1 conn:ixtun00168 this.client.addr:13.1.0.174 that.client.addr:14.1.0.174 | peer client is subnet 14.1.0.174/32 | peer client protocol/port is 0/0 | our client is subnet 14.1.0.1/32 | our client protocol/port is 0/0 | find_client_connection starting with ixtun00168 | looking for 14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 | concrete checking against sr#0 13.1.0.174/32 -> 14.1.0.174/32 | match_id a=14.1.0.174 | b=14.1.0.174 | results matched | trusted_ca called with a=(empty) b=(empty) | fc_try trying ixtun00168:14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 vs ixtun00168:13.1.0.174/32:0/0 -> 14.1.0.174/32:0/0 | fc_try concluding with none [0] | fc_try ixtun00168 gives none | checking hostpair 13.1.0.174/32 -> 14.1.0.174/32 is not found | concluding with d = none | ###### CUSTOM_DEBUG: quick_inI1_outR1_authtail set me.client.addr:14.1.0.1 ###### CUSTOM_DEBUG: quick_inI1_outR1_authtail set he.client.addr:14.1.0.174 "ixtun00168" #1339: cannot respond to IPsec SA request because no connection is known for 14.1.0.1/32===13.1.0.174:4500[S?C]...14.1.0.174:4500[S?C] | =>complete_state_transition ............................. The check: fc_try trying ixtun00168:14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 vs ixtun00168:13.1.0.174/32:0/0 -> 14.1.0.174/32:0/0 should be fc_try trying ixtun00168:14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 vs ixtun00168:13.1.0.174/32:0/0 -> 13.1.0.174/32:0/0. If the responder would have not removed the client in the code snapshot above, then the problem would not arise. That's why I wanted to ask you if you know the real reason behind that code. If not completely remove, maybe we may add a new check for NAT_TRAVERSAL_NAT_BHND_ME, or we may skip removing the client in the test. Waiting for your reply. Thank you, Daniel. _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
