Unable to setup bridged connection

Got a problem with Viscosity or need help? Ask here!

josh

Posts: 3
Joined: Fri Jun 05, 2020 5:58 am

Post by josh » Fri Jun 05, 2020 6:18 am
Hello,

I'm trying to connect to a VPN hosted on my home LAN in bridged mode using tap, so that my VPN client is assigned a private IP on the same range as the rest of my network (in my case 192.168.0.x). I'm not sure what kind of configuration is needed, besides specifying "tap" device in preferences. I've also set "Send all traffic over VPN connection", Automatic DNS mode, and "route-delay 20". My VPN server is on a TP-Link router, so I have little or no access to its configuration (though would consider using DD-WRT if necessary).

I am able to connect to the VPN, but get a 10.8.0.6 IP address. I also see a lot of routing errors in the log (below). How do allow my home router to assign a 192.168.0.x IP address?

I also tried putting in the desired gateway under Routing / Default Gateway, but then am unable to connect at all.

Thanks very much for any help in advance!


Log:

2020-06-04 16:11:32: Viscosity Mac 1.8.5 (1537)
2020-06-04 16:11:32: Viscosity OpenVPN Engine Started
2020-06-04 16:11:32: Running on macOS 10.15.5
2020-06-04 16:11:32: ---------
2020-06-04 16:11:32: State changed to Connecting
2020-06-04 16:11:32: Checking reachability status of connection...
2020-06-04 16:11:32: Connection is reachable. Starting connection attempt.
2020-06-04 16:11:32: OpenVPN 2.4.8 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Apr 1 2020
2020-06-04 16:11:32: library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
2020-06-04 16:11:32: Valid endpoint found: [xxxx]:1194:udp
2020-06-04 16:11:32: TCP/UDP: Preserving recently used remote address: [AF_INET]108.41.211.18:1194
2020-06-04 16:11:32: UDP link local: (not bound)
2020-06-04 16:11:32: UDP link remote: [AF_INET][xxxx]:1194
2020-06-04 16:11:32: State changed to Authenticating
2020-06-04 16:11:33: [server] Peer Connection Initiated with [AF_INET]192.168.0.1:1194
2020-06-04 16:11:33: WARNING: Since you are using --dev tap, the second argument to --ifconfig must be a netmask, for example something like 255.255.255.0. (silence this warning with --ifconfig-nowarn)
2020-06-04 16:11:33: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.0.0
2020-06-04 16:11:33: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.0.0
2020-06-04 16:11:33: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.0.0
2020-06-04 16:11:33: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: 0.0.0.0
2020-06-04 16:11:33: GDG6: problem writing to routing socket
2020-06-04 16:11:33: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: fc00::/7
2020-06-04 16:11:33: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: 3000::/4
2020-06-04 16:11:33: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/4
2020-06-04 16:11:33: OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
2020-06-04 16:11:33: OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/3
2020-06-04 16:11:33: DHCP enabled on tap interface vtap0
2020-06-04 16:11:34: TUN/TAP device vtap0 opened
2020-06-04 16:11:34: /sbin/ifconfig vtap0 delete
2020-06-04 16:11:34: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-06-04 16:11:34: /sbin/ifconfig vtap0 10.8.0.10 netmask 10.8.0.9 mtu 1500 up
2020-06-04 16:11:53: NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing
2020-06-04 16:11:53: WARNING: OpenVPN was configured to add an IPv6 route over vtap0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.
2020-06-04 16:11:53: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-06-04 16:11:53: Initialization Sequence Completed
2020-06-04 16:11:53: Disabling DHCP on interface vtap0 (not required)
2020-06-04 16:11:53: DNS mode set to Full
2020-06-04 16:11:53: State changed to Connected
2020-06-04 16:11:53: DNS change detected, restoring DNS settings

James

User avatar
Posts: 1980
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Jun 05, 2020 12:38 pm
Hi josh,

It looks like your VPN server is pushing out a standard TUN-style IP address, rather than an IP address and subnet mask (or nothing at all and leaving it to DHCP). You'll need to configure your VPN server and make sure it is set to TAP/bridged mode, as this is what will typically happen if it is set to TUN mode (while your VPN client is set to TAP).

I'm afraid I'm not familiar with TP-Link's OpenVPN server support, but if it doesn't have a TAP/bridged option I'm afraid that means you'll have to run your connection in TUN mode.

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

josh

Posts: 3
Joined: Fri Jun 05, 2020 5:58 am

Post by josh » Sat Jun 06, 2020 6:57 am
Hi James,

Thanks for the assistance. I thought that might be the case, until I looked at the routing table. It has lines like the following:
Code: Select all
Destination        Gateway            Flags        Netif Expire
default            v                  UGSc           en0       
10.8.0.4&0xa080    link#14            UC           vtap0      !
10.8.0.6           5a:73:57:30:b3:de  UHLWIi         lo0       
edge-star-mini-shv link#14            UHLWI        vtap0      !
127                localhost          UCS            lo0       
localhost          localhost          UH             lo0       
142.250.31.156     link#14            UHLWIi       vtap0      !
Doesn't that mean I have a TAP connection?
The Internet6 section of the table, though, has "utun" adapters.

Thanks again

James

User avatar
Posts: 1980
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sat Jun 06, 2020 6:55 pm
Hi josh,

Both the OpenVPN server and the client need to be using the same mode, otherwise it won't work. While you have set the VPN client to use TAP (and so Viscosity creates a vtap adapter), the OpenVPN server is not setup to use TAP. It is expecting any connecting client to use TUN mode. This affects the IP address being pushed, the routes being pushed, and the packet handling. Your VPN connection will not work unless the server is also set to TAP/bridged mode, and if it doesn't support that you'll need to use TUN on the client side instead.

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

josh

Posts: 3
Joined: Fri Jun 05, 2020 5:58 am

Post by josh » Tue Jun 09, 2020 2:28 am
Got it, thanks.
Do you know if there's a way in TUN mode for the VPN client to get assigned an IP in the range of the local network?

James

User avatar
Posts: 1980
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Tue Jun 09, 2020 4:30 pm
Do you know if there's a way in TUN mode for the VPN client to get assigned an IP in the range of the local network?
The short answer is no, I'm afraid it's not really possible.

The longer answer is that it could in theory be done on a linux server, however the process is quite complicated and definitely wouldn't be possible on your TP-Link router.

Depending on what you're trying to do I'd recommend one of the following:

1. If you simply want to be on the same IP subnet so that computers on the network appear in the Finder sidebar, so that AirPlay/AirDrop works, etc., then you can achieve this in TUN mode by running a mDNS proxy/forwarder on the server. However I'm afraid I have no idea whether your TP-Link device would support this - it would be something you'd need to ask TP-Link.

2. Use a different device as the OpenVPN server. For example, you can setup an OpenVPN server on a RaspberryPi (an inexpensive, small, and low-power computer) or spare computer. This would allow you to use a TAP setup, or a TUN setup with a mDNS proxy.

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
6 posts Page 1 of 1