== An important note if you want to totally stop an IKE IPSec connection

Suppose, hypothetically, that you think [[your IPSec GRE tunnel
IKEForPointToPointGRE]] may be contributing to [[some weird connection
problem you're having IKEAndIPSecNewIssue]]. In order to get it out
of the picture, you want to shut it down ([[which will still leave
you able to reach things ../sysadmin/GRETeardownSecurity]]). There
are three ways you can do this: you can use '_ipsec whack --terminate_'
to ask your local _pluto_ to shut down this specific IKE connection
(which you've engineered to stop the GRE tunnel), you can shut your
local _pluto_ down entirely with '_systemctl stop pluto_' (or
equivalent), or you can stop _pluto_ on both ends.

I will skip to the punchline: if you have no _*protoport_ set (so
that you're doing IPSec on all traffic just because you might as
well), you need to shut _pluto_ down on both ends. Merely shutting
down the IKE IPSec stuff for your GRE tunnel (and taking down the
tunnel itself) will leave the overall IPSec security policy intact
and this policy specifically instructs the kernel to drop any
non-IPSec packets between your _left_ and _right_ IPs. Only shutting
down _pluto_ itself will get rid of the security policy, and you
need to get rid of it on both ends so you need to shut down _pluto_
on both.

(If _pluto_ is handling more than one connection for you on one of
the ends, you're going to need to do something more complicated.
My situation is usefully simple here.)

If you shut down _pluto_ on only one end and then keep trying to
test things, you can get into very puzzling and head-scratching
problems. For instance, if you try to make a connection from the
shut-down side to the side with _pluto_ still running, _tcpdump_
on both ends will tell you that SYN packets are being send and
arriving at their destination but are getting totally ignored despite
there being no firewall rules and so on that would do this.

(If you have a selective _*protoport_ set, any traffic that would
normally be protected by IPSec will be affected by this because the
security policy says 'drop any of this traffic that is not protected
with IPSec'.)

PS: your current IPSec security policies can be examined with
'_setkey -DP_'.  There's probably some way to get a counter of how
many packets have been dropped for violating IPSec security policies,
but I don't know what it is (maybe it's hiding somewhere in '_ip
xfrm_', which has low-level details of this stuff, although
((/proc/net/xfrm_stat)) doesn't seem to be it).