make a package that configures the MIT VPN

[tabbott]

We should investigate making a package that configures VPNC to use the MIT VPN service.

[broder]

This is tricky because the apt repo is publicly readable and the VPN group information is not. Some cleverness with postinst scripts is probably in order.

[geofft]

One decent way to deal with this would be to make two installer scripts, one protected behind certs, that writes to /etc a small private key that debathena-vpnc-config's postinst can use to decrypt its config file. This has the benefit of being extensible to other things we may need to restrict to MIT users only, but still want to package (commercial software with license keys comes to mind).

[broder]

We can do slightly better than that, I think.

curl supports SPNEGO, right? So we just need a site with the information behind a SPNEGO auth, and make the user get tickets at install-time. Then we can have 1 package that handles it.

[andersk]

The directions for configuring this yourself are straightforward.

1. Install network-manager-vpnc.
2. Click the NetworkManager applet → VPN Connections → Configure VPN… → Add.
3. For Choose a VPN Connection Type, select Cisco Compatible VPN (vpnc).
4. Fill in Connection name: MITnet (or whatever), Gateway: vpn-public.mit.edu, Group name: MIT, Group password: [the super-secret VPN password], Username: [your Athena username], and click Apply.
5. Now you can connect by clicking NetworkManager applet → VPN Connections → MITnet. You will be prompted for your Athena password (or you could have saved it in step 4).

The difficulty with packaging this is that your Athena username needs to be part of the configuration; there seems to be no way to make it prompt for that.

[jdreed]

In addition to Anders' directions, users can download the config file from  https://web.mit.edu/software/mit/vpn/profiles/MITnet-VPN.pcf and then run /usr/share/vpnc/pcf2vpnc on it to create the VPNC config (which will even decrypt the group key).

This is probably WONTFIX at this point -- I'm not sure it's worth the effort to set up some sort of authenticated/protected repository just for one package, unless we want to get into the VirusScan? or MATLAB business (we really don't).

[broder]

It would appear that there are still a few unresolved issues here.

• NetworkManager blindly displays the welcome message via libnotify once its already connected, which means users get a black box saying "[...] Please hit the continue button below to complete the signon process and connect to MITnet" without any buttons.
• In its default configuration, NetworkManager doesn't seem to be setting up any useful routing whatsoever. It might be setting up routing over the VPN for 18.100/16 - I can't tell. If you edit the VPN configuration, go to the "IPv4 Settings" tab, and click "Routes", there's an option to "Use this connection only for resources on its network." Turning that off didn't make the VPN go for me, though I'm inclined to blame that on weird VM networking interactions.

It would be good if someone running Ubuntu under not-a-VM could poke at these settings and see if we can figure out how to make them useful.

[dwinston]

Under not-a-VM Ubuntu (9.04), I get the weird libnotify message, but unchecking the "Use this connection only..." option DID work in getting things to route properly, at least verified with  http://whatismyip.com/ (I get a 18.100.*.* IP now). Yay!

Replying to broder:

It would appear that there are still a few unresolved issues here.

• NetworkManager blindly displays the welcome message via libnotify once its already connected, which means users get a black box saying "[...] Please hit the continue button below to complete the signon process and connect to MITnet" without any buttons.
• In its default configuration, NetworkManager doesn't seem to be setting up any useful routing whatsoever. It might be setting up routing over the VPN for 18.100/16 - I can't tell. If you edit the VPN configuration, go to the "IPv4 Settings" tab, and click "Routes", there's an option to "Use this connection only for resources on its network." Turning that off didn't make the VPN go for me, though I'm inclined to blame that on weird VM networking interactions.

It would be good if someone running Ubuntu under not-a-VM could poke at these settings and see if we can figure out how to make them useful.

[jdreed]

IS&T is moving away from the Cisco 3000 VPN (supported by vpnc) and moving to Cisco AnyConnect?. You can try out the new VPN at  http://vpn.mit.edu (which some users have said looks like a phishing site, but totally isn't).

It will try to automatically install the VPN client using the following methods, in order: ActiveX (doesn't apply to Debathena, obviously), Java applet, and finally a link that says "Click here".

It works reasonably well and appears to be less invasive about routing than the old cisco client was.

So we should test this. I believe it's expected NOT to work with vpnc, so we should possibly WONTFIX this ticket.

[jdreed]

I've committed some code in r24476 to do sane things for command line users, and for GUI users, we'll document using NetworkManager with openconnect (which works, at least under stock Karmic).

Jaunty users get to be sad, because there's no openconnect.

[jdreed]

(Note: The reasons why I don't use use /etc/vpnc/vpnc-script:

• It's a mess
• It's for VPNC, not openconnect. Some variables are the same, others aren't
• You shouldn't have to have vpnc installed to use openconnect

[quentin]

The openconnect documentation *specifically* tells you to use a vpnc-script. It's supposed to be completely compatible. However, it is a good point that we don't necessarily want to depend on vpnc. The openconnect documentation suggests using the script from  http://git.infradead.org/users/dwmw2/vpnc-scripts.git. I can confirm that that script works out of the box for me with MIT's VPN.

[jdreed]

Yeah, I saw the documentation, but I don't even want to ship vpnc-script as is from upstream, because it has the same bugs (which we should probably get fixed upstream, but that's another ticket).

Namely:

• The following barfs because our VPN server sets INTERAL_IP4_NETMASK, but not INTERNAL_IP4_NETADDR, so it tries to run "ip route /255.255.0.0 dev tun0" which is an invalid command. {{{ if [ -n "$INTERNAL_IP4_NETMASK" ]; then

set_network_route $INTERNAL_IP4_NETADDR $INTERNAL_IP4_NETMASK $INTERNAL_IP4_NETMASKLEN

fi

}}}

• it only deals with include-splits, not exclude-splits
• CISCO_BANNER isn't set, it's not in the CISCO_CSPT_OPTS (or whatever it is)
• I don't want to blindly run any pre- or post- connect/disconnect hooks that users may have, because those assume vpnc, not openconnect.

Our script is minimal and not a big deal to maintain. If we want to start supporting more complicated routing (and we totally don't), then we should fix the upstream bugs in vpnc-script and use that.

Additionally, I decided to depend on resolvconf because it makes playing resolv.conf games an order of magnitude easier.

I'll also note that in documentation, NetworkManager will be the preferred way of using the VPN, with this as a fallback. I don't even think it should go in any metapackages -- I think it should be an optional install.

[jdreed]

• CISCO_BANNER isn't set, it's not in the CISCO_CSPT_OPTS (or whatever it is)

s/not/now/

[jdreed]

Documented.  http://kb.mit.edu/confluence/x/-IJh

There's really no need for a package anymore.