problem connecting with Microsoft RDP App over VPN

[Jake Jackson]

I was setting up a Chromebook for an end user to use to RDP to their work PC's over VPN. VPN connects fine, I can ping the target computer and access anything across the VPN that uses http. The MS RDP app works fine when connected to the local LAN, but when connected to the VPN I get error 0x104.

I wasted about 5 hours two days ago trying all sorts of other things including trying the beta and dev builds. It was particularly maddening since I could ping across the VPN to the target computer and see any other resources that i needed to. Yesterday I unboxed a second Chromebook that we had gotten for another user to see if it was just a fluke and low and behold it would connect fine across the VPN using the MS RDP App. I rebooted a few times and tried a few different wifi AP's not on our network with the VPN to make sure that it was stable. I figured for giggles I would check the build info. It was actively applying an update at the time that I checked but the installed build date on the release that the second Chromebook shipped with was March 21, 2019, (I didn't write down the build number).. It updated to 78.0.3904.106 with a 11/15/19 build date and I restarted. Once it updated the RDP connection over the VPN was broken and it would no longer connect to the target computer over the VPN, I could still ping the target computer and access anything with http over the VPN. It will connect just fine to the target computer via RDP over the local network, but while connected to a different network over VPN it errors out with the 0x104 error.

I have a Samsung Galaxy Tab S4 running the latest update set up using the exact same VPN configuration and it will open the RDP connection over the VPN perfectly every time to the target computer.

Any ideas or things to check?

[Hakatit]

So the second chrombook that was working stopped working after it updated to 78?
You're using the Microsoft RDP Android app. My guess is something changed with the Android container since it sounds like the VPN still connects.
Does it work inside the LAN, just not outside?

[Jake Jackson]

Yes, That is what happened. This past weekend I went and picked up a Samsung Chromebook to do some testing on. It exhibited the same behavior that the second Chromebook I mentioned above did. The ChromeOS version that it shipped with was 75.xxxx I set it up and had the VPN working and was able to RDP using the Microsoft RDP Android App to a target computer just fine. It updated itself to ChromeOS 79.xxxx and after the reboot the RDP connection across the VPN fails. It does still connect on the Local LAN. 

I was able to get a workaround in place by installing the Linux subsystem and installing Vinagre. It will connect to the RDP target from there just fine. But that's just that, a work around. I shouldn't have to jump through hoops to get it to work. The RDP over VPN works fine on the 75.xx build and on my Galaxy Tab S4, but not on the 78.xx/79.xx builds The odd thing is when I pull the ifconfig from the Linux shell I get an odd ip address on eth0. FWIW I'm connecting to a backup DSL circuit to test the VPN functionality.  My Chromebook is getting assigned 100.115.92.9 which is odd as the IP address that the WiFi AP for the Backup DSL circuit is handing out is 192.168.1.173.

When I goto chrome://system I get the following entries when I expand ifconfig:

arc_wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 100.115.92.9 netmask 255.255.255.252 broadcast 100.115.92.11 inet6 fe80::c4b8:1eff:feba:2833 prefixlen 64 scopeid 0x20<link> ether 6a:b6:ae:9e:bd:98 txqueuelen 1000 (Ethernet) RX packets 9219 bytes 1035860 (1011.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14492 bytes 42186220 (40.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

arcbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 100.115.92.1 netmask 255.255.255.252 broadcast 100.115.92.3 inet6 fe80::fc30:cbff:fed7:604c prefixlen 64 scopeid 0x20<link> ether b2:f7:84:4e:a9:7e txqueuelen 1000 (Ethernet) RX packets 13 bytes 836 (836.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 107 bytes 8796 (8.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 48 bytes 3536 (3.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 48 bytes 3536 (3.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1280 inet 192.168.29.227 netmask 255.255.255.255 destination 192.168.29.227 ppp txqueuelen 3 (Point-to-Point Protocol) RX packets 100 bytes 39891 (38.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 147 bytes 18934 (18.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

veth_arc0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::b0f7:84ff:fe4e:a97e prefixlen 64 scopeid 0x20<link> ether b2:f7:84:4e:a9:7e txqueuelen 1000 (Ethernet) RX packets 13 bytes 1018 (1018.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 70 bytes 6992 (6.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

veth_wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::68b6:aeff:fe9e:bd98 prefixlen 64 scopeid 0x20<link> ether 6a:b6:ae:9e:bd:98 txqueuelen 1000 (Ethernet) RX packets 9219 bytes 1164926 (1.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14393 bytes 42369657 (40.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

vmtap0: flags=67<UP,BROADCAST,RUNNING> mtu 1500 inet 100.115.92.25 netmask 255.255.255.252 broadcast 100.115.92.27 inet6 fe80::2456:58ff:fe18:474a prefixlen 64 scopeid 0x20<link> ether 26:56:58:18:47:4a txqueuelen 1000 (Ethernet) RX packets 15220 bytes 1026159 (1002.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 43935 bytes 344069461 (328.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.173 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::52e0:85ff:fefe:44b7 prefixlen 64 scopeid 0x20<link> ether 50:e0:85:fe:44:b7 txqueuelen 1000 (Ethernet) RX packets 371292 bytes 538359781 (513.4 MiB) RX errors 0 dropped 60 overruns 0 frame 0 TX packets 42932 bytes 5194312 (4.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

Logically I should only have-  

-wlan0 which is the wifi connection

-ppp0 is the VPN tunnel

-lo is the loopback.

Where are the extra adapters coming from ?

-arc_wlan0 : inet 100.115.92.9 netmask 255.255.255.252 broadcast 100.115.92.11

-arcbr0 : inet 100.115.92.1 netmask 255.255.255.252 broadcast 100.115.92.3

-veth_arc0 : ipv6

-veth_wlan0 : ipv6

-vmtap0 : inet 100.115.92.25 netmask 255.255.255.252 broadcast 100.115.92.27

and where is the 100.115.92.XX IP addresses coming from?

[Jason Keomany]

I'd love to get to the bottom of this as well. Especially since we're attempting to deploy Chromebooks for users to remotely connect to their desktops in the office. I'm having the exact same issue. Once Chrome OS updates beyond roughly build 75 or so, RDP over VPN no longer works. And like you said, you can ping it and it's fine. Just RDP is borked.

[Nom De Plume]

I think I remember the answer to the IP address oddity being an internal proxy that prevents direct access from the network to ChromeOS. That isn't something that has changed recently.