On 2017-09-29, BARDOU Pierre <bardou.p@mipih.fr> wrote:
> Hello,
>
> I don't know if I should post this to misc@ or bugs@...
> If this is the wrong list tell me I'll file a proper bug report.
>
> I need to add a default route in rdomain 1 to be able to use the tunnels created by isakmpd.
> That is a bit weird, routes should be injected by isakmpd.
It's more of a feature request than a bug - the IPsec implementations on
OpenBSD only work with flows, there isn't a nice way to use them with routes.
It would be extremely useful though, especially in conjunction with dynamic
routing. For example: it would allow a cluster of health-checked IPsec
gateways behind relayd, advertising client routes to the rest of your
network via bgp/ospf. Sure it relies on NAT-T and DPD to notice when a
gateway goes down, but then there's no horrible mess syncing the SADB
between machines.
> My guess is that the problem is quite the same as with inter-domain
> routing with PF : destination lookup is done BEFORE processing by PF or
> IPSEC (explained here for PF :
> https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/).
> So when there is no default route, it fails.
There doesn't need to be a *default* route, but there must be *a* route for
the flow destination.
> If this guess is right, the problem shoud also happen on rdomain 0.
Yes.
> Could you fix the code to make it work without the default route ?
What you propose here would mean changing pieces deep in the network
stack with tentacles in various subsystems.
> Or, as I suspect, is this too difficult and I'll go with my workaround ?
There are ways to get IPsec working with routes, but not really nice ones:
- you can configure a gif or gre tunnel on top of IKE & IPsec transport
mode at both sides, but it's a two-step config, and the other side needs
to support gif/gre.
- you can configure a gif tunnel with IPsec transport mode at one
end, and the other end can be normally configured with tunnel mode if
you like (so you can use some endpoint at the other side that doesn't
explicitly support gif). This works because gif(4) tunnel headers are
*identical* to the IPsec tunnel mode ones. The problem is that this
only currently works on OpenBSD with manual keying, not IKE.
In terms of code changes, I think the best situation would be for an
IPsec daemon to be able to negotiate tunnel mode with the peer via
IKE, but actually install just a "proto ipencap" flow between the two
endpoint hosts (*not* for the tunnel addresses), and create a gif
interface with the correct addressing so the tunnel packets flow.
Note this would be a purely userland change.
The other endpoint would just see a normal tunnel configuration so it
would be perfect for talking to other vendor's implementations.
If it helps illustrate it, here's a worked example with manual flows:
http://bodgitandscarper.co.uk/openbsd/openbsd-ipsec-and-rfc-3884/
No comments:
Post a Comment