On 2019-01-16, sven falempin <[email protected]> wrote: > On Thu, Jan 10, 2019 at 5:13 AM Stuart Henderson <[email protected]> wrote: >> >> On 2019-01-10, Daniel Ouellet <[email protected]> wrote: >> > I have two separate subnets (on different interfaces) on a router. I am >> > trying to tunnel both subnets over the internet to another router on my >> > network. I can tunnel one subnet easily and everything works as >> > expected, but when I tunnel the 2nd subnet, then traffic from one local >> > subnet is no longer forwarded to the other subnet, but is >> > unconditionally sent into the ipsec tunnel, bypassing the routing table. >> >> OpenBSD's implementation of ipsec doesn't use the routing table, if you >> want that (unless you make code changes) you will need to use a >> different tunnel interface (gif or others) and just use ipsec to protect >> the gif traffic. >> > > Dear all, > > Can someone point out an example of this gif+ipsec setup somewhere ? > > I failed at finding any GIF ref when looking IPSEC+OPENBSD, also man > ipsec does not list gif, only enc.
Briefly, gif(4) is an L3 tunnel interface which can transport IP(v4/v6)/MPLS inside other IP packets. Alternatively there is gre(4) which is a different but similar protocol (actually the docs in the gre manual are a bit more complete so that might be an easier starting point - for this use you can ignore all the EGRE/NVGRE bits - I generally use gif where possible as it has a little lower per-packet overhead, config for gif is similar to gre). These are general purpose tunnel protocols and can run either with or without ipsec - in the case of ipsec you would setup ipsec in transport mode just to protect communications between the addresses of the two routers, and run the tunnel over that. I suggest trying just setting up a simple tunnel without ipsec for starters to get a feel for how it works, when you have it working then look at adding ipsec. (Beware old guides for gif+vether bridges - gif used to be a "dual mode" layer 2 or layer 3 tunnel device - guides using gif+vether were using the L2 mode which has since been moved to etherip - you could also do what you're looking for that way, but it's higher overhead again because you have ethernet *and* a second set of IP headers).
