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.) 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. Did not know that these tunnel interfaces supported point to point IP networking like that. Very handy Sincerely, Henrich
