On Tue, Feb 17, 2026 at 03:04:14AM +0000, H. Hartzer wrote: > On Fri Feb 13, 2026 at 3:42 AM UTC, David Gwynne wrote: > > there's a lot to work through here. the most important detail is > > how your /28 is delivered to you. > > > > hopefully your ISP routes the /28 to you rather than expecting you > > to put all the hosts using that IP on the link to the ISP. if it's > > the latter and you want a single firewall facing the ISP, then > > you'll need proxy arp, but our (openbsds) implementation isn't in > > good shape at the moment. > > > > if they route the /28 to you, then you can split up the IPs and > > route them independently. ie, you don't need to use /30s and burn > > up the provided ips on links between the hosts. this is especially > > true for point to point links (like gif) where the ips on each end > > can be discontiguous. > > > > eg, let's assume the ISP talks to your router with a public ip on > > your wan interface, and routes 203.0.113.0/28 to you via that ip. > > if that is the situation, then you could just put the /28 on a common > > ethernet network all your backend hosts sit on. you will lose 2 of the > > IPs in the /28 to the broadcast and network address though. > > > > if you want the router act as a hub and your hosts as spokes so all > > ipv4 communication goes through the router, you could do something > > like this with gif interfaces over v6: > > > > router# cat /etc/hostname.gif1 > > tunnel fd40:6ed3:97ff::1:0 fd40:6ed3:97ff::1 > > inet 169.254.0.1 255.255.255.255 203.0.113.1 > > up > > router# cat /etc/hostname.gif2 > > tunnel fd40:6ed3:97ff::1:0 fd40:6ed3:97ff::2 > > inet 169.254.0.2 255.255.255.255 203.0.113.2 > > up > > > > then on the hosts: > > > > host1# cat /etc/hostname.gif1 > > tunnel fd40:6ed3:97ff::1 fd40:6ed3:97ff::1:0 > > inet 203.0.113.1 255.255.255.255 169.254.0.1 > > up > > host1# cat /etc/mygate > > 169.254.0.1 > > > > host2# cat /etc/hostname.gif2 > > tunnel fd40:6ed3:97ff::2 fd40:6ed3:97ff::1:0 > > inet 203.0.113.2 255.255.255.255 169.254.0.2 > > up > > host2# cat /etc/mygate > > 169.254.0.2 > > > > if you want the router to use one of these ips too, you can assign it to > > a loopback interface: > > > > router# cat /etc/hostame.lo1 > > inet 203.0.113.0 255.255.255.255 > > up > > > > there are a lot of alternatives to this too though. > > Hi David, > > Thank you so much for your help! That is working for me! > > The IP allocation is currently on the same link, so I do have to ARP > proxy. This is working for me, but I have to do arp -s (my wan mac) > (ipv4) before bringing up the gif interface (or Wireguard.)
boo :( > I can tell it uses less CPU on the router, however it also seems a > little bit slower than Wireguard? I am not sure why. I played with MTU > and fragmentation settings, but no notable impact. I think it's fast > enough for my use, though. that is surprising. i haven't spent any time trying to optimise the pseudo interfaces that tunnel over ip (eg, gif, gre, etherip, etc), but that should include wireguard. > Did not know that these tunnel interfaces supported point to point IP > networking like that. Very handy > > Sincerely, > > Henrich
