On Fri, Jan 20, 2023 at 12:48:33AM +0100, Lars Bonnesen 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?
sure. the first thing i would like to point out is that you want wg to protect the egre traffic, so you should set the egre tunnel addresses to the IPs you've set up inside wg. right now you're trying to use IPs from the network you're trying to stretch as the tunnel enspoints, which, as the gre manpage says, is not going to work. the gre manpage also has points out that egre also needs the net.inet.gre.allow sysctl set 1. so, this is a good step: # sysctl net.inet.gre.allow=1 # ifconfig egre0 tunnel 192.168.5.2 192.168.5.1 # ifconfig egre0 up you can do that in /etc/sysctl.conf and /etc/hostname.egre0 too. the second thing to clean up is how vlan172 is wired up to the tunnel. while bridge(4) can do it, i think there are better options now so i would tear that down. if this box does not need to interact with traffic inside the vlan, ie, its only job is to stretch the traffic, then you can use tpmr(4) to plug them together: # ifconfig tpmr0 create # ifconfig tpmr0 add vlan172 add egre0 # ifconfig tpmr0 up if this box does need to do stuff on the 172.24.90.0/24 network, then veb(4) and vport(4) are better: # ifconfig vport0 create # ifconfig vport0 inet 172.24.90.94/24 # ifconfig vport0 up # ifconfig veb0 create # ifconfig veb0 add vport0 vlan172 egre0 # ifconfig veb0 up that should work, or should be a big step closer. > > 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 > >> > >
