Re: IPsec (isakmpd) in rdomain non zero needs default route

[Stuart Henderson]

On 2017-09-29, BARDOU Pierre  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/

IPsec (isakmpd) in rdomain non zero needs default route

[BARDOU Pierre]

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.

Here is my test setup :
++
| em1 (rd1):192.168.0.1  em1(rd1)192.168.0.2 |
++   ++
|  rtr1  |   |  rtr2  |
| lo1 (rd1): 127.0.0.1   |   | lo1 (rd1): 127.0.0.1   |
| alias: 192.168.1.1 |   | alias: 192.168.2.1 |
++   ++
on rtr 1 and 2 :
created enc1 rdomain 1 up
launched route -T 1 exec isakmpd -K

tunnel conf rtr 1:
ike esp from 192.168.1.0/24 to 192.168.2.0/24 local 192.168.0.2 peer 
192.168.0.2 \
main auth hmac-md5 enc 3des group modp1024 lifetime 28800 \
quick auth hmac-md5 enc 3des group modp1024 lifetime 3600 psk "deadbeef"

tunnel conf rtr 2:
ike esp from 192.168.2.0/24 to 192.168.1.0/24 local 192.168.0.2 peer 
192.168.0.1 \
main auth hmac-md5 enc 3des group modp1024 lifetime 28800 \
quick auth hmac-md5 enc 3des group modp1024 lifetime 3600 psk "deadbeef"

routing table rt1 :
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo1
192.168.0/24   192.168.0.1UCn10 - 4 em1
192.168.0.100:50:56:b4:7b:eb  UHLl   0   37 - 1 em1
192.168.0.200:50:56:b4:77:82  UHLc   1   16 - 3 em1
192.168.0.255  192.168.0.1UHb00 - 1 em1
192.168.1.1192.168.1.1UHl07 32768 1 lo1

routing table rt2 :
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo1
192.168.0/24   192.168.0.2UCn00 - 4 em1
192.168.0.200:50:56:b4:77:82  UHLl   0  245 - 1 em1
192.168.0.255  192.168.0.2UHb00 - 1 em1
192.168.2.1192.168.2.1UHl0   52 32768 1 lo1

flows rtr1 :
# route -T1 exec ipsecctl -sf
flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer 192.168.0.2 srcid 
192.168.0.1/32 dstid 192.168.0.2/32 type use
flow esp out from 192.168.1.0/24 to 192.168.2.0/24 peer 192.168.0.2 srcid 
192.168.0.1/32 dstid 192.168.0.2/32 type require

flows rtr2 :
# route -T1 exec ipsecctl -sf
flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer 192.168.0.1 srcid 
192.168.0.2/32 dstid 192.168.0.1/32 type use
flow esp out from 192.168.2.0/24 to 192.168.1.0/24 peer 192.168.0.1 srcid 
192.168.0.2/32 dstid 192.168.0.1/32 type require

On rtr1 :
ping -V 1 -I 192.168.1.1 192.168.2.1 
won't work until I do on both routers :
route -T1 add default 127.0.0.1

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. If this guess is right, the 
problem shoud also happen on rdomain 0.

Could you fix the code to make it work without the default route ?
Or, as I suspect, is this too difficult and I'll go with my workaround ?

--
Cordialement,
Pierre Bardou