> > 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.
Please forgive me, I still don't get it, To me, it seems that even if those
subnets are single IPs (/32), they're still ANY IPs. I'd assume that a
config with
left=%defaultroute
right=%any
and
leftprotoport=tcp/%any
rightprotoport=tcp/22
on a client machine would allow me to SSH (tcp/22) from that particular
host to %any other, perhaps just not allowing to passthrough SSH to any
further hosts on the same subnet that the right participant might be
forwarding (routing, NATting, ...) to or forwarding to the right
participant for others. Which is obviously not the case, according to
what you write.
> > 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.
I sure can leave SSH to nftables, and I probably will. This was likely a
question asked one step too early in the process. However, it comes
again right in the next step.
In order to move on and to avoid confusion, I changed the privlan-ssh conn
to use right=%any, as you advise. As expected, SSH access works, this time
already without any opportunistic encryption involved on either end.
Now I am going to get rid of opportunistic encryption for the ipsec part
itself. On host.privlan I just removed the policy file and replaced
right=%opportunisticgroup with right=192.168.1.253. Everything works.
The next step would be to adjust right= on server.privlan accordingly -
but to what? Obviously, I could use right=%any - but I will need this
option in the future to configure a different connection for the
roadwarriors. Which brings me back to the question of how to distinguish
between those connections?
Any hints? Am I perhaps completely missing the basic concept?
> 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.
Great :-( From my recent experience, I tend to spend WAY more
time getting legit mail through and tracing lost messages for my users
than dealing with spam complaints.
Many thanks!
Phil
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
