On Fri, 9 Feb 2024, Phil Nightowl wrote:
Along your advice, I changed the config files on host1.privlan (applicable
to any host on my 192.168.1.x except server.privlan). SSH access is fixed,
the config on host1.privlan does not use opportunistic encryption any longer
and works fine. Adding
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
did help. Could you please explain why it did and how? The man page doesn't
mention 0.0.0.0/0. On the other hand, it does say that "if
[leftsubnet/rightsubnet is] omitted, essentially assumed to be left/32,
In your case, you wanted ssh to never be caught up in IPsec, so using
0.0.0.0/0 ensures it matches all IPs, so the ssh exception always hits.
Think of type=passthrough as a firewall rule within the IPsec subsystem
that is basically iptables -j RETURN.
Without these, you would only match a single left and right IP/32, and
when using right=%any that would become 0.0.0.0/32 which is a single IP
address.
Now for server.privlan. To begin with the easier part (SSH), to switch away
from opportunistic encryption I think I need
conn privlan-ssh
type=passthrough
left=%defaultroute
auto=ondemand
authby=never
leftprotoport=tcp/22
rightprotoport=tcp/%any
plus possibly(?)
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
However, I should add something instead of
right=%any
since I probably don't want to allow SSH from all hosts to get through. That
was actually my second reason to use opportunistic encryption. The man page
the left/right does not really matter if you specify the subnets. Then
those left/right's are the tunnel endpoints, but type=passthrough is not
really a tunnel with endpoints.
says that left/right accepts IPs, FQDNs and magic values. So I assume I
cannot use netmasks here. How can I (without opportunistic encryption)
select only certain hosts to pass SSH through? That is probably only a
specific form of a general question: how do I distinguish between different
configs with identical left participant (server) without listing each
individual right participant explicitly?
Ok if you want that, you could use a complicated opportunistic setup,
but you would need to sync those passthrough policies every time you add
a node or subnet. but honestly, at that point you should do this at the
firewall level using iptables/nftables. The reason people usually leave
out ssh is so that they don't do double encryption or that they want ssh
to work if the IPsec policies/state has locked them out and they need to
ssh in to fix it. So configuring that within IPsec with opportunistic
would still run the risk of locking you out.
Check your spam folder. Google enforced SPF/DKIM on all mail, as in they
started refusing large amounts of emails. We did fix the libreswan lists
to do this, so likely this is no longer happening to you.
For me, it seems that Google doesn't refuse the messages, but marks them as
spam anyway.
They changed their policy two days ago, and started bouncing those
messages now. We got 100+ messages bounces back from the libreswan list
until we enabled dkim for the lists.libreswan.org domain.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
