Re: Help with post-connect actions with non-standard ChromeOS RPDB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think I have resolved the issue. Since I don't mind all the traffic
going through the VPN since that was how things were originally, I
followed how things looked in the main table, and just added them to
table 1002. I needed to delete the default dev in the main table too.
I added these post-connection commands to a copy of my vpnc-script:

        # ChromeOS puts routing information into table 1002...
        ip route del default dev ${TUNDEV}
        ip route add default dev ${TUNDEV} table 1002
        ip route add 192.168.56.0/24 dev ${TUNDEV} table 1002

I am now successfully connected to the VPN and can access office
resources and external resources as normal. I've tested this on more
than one wireless network and it seems robust. Very happy!

Strangely, I continue to get DTLS errors:

DTLS handshake timed out
DTLS handshake failed: Resource temporarily unavailable, try again.

But this does not impact my ability to connect, and adding the
--no-dtls option silences these, obviously.

Thanks to David and Daniel for all of the attention to this issue over
the past few months! Hopefully this will be helpful to anyone else
using ChromeOS and OpenConnect.

All the best,
Adam

On Fri, Jan 17, 2020 at 11:32 AM Adam Allgood <avram.meir@xxxxxxxxx> wrote:
>
> Hello OpenConnect devs,
>
> I am asking this question in a new email thread because the old one
> was long and muddled, and I'm hoping to focus on one specific problem.
> If this yields success, then hopefully the breadcrumbs will be clearer
> for anyone else with this issue who stumbles across this list while
> Googling. A big thank you to Daniel and David for working with me on
> this issue for the past few months.
>
> "Brief" recap: I use OpenConnect on ChromeOS in a crouton Ubuntu Linux
> chroot to connect to my office Cisco VPN. I do this because
> OpenConnect has PKCS#11 support, which I require because I have to
> authenticate with a smart card. For well over a year, this setup
> worked wonderfully, but following the automatic update to ChromeOS
> v77, a successful connection to the VPN head end would be made, but
> then no traffic would successfully move through the tunnel.
>
> A look at ChromeOS's routing protocol database (RPDB) shows a
> nonstandard networking setup, with an additional table 1002. This is
> the routing setup (routes, rules, tables) BEFORE a VPN connection is
> made:
>
> chronos@localhost / $ ip route show
> 100.XXX.92.0/30 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> 100.XXX.92.8/30 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.197
>
> chronos@localhost / $ ip rule show
> 0:      from all lookup local
> 9:      from all lookup main
> 10:     from all oif wlan0 lookup 1002
> 10:     from 192.168.1.197/24 lookup 1002
> 10:     from all iif wlan0 lookup 1002
> 32765:  from all lookup 1002
> 32766:  from all lookup main
> 32767:  from all lookup default
>
> chronos@localhost / $ ip route show table local
> broadcast 100.XXX.92.0 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> local 100.XXX.92.1 dev arcbr0 proto kernel scope host src 100.XXX.92.1
> broadcast 100.XXX.92.3 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> broadcast 100.XXX.92.8 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> local 100.XXX.92.9 dev arc_wlan0 proto kernel scope host src 100.XXX.92.9
> broadcast 100.XXX.92.11 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
> broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
> broadcast 192.168.1.0 dev wlan0 proto kernel scope link src 192.168.1.197
> local 192.168.1.197 dev wlan0 proto kernel scope host src 192.168.1.197
> broadcast 192.168.1.255 dev wlan0 proto kernel scope link src 192.168.1.197
>
> chronos@localhost / $ ip route show table main
> 100.XXX.92.0/30 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> 100.XXX.92.8/30 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.197
>
> chronos@localhost / $ ip route show table 1002
> default via 192.168.1.1 dev wlan0 metric 10
>
> The arcbr0 device I believe is used for communication with Android
> apps, and is not relevant. Now, connecting to the VPN creates a new
> tun0 device to handle network traffic on the VPN, and AFTER the
> default VPNC script does its stuff, the routing configuration looks
> like this:
>
> chronos@localhost / $ ip route show
> default dev tun0 scope link
> 100.XXX.92.0/30 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> 100.XXX.92.8/30 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.197
> 192.168.56.0/24 dev tun0 scope link
>
> chronos@localhost / $ ip rule show
> 0:      from all lookup local
> 9:      from all lookup main
> 10:     from all oif wlan0 lookup 1002
> 10:     from 192.168.1.197/24 lookup 1002
> 10:     from all iif wlan0 lookup 1002
> 32765:  from all lookup 1002
> 32766:  from all lookup main
> 32767:  from all lookup default
>
> chronos@localhost / $ ip route show table local
> broadcast 100.XXX.92.0 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> local 100.XXX.92.1 dev arcbr0 proto kernel scope host src 100.XXX.92.1
> broadcast 100.XXX.92.3 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> broadcast 100.XXX.92.8 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> local 100.XXX.92.9 dev arc_wlan0 proto kernel scope host src 100.XXX.92.9
> broadcast 100.XXX.92.11 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
> broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
> broadcast 192.168.1.0 dev wlan0 proto kernel scope link src 192.168.1.197
> local 192.168.1.197 dev wlan0 proto kernel scope host src 192.168.1.197
> broadcast 192.168.1.255 dev wlan0 proto kernel scope link src 192.168.1.197
> local 192.168.56.197 dev tun0 proto kernel scope host src 192.168.56.197
>
> chronos@localhost / $ ip route show table main
> default dev tun0 scope link
> 100.XXX.92.0/30 dev arcbr0 proto kernel scope link src 100.XXX.92.1
> 100.XXX.92.8/30 dev arc_wlan0 proto kernel scope link src 100.XXX.92.9
> 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.197
> 192.168.56.0/24 dev tun0 scope link
>
> chronos@localhost / $ ip route show table 1002
> default via 192.168.1.1 dev wlan0 metric 10
> 140.YY.73.186 via 192.168.1.1 dev wlan0
>
> I strongly suspect that, due to the non-standard network configuration
> in these later versions of ChromeOS, that there is some error in this
> setup that is preventing traffic from going out/in on tun0. For
> example, I see an IP related to the VPN added to table 1002, but
> nothing about device tun0. I'm hoping that some additional setup
> commands added to the VPNC script could fix this issue. I've tried a
> few things without success. Unfortunately, I know very little about
> networking issues. Do you see anything here that could be causing the
> problem, and can you recommend a way to fix the routing?
>
> Thanks so much!
> Adam

_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux