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
