Consider east which has this OE configuration in newoe-25-cat-1: conn oe-base-server type=tunnel left=%defaultroute authby=null leftid=%null rightid=%null right=%opportunisticgroup leftaddresspool=10.0.10.1-10.0.10.200 leftmodecfgclient=yes narrowing=yes leftcat=yes conn private-or-clear also=oe-base-server failureshunt=passthrough negotiationshunt=passthrough auto=ondemand
when added msgcfg.{client,server} are set as expected: | pool 10.0.10.1-10.0.10.200: reusing existing address pool@0x7f82910d3f98; pool-refcount 1 size 200 leases 0 in-use 0 free 0 reusable 0 | addref struct addresspool@0x7f82910d3f98(1->2) (addresspool_addref() +713 /programs/pluto/addresspool.c) | forcing leftmodecfgclient=true rightmodecfgserver=true (the address pool is saved in the global c->pool; hold that thought) it is then oriented: | orienting "private-or-clear" | interface endpoint 192.1.2.23:500 matches left(THIS); orienting but notice how LEFT matches the local interface which means that the connection a CLIENT. Next road(?), a true client, hits on east. Things progress to the IKE_AUTH child code where east is (still) a client: | left server = no; left client = yes (local) | right server = yes; right client = no (remote) but, because c->pool is "global", east instead acts like a server and gives out one of its addresses. so is this OE connection a client, server, or something else _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev