Re: IPsec (isakmpd) in rdomain non zero needs default route
On 2017-09-29, BARDOU Pierrewrote: > 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
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