Trying to move from TUN to TAP configuration

Overkill

Hello all! I'm Overkill...a sysadmin from the moment I sat in front of a computer and until the day I die 🙂

I inherited the responsibility of configuring/maintaining an OpenVPN server to allow access from a satellite office. Said office needs NetBIOS to work, and they previously had a TAP configuration but switched to TUN because (???). I'm switching back to TAP because my understanding is that the bridged interface allows for NetBIOS where a tunnel does not (and the remote office needs to access a Windows share on the LAN). They kept a backup of the old config but it's not working and I'd like some help getting it configured so that it allows my remote users to use features requiring NetBIOS. If I'm wrong and this can be achieved by modifying the tunnel configuration, I'm open to that too ;-) I'm unable to spend the time troubleshooting via Google today, but if anybody can get me started I have a strong Linux background, lots of troubleshooting skill/experience, and generally "get it". Thanks in advance!

> LAN is on 192.168.22.0/24
---> DHCP from router is *.2 to *.125
---> OpenVPN server is at *.65 (DHCP reservation)
> Remote network is on 192.168.1.0/24

The working TUN configuration is this:

port 443
proto tcp
dev tun
topology subnet
ca ca.crt
cert server.crt
key thisisakeyfile.key #keepitsecretkeepitsafe
dh dh1024.pem
server 192.168.22.128 255.255.255.128
ifconfig-pool-persist ipp.txt
push "route 192.168.22.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log-append   openvpn.log
verb 3

The not working TAP configuration is this:

port 443
proto tcp
dev tap0
ca ca.crt
cert server.crt
key thisisakeyfile.key #keepitsecretkeepitsafe
dh dh1024.pem
server-bridge 192.168.22.65 255.255.255.0 192.168.22.192 192.168.22.254
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append   openvpn.log
verb 3
crl-verify crl.pem

Finally, a client configuration looks like this:

client
dev tun
proto tcp
remote our.WAN.IP.addr 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert usercertfile.crt
key userkeyfile.key
comp-lzo
verb 3

Overkill

I just saw this:

**You ONLY want to use dev tap if you are tunneling layer2 traffic, if you are using IP traffic you want tun. If you are using tap only for windows file sharing, look into running a WINS server instead.

Researching this now, but I'd really like to set up my offices so that my two sites are linked together in such a way that it is as if we're on the same network. I'm currently considering migrating all offices to a private class B address so that we can network between a total of 3 offices, our datacenter, and our two cloud services (Azure/AWS)...but this would require downtime and planning that we haven't had the time for...

For now, though, I would like to get the TAP working still since that seems to be the fastest way to get my developers up and running; we just had our primary dev leave the company and we're using the opportunity to allow our programmers to collaborate and use the same servers. Our staging environment is in this office until we can move things to either the datacenter or one of our cloud environments.

Traffic

Windows Network shares are still available via TUN by using:

\\ip.address\sharename

It is only network broadcasts (which Windows Browser relies on) that are not passed over a TUN VPN.

Overkill

Hmmm...thanks

We've been unable to access them at all, perhaps there's something else going on. More research! 😃

Traffic

Before moving to TAP have you considered getting TUN to work properly ?

HOWTO: Expanding the scope of the VPN to include additional machines

Overkill

Okay, so I found out three things:

1) They have a NetGear router that has OpenVPN pre-installed, we're probably going to use that because it's one less thing to manage...
2) Somebody had managed to turn off the computer browser service on the target machine, and turning that on solved the IP problem.
3) WINS/DNS aren't working out very well because the remote office is on a different domain, and the requests are coming through with that domain attached instead of ours, which then go out to Google's DNS since we can't look them up. We had them add static entries for the servers they need access to on their local DNS server, but that's a patchwork solution :/