As far as I remember, I could only get gre to work over wg. Anything that is ethernet (like tmpr, etherip, etc) didn't work. My wild guess is that packet overhead is becoming to big as there is a lot of encapsulation. Also, wg interfaces do not have same features like normal interfaces so for example you can't add them to bridges and the like.
On Friday, January 20, 2023 at 08:48:58 a.m. GMT+9, Lars Bonnesen <lars.bonne...@gmail.com> wrote: I have been fighting with this for a while now, trying to make it work reading man pages... But it does not work as I want it to work. tcpdump can see a lot of arp requests on bridge0, egre0, vlan172 - but nothing seems to get to wg0. This is my ifconfig filtered for public IPs: lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768 index 5 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:50:56:b4:a5:ab index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (10GbaseT) status: active inet qq.ww.ee.rr netmask 0xffffff00 broadcast ee.rr.tt.yy vmx1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:50:56:b4:0d:26 index 2 priority 0 llprio 3 media: Ethernet autoselect (10GbaseT) status: active vmx2: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1600 lladdr 00:50:56:b4:ef:b4 description: corp index 3 priority 0 llprio 3 media: Ethernet autoselect (10GbaseT) status: active enc0: flags=0<> index 4 priority 0 llprio 3 groups: enc status: active pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136 index 6 priority 0 llprio 3 groups: pflog lo1: flags=8008<LOOPBACK,MULTICAST> rdomain 1 mtu 32768 index 8 priority 0 llprio 3 groups: lo wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420 index 9 priority 0 llprio 3 wgport 51820 wgpubkey GIWFxfaaxt1VmURRvEtJkG/mZQgVLNtHuEtPa6vt/kM= wgpeer MSS4DjJjPtp9DsTpMbNQ1ict6jEx07DICfipOpnOUR4= wgendpoint aa.bb.cc.dd 51820 tx: 1690108800, rx: 2934539600 last handshake: x seconds ago wgaip 192.168.5.1/32 groups: wg inet 192.168.5.2 netmask 0xffffff00 broadcast 192.168.5.255 egre0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 lladdr fe:e1:ba:d0:31:5b index 14 priority 0 llprio 3 encap: vnetid 172 txprio 0 rxprio packet groups: egre tunnel: inet 172.24.90.92 --> 172.24.90.91 ttl 64 nodf vlan172: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:50:56:b4:ef:b4 index 24 priority 0 llprio 3 encap: vnetid 172 parent vmx2 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (10GbaseT) status: active inet 172.24.90.94 netmask 0xffffff00 broadcast 172.24.90.255 bridge0: flags=41<UP,RUNNING> mtu 1500 index 25 llprio 3 groups: bridge priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp vlan172 flags=3<LEARNING,DISCOVER> port 24 ifpriority 0 ifcost 0 egre0 flags=3<LEARNING,DISCOVER> port 14 ifpriority 0 ifcost 0 vmx2 flags=3<LEARNING,DISCOVER> port 3 ifpriority 0 ifcost 0 On the other end the ifconfig is similar wg0 is working. I can ping 192.168.5.1 from 192.168.5.2 and visa versa. 172.24.90.0/24 (vlan172) is the network that I want to strech... and is presented to the obsd as vmx2 connected to an access port on a switch Can anyone guide me in the right direction, thx? Regards, Lars. On Wed, Jan 4, 2023 at 7:24 AM Lars Bonnesen <lars.bonne...@gmail.com> wrote: > Thanks for your replies. It has been Xmas and I have been delayed, but I > have now read up upon it. I am going for the tpmr(4). We are going to > replicate a lot of live data from Site1 to Site2, and my experiences with > OpenVPN is that it is great, but not high performing. So I have established > a WireGuard connection with one OBSD on each site, and I am planning to > tunnel tpmr through this - I guess that tpmr itself is not encrypted in any > way? > > Regards, Lars. > > On Fri, Dec 16, 2022 at 4:30 PM deich...@placebonol.com < > deich...@placebonol.com> wrote: > >> I've run L2 over an IPsec tunnel using egre (gre(4)) and bridge (bridge >> (4)) to connect systems in different locations together. >> >> This was done before David Gwynne created tpmr(4). I've been to lazy to >> reimplement my current configuration. >> >> 73 >> diana >> >