On Thu, 4 Jul 2019 at 12:49, Paul Wouters <[email protected]> wrote: > > On Thu, 4 Jul 2019, Andrew Cagney wrote: > > > The code is roughly: > > > > for st in all states do: > > if ((IS_CHILD_SA(nfo_st) && > > (st->st_serialno == nfo_st->st_clonedfrom || > > st->st_clonedfrom == nfo_st->st_clonedfrom)) || > > st->st_serialno == nfo_st->st_serialno) { > > do stuff > > } > > > > if I transform the if() I get: > > > > if ((IS_CHILD_SA(nfo_st) && st->st_serialno == nfo_st->st_clonedfrom) || > > (IS_CHILD_SA(nfo_st) && st->st_clonedfrom == nfo_st->st_clonedfrom) > > || > > st->st_serialno == nfo_st->st_serialno) > > > > which makes me suspect it is looking for: > > > > - nfo_st's IKE SA > > - nfo_st's siblings > > - and of course nfo_st > > > > or in other words it wants to 'do stuff' on ST's entire family? I > > guess that makes sense, just not very efficient. > > I think this case is when the initial IKE packet comes from a different > port. The client is behind NAT, uses port 500 and gets NAT'ed to port > 3276x. And then it detects NAT and switches to port 4500, but then of > course the NAT gateway will NAT it to another port. > > My guess is this code updates the ports in the struct st for that, > although it is a bit scary it might also update the IP address. And > the child states should never use the state port/interface anything I > think - it should only be stored in the actual IKE states that need it.
I suspect it updates children as, in IKEv1 they are allowed to out live their parent. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
