This is probably a security flaw but it's handy

[Dieselboy]

A couple of years ago one of my remote users in Virginia USA had an issue with his 8945 Cisco phone. The phone connects back to the corp office in Australia (bit far..). So the user did a reset to factory default as due to the time difference I was asleep. This completely reset the phone and deleted the SSL certificates which are used to connect to the AnyConnect VPN. So at that point we had a useless Cisco handset.

To get it working again without shipping the phone back to me in Australia, I set up a remote support webex to his laptop and done the following.
- connected the laptop to the home wifi (user works from home)
- connected to the corp. VPN using AnyConnect, from the laptop
- Set up Internet Connection Sharing and shared the AnyConnect VPN adapter to the Ethernet NIC on the laptop
- Plugged in the phone into the wall for power
- Plugged in the phone into the Ethernet NIC port of the laptop

The phone was able to connect to the corp office CUCM and download its config through the VPN from the laptop. Once the phone had the config and certs again, we unplugged it all / removed ICS and connected the phone into the home router as normal. I can't remember if we manually set the TFTP IP address on the phone or if we set a DHCP option in ICS.

This seems like a bit of a security flaw in AnyConnect. Technically you could connect anything back to the corp office, proxied through an AnyConnect client software, hiding behind the VPN IP address.

Was anyone else aware of this?

[deanwebb]

It's a matter of being able to disable dual-homing on a device. AnyConnect can also be used to set up SOHO networks, if I recall correctly. Not a flaw... a feature!

[dlots]

That's pretty nifty, I knew we disabled split tunnel on our VPNs cause someone got into a PC that was VPNed in and got into a network that way, never thought of doing the sharing thing though.

If you care another "security flaw/feature" is if you are in the middle of a show command on an IOS device the session won't time-out, so if your working on a router and need to keep it open while you go do something else for a few min, do a show run and just never go to the end of the config, as long as it's waiting for you to hit keys the session stays alive.

[Dieselboy]

wow! I will forever use the show run then go make a coffee trick!
Because I'm always looking into issues between our offices on the internet I'm usually always connected in to the devices via SSH. I've set the exect timeout to 0 as a temporary fix, sometime last year. I don't like it. I will try your way

When you say you disabled split tunnel, do you no longer tunnel anything (clientless VPN?) or do you tunnel all? I would think a tunnel all would still allow you to ICS the AnyConnect adapter to the NIC.

PS. This is why I like using these forums! Although I did have a thought when doing the OP that someone will google this one day and it will be known. Could I have inadvertently caused security issues by making it known? 

[Reggle]

Probably yes. Someone make a TAC case s Cisco can investigate?

[Dieselboy]

I'm not raising a TAC. That's my get out of jail card in case my users lose their phone config  

[deanwebb]

Like I said, not a flaw. Feature!

But it will be fixed one day, you can be sure of that.

[Nerm]

If you care another "security flaw/feature" is if you are in the middle of a show command on an IOS device the session won't time-out, so if your working on a router and need to keep it open while you go do something else for a few min, do a show run and just never go to the end of the config, as long as it's waiting for you to hit keys the session stays alive.

[Dieselboy]

The show run feature is great! Used it today while I was waiting for an ISP to get back to me after I provided them with some trace routes.