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.bonnesen@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.bonnesen@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 deichert@placebonol.com <
> deichert@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
>>
>
No comments:
Post a Comment