<div dir="ltr"><div>Well, I have Fossa, but no tap0 interface :-(</div><div><br></div><div>Time to move to Plan B - softether.</div><div><br></div><div>Kevin.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 Apr 2020 at 11:43, Kevin Shackleton <<a href="mailto:krshackleton@gmail.com">krshackleton@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Ian, looks like a project to work on. Maybe the new Ubuntu LTS will *just work* though it's a couple of months away. Cheers, Kevin.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 12 Apr 2020 at 16:41, Ian Kent <<a href="mailto:raven@themaw.net" target="_blank">raven@themaw.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 2020-04-12 at 10:46 +0800, Kevin Shackleton wrote:<br>
> <br>
> The guys wanted a TAP VPN (which CMIIW I understand as a bridging VPN<br>
> whereas a TUN is a routing VPN. I'll try changing the config to a<br>
> TUN and see if my problems disappear . .<br>
<br>
Mmm ... looks like using a tap device will pass Windows broadcasts<br>
through.<br>
<br>
So, good for Windows, but needs scripting on Linux to be able to<br>
use it.<br>
<br>
Maybe setting a WINS server and "pushing" that to the clients with<br>
a "dhcp-options" directive will be enough, not sure. Or set the<br>
remote machine names in a local DNS and set the vpn server to push<br>
the dns server would work, but I think there'll be no network<br>
neighbourhood visibility.<br>
<br>
Or use two vpn servers, one tap for windows clients and one tun for<br>
Linux clients (and add the names to a local hosts file). Still, being<br>
a bridge I think tap clients will send everything over the vpn tunnel<br>
which might not be what you want and probably isn't the best thing to<br>
do.<br>
<br>
You could have a look at (looks pretty comprehensive):<br>
<a href="https://openvpn.net/community-resources/ethernet-bridging/" rel="noreferrer" target="_blank">https://openvpn.net/community-resources/ethernet-bridging/</a><br>
<br>
And<br>
/usr/share/doc/openvpn/sample/sample-scripts/bridge-start<br>
/usr/share/doc/openvpn/sample/sample-scripts/bridge-stop<br>
<br>
described in the above page, used with the up and down ovpn<br>
configuration directives.<br>
<br>
You may well need some iptables setup too ... beware that the down<br>
script might be run in vpn user context (if you used user/group vpn<br>
options) so you may need to use the openvpn-plugin-down-root.so<br>
openvpn plugin to execute it.<br>
<br>
TBH I haven't needed to worry about this stuff, up and down scripts<br>
and user/group configuration is already done for me in the work<br>
configurations and vpn provider configurations assume the vpn will<br>
be used for everything and most block incoming traffic so I just<br>
use a minimal container or secured VM for vpn setups that do allow<br>
incoming connections (like for torrent client seeding).<br>
<br>
Ian<br>
<br>
</blockquote></div>
</blockquote></div>