Enableing TAP rather than TUN help

[steve288]

Have successfully used my Asus RT-AC66U B1 to access my network via OpenVPN. This comes through the ISP's router then to the Asus router. Works great. I use TUN. I can access computers, use remote desktop etc.
Ok so it does not work perfectly in one case. I use a program called EZVIS to search for my Hikvision camera at home. It works fine when I'm at home locally. But it does not work over an OpenVPN connection.

Someone has said this MAY be because Multicast does not work on VPN connections. So tries to find the device but cannot. The program sadly does not allow me to put in an IP address that I know of. Then Others said well if you set up TAP rather than TUN VPN this may work. So I went to router clicked drop down box in OpenVPN server tab and set it to TAP. I then tried to connect with my clients and it would not connect.

There may be many helpful things you all may say and I welcome them. However the one question I do have is, do i have renew my certificate and export, and import into the client again a new .ovpn file. I did try to switch to TAP applied then tried to use my existing clients, but this did not work. There does not seem to be any way in the client software to changed from TAP to TUN.
Thank you.
PS current firmware is Current Version : 3.0.0.4.386_51685-gd1be76f

 

[ColinTaylor]

Yes you have to export the .ovpn file again and import it on the client device. You might get away with just editing the original .ovpn file and changing the dev tun line.

IIRC Apple devices don't allow tap mode.

 

[steve288]

Thank you. I dont have apple thank goodness.
Regards

 

[eibgrad]

It's been ages since I used an Android device, but way back when I last did, neither Apple nor Android supported bridged (TAP) OpenVPN tunnels. I've had others suggest you can w/ Android provided you're willing to use third-party repositories, or likewise w/ a jail-broken Apple device, but I've never confirmed it personally.

This is why for road warriors, it might be a good idea to configure a travel router that manages the OpenVPN bridged client, thus acting as a middleman between the mobile device and the server.

 

[steve288]

It's been ages since I used an Android device, but way back when I last did, neither Apple nor Android supported bridged (TAP) OpenVPN tunnels. I've had others suggest you can w/ Android provided you're willing to use third-party repositories, or likewise a/ a jail-broken Apple device, but I've never confirmed it personally.

This is why for road warriors, it might be a good idea to configure a travel router that manages the OpenVPN bridged client, thus acting as a middleman between the mobile device and the server.

mm well that would be disappointing. I will test and see what happens, thank for your advice.

 

[steve288]

It's been ages since I used an Android device, but way back when I last did, neither Apple nor Android supported bridged (TAP) OpenVPN tunnels. I've had others suggest you can w/ Android provided you're willing to use third-party repositories, or likewise w/ a jail-broken Apple device, but I've never confirmed it personally.

This is why for road warriors, it might be a good idea to configure a travel router that manages the OpenVPN bridged client, thus acting as a middleman between the mobile device and the server.

So I have tested it and your right! the openvpn client does not support tap. I set the Asus router to TAP, exported the opvn file and when I try to import into client it says its not supported. Good enough for them to tell me. I'm no expert on these things. But its odd to me that the server supports it but the client does not. Do you know of a client that does? That is simple to use like the openvpn one. I'm afraid I'm not going to carry a router along with me.
Regards

 

[ColinTaylor]

So I have tested it and your right! the openvpn client does not support tap. I set the Asus router to TAP, exported the opvn file and when I try to import into client it says its not supported. Good enough for them to tell me. I'm no expert on these things. But its odd to me that the server supports it but the client does not. Do you know of a client that does? That is simple to use like the openvpn one. I'm afraid I'm not going to carry a router along with me.
Regards

You didn't mention what your client device is. After @eibgrad's post I went back and checked my current Android phone (using the OpenVPN Connect app) and got the same "not supported" error you did. This is a change in behaviour because the same app on my previous Android phone from five years a go definitely did support tap as I used it quite frequently and still have the .ovpn files. My guess is this is a change imposed by Android rather than the app itself.

 

[steve288]

Thank you for your response. I have done some reading and found that openvpn2 did or does support it but openvpn3 does not. So you are most likely confirming this. It was removed. The claim is there are workarounds or you dont need it?? There is some complex discussions regarding this here:
https://forums.openvpn.net/viewtopic.php?t=34863
I have tried to look for v2 but on Androids they are not quick to tell you which version you are using? As far as where to get v2, how to identify it and if I should use it, frankly I'm in the weeds. Does any version that starts with 2.x.x mean its version 2? The only thing I did glean was you can have both on your device if I read it right.
Regards

 

[eibgrad]

You didn't mention what your client device is. After @eibgrad's post I went back and checked my current Android phone (using the OpenVPN Connect app) and got the same "not supported" error you did. This is a change in behaviour because the same app on my previous Android phone from five years a go definitely did support tap as I used it quite frequently and still have the .ovpn files. My guess is this is a change imposed by Android rather than the app itself.

I suspect these platforms (Apple and Android) see it as a security risk since you're hooking into layer 2. But frankly, nothing actually requires the client to bridge the tunnel to the client's local network interface. It could just as well be *routed* from the client's perspective, and only bridged at the server side. But I don't think that's the way THEY are thinking about it. They seem to assume being locally bridged is expected and/or necessary (which it isn't).

 

[steve288]

Well things that I thought would be easy are not. I may just give up on the project. Thanks.