Hi Martin. >> I do not understand why port 4500 is used. I shouldn't have a NATed >> setup. > A MOBIKE enabled peer always switches to port 4500 for IKE_AUTH, this is > the intended behavior. Ah I see :)
Just out of curiosity: In both cases (I mean 500 and 4500) I cannot make firewall rules to just allow udp with sport and dport 500 udp with sport and dport 4500 but each only with dport 500/4500, right? Because with NAT the sport can be different anyways (due to the NAT) and with non-NAT the port 500 seems to be configurable in strongswan. Is the port 4500 also configurable? > Looks like a bug if reauth=yes is used in conjunction with > dpdaction=restart and uniqueids=yes. If an IKE_SA is deleted for some > reason, the responding peer tries to reestablish the same with the > restart action. However, the peer deleting the SA actually does a > reauthentication by close-and-reestablish, resulting in redundant > IKE_SAs. This probably triggers the unique checking of an IKE_SA, and > again, deletes one of them. Just for my understanding: rekey = yes is important, or otherwise my connections will be closed after the end of the key lifetime. reauth = yes means just that if a rekey happens, than the authentication (e.g. via certificates) is also re-done. Right? And I guess I (in my scenario) need the dpdaction=restart (in conjunction with the keyingtries = %forever) to guarantee that a connection is no simply closed once the peer becomes) temporarily unavailable or has some problems in setting it up again. So reauth=no is the only "solution" for me for now?! > The main issue here is the problematic reauthentication procedure > defined by the IKEv2 protocol. I'd highly recommend to disable it with > reauth=no, as it is usually useless from a security perspective if the > user does not have to reenter his credentials manually. Mhh ok,.. yeah,.. perhaps with one exception, that one peer looses his credentials (the cert) completely, or it expires?! > There is currently a discussion about a proper reauthentication > extensions for IKEv2 on the IPsec mailing list. We probably should drive > that thing forward and fix all the problems resulting from > reauthentication. Ok :) btw: is there some bug-tracker for strongswan, where one could hook up such issues in order to allow end users (like me) to some how trace these things better? Thanks, Chris. _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
