Major problem with remote access and timout

[Brian Bergin]

So I'm working on a customer's site today using the TBA to generate RDP access to systems to install an update to a software package.  I first RDP'd to, let's call it Machine "A".  While I installed and configured the software there the portal timed out on me forcing me to log back in to get to Machine "B" (but I still needed access to machine A to export some registry keys.  The problem is when the portal times out the RDP session appears to do likewise and then I got dropped.  Since I'm on Win7 here mstsc.exe automatcally tries to reconnect and when it did it did not connect me to Machine A it connected me to machine B using port :11700.

There are going to be many times when I am going to require potentially hours of connections to multiple machines and as such I need the portal and the TBA device to never time out while I have active connections.  If they idle out and other connections are made to the same LAN a new port needs to be selected.  There's no reason why it can't be some random port.  It doesn't have to be 11700 it could be 12345 for all I care, but I need to be able to get to any machine at any time.

Does this make sense?

[Michael Holloway]

Hi Brian. An existing tunnel session is disconnected from the portal session, so if you navigate away from or even logout from the portal, it should not disturb any existing tunnels. However, if you change IP addresses mid-stream, such as with redundant connections that use different IPs, you will observe being logged out of both sessions simultaneously, as both separate connections depend on the source address not changing.

Regarding accessing multiple devices simultaneously at a site, this isn't functionality that Thunderbolt currently intends to provide. Instead we recommend installing a VPN at the site. It's not due to any technical limitation in Thunderbolt, in fact our marketing folks are currently looking very closely at the remote connection services that we may offer to users at release. There is the possibility of enhanced remote access under different service agreements. Your input here would be GREATLY appreciated, nothing is set in stone yet!

-mike

[Brian Bergin]

Don't get me started again on Cisco's lousy VPN technology forced on your small biz customers.  Also, please, I beg of you, don't nickel and dime the small biz to death or it will be the end of TBA.  Enterprises are used to having to pay piece meal for services, small businesses don't and won't.

One of the major selling points of TBA will be my ability to maintain a customer network from anywhere in the world.  I often end up in hotels with crappy routers that don't allow VPN well if at all and TBA will solve that, but if I can't connect to several machines at once it'll be useless to me. I can continue to use IPSentry to monitor LANs for up/down systems and if I can only count on 1 connection that's what I'm likely to do.  Partners can use this to support customers and when customers are supported well they know it and come back for more.  If Cisco backs Partners, Partners will back Cisco.  If Cisco makes us have to nickel and dime customers into buying "different service agreements" many of us simply won't bother.  We have far too many other things to worry about.

Now, if you want to go back to the Cisco small biz VPN issue I'm happy to lambast it once again as the worst technology on the market today with almost zero possibility of being resolved without a full revamp of every Cisco Small Business router Cisco makes.  Given current betas, I'm betting it's 2015 before we have acceptably functioning VPN technology to the small business.

At the very least, we should be able to connect to 5-10 devices at the same time through a TBA.  Look at it this way, if they're using a RV082, they can connect 100 VPNs, so what's the difference if they're using a RV082 to create the tunnel or the TBA other than the TBA's tunnels actually work and the RV082's (or SA500's for that matter) rely on QVPN which was/is so badly designed that I'd rather see it removed with no replacement than for Cisco to continue to try to justify its existence.

[Michael Holloway]

Thanks for the candid feedback Brian, it's exactly what we need to hear to ensure that we don't repeat past mis-steps with the small business needs versus enterprise.

-mike

[Brian Bergin]

Mike,

I think I should also point out that I still believe that Cisco needs to ask "would this fly if we tried this with our enterprise customers" but that really can only apply for technologies not pricing or bundles.  SBs have had the Linksys-style of pricing for so long that any other scheme will fail.  Ask the SA500 folks.  They tried the piece meal and failed to sell hardly any of the IDS or Protect Link so they had to rebundle SKUs to sell them upfront.  I'm still not convinced IDS and PL will sell well to the SB market, but that should be the warning shot that SBs don't like to have to pay for add-ons and more often than not won't pay for add-ons.

[Marcos Hernandez]

Brian,

The limitation of one tunnel per site is not artificial. We hairpin this tunnel through our portal, each an every packet. It is not a P2P session between your computer and the appliance, so we are concerned about the impact that this traffic could have on data center bandwidth, server CPU, etc. So far we have not taxed this connection. We have been offering soft guidance that you shouldn't use it to replicate your database, for example. It is intended for remote, infrequent access.

Ideally, a remote tunnel should resort to the hairpin approach only if the P2P session fails (like Skype does, for example). The problem here is that we do not control both ends of the connection. We only have one client under control (the TBA) while the other side is a browser.

We were looking at the possibility of running an SSL VPN server on the appliance and treat the browser-to-TBA session as an ordinary VPN session behind NAT boundaries, effectively cutting the Portal out of the equation. This is technically feasible. The problem we found is that the Open Source package available for that VPN server doesn't support the Cisco AnyConnect client, or any Cisco-vetted client, and that is a non-starter if we want all this stuff supported by TAC.

We will have to revisit this, but for now I am not sure I have a good answer for you. At the very least we should solve the following inconsistency: we only allow one tunnel per customer, but you can create tunnels against multiple customers. So the actual impact our infrastructure is the same as if you had created multiple tunnels against the same customer. You could have as many tunnels as customers there are!!!! Maybe the answer is that we support "5 tunnels total" and we enforce that regardless of how you are using them (one per customer, or 5 per customer)

Let me know what you think. Others, please feel free to chime in.

Marcos

[Brian Bergin]

I see your point, but one is going to kill the functionality gains.  At least 3 or 4 would almost certainly be a requirement.

BSB

[Brian Bergin]

We were looking at the possibility of running an SSL VPN server on the appliance and treat the browser-to-TBA session as an ordinary VPN session behind NAT boundaries, effectively cutting the Portal out of the equation. This is technically feasible. The problem we found is that the Open Source package available for that VPN server doesn't support the Cisco AnyConnect client, or any Cisco-vetted client, and that is a non-starter if we want all this stuff supported by TAC.

Wait, why do we need an open source VPN server?  Cisco already has its OWN code that works perfectly well.  This is my ENTIRE probelm with RV082's, SA500's, and every other Cisco Small Business product.  VPN is jury rigged at best when Cisco already owns the code to do it right.  Forget open source.  It's a waste of Cisco's time and therefore a waste of Cisco's Partners' and Customers' time.  I again submit that if Cisco's shareholders really knew how much questionable 3rd party code was incorporated into Cisco branded products when code that has already been written by Cisco employees they'd be very unhappy with upper management, potentially unhappy enough to warrant a change.

Simple question, why can't you incorporate code with features limited to current specs (number of users, etc...) from an ASA into EVERY SINGLE Small Business code to allow REAL Cisco-branded VPN clients to work?

[Marcos Hernandez]

I am already in conversations (very early ones) with some security product teams to investigate just this. I agree with you, we have way too many VPN sw stacks.

Thanks,

Marcos

[Marcos Hernandez]

Quick update: We will be investigating the possibility of using Anyconnect and a common VPN headend infrastructure (very likely, the ASA one) for this remote access service.

Thanks,

Marcos

[Brian Bergin]

I cannot tell you how much that increases my confidence in this product and I can only hope that a successful deployment of that technology with TBA will lead to its widespread use in EVERY other Cisco Small Biz and Small Biz Pro device.  The QVPN junk in use now is an embarrassment to Cisco and its Partners and a constant point of frustration for our mutual customers.

[danny]

I agree with Brian 100%.  The timeout issue is very frustrating from a support issue because when it does timeout aventually the RDP connection drops.  Having the ability to make multiple RDP/VNC connections to the same Customer is very important as a support tool.  The current platform I use to support Customers is a VPN router that allows me to connect to their network and have the ability to either RDP or VNC to all systems on their network individually or at the same time.  If I am doing updates, scans or installations on multiple systems it saves time and money to be able to have access to multiple systems at the same time.

[Marcos Hernandez]

Excellent. It seems that we are all aligned. This is what we have in mind:

1) We create a new type of connection, controllable via the Portal, maybe called "VPN access". This VPN access allows the TBA to become an SSL VPN headend.

2) If your WAN router supports port forwarding, then you would forward the required VPN port (or ports) to the TBA's IP (static).

3) You then use Anyconnect to  connect to the TBA in bridged mode. That puts you on the customer's LAN at which point you can do whatever.

4) The Portal controls the configuration of the Anyconnect client, for enhanced security and usability. This is where things like that DDNS-like service become important (since the client can now just point to the Portal-provided customer site name, even when the IP changes).

5) If your WAN router does not support port forwarding, or you can't configure it (say you don't own it), we hairpin the TLS VPN connection through the portal.

Giving you, our reseller, the alternative to connect directly to the customer, allows us to restrict the bandwidth of the hairpinned tunnels, thus preventing the starvation of our Data Center resources. If the WAN router is a Cisco router, the TBA can even help you configure the port forwarding rules, via direct connection or using UPnP IGD, for example.

Finally, each TBA would support one and only one SSL tunnel. That allows us to avoid certain Anyconnect licensing implications. By leveraging the same headend infrastructure, the hope is also that we can upsell you into the notion of a full blown VPN using the ASA or similar Small Business router.

What do you think?

[Brian Bergin]

Well, that could be a problem.  If the customer already uses VPN technology, many will, at their site forwarding a port to the TBA would be problematic if that same port were used for the existing technology so unless you use a customizable port for this you break the primary VPN capability and force a fall back on a bandwidth-restricted portal-based connection.

[Marcos Hernandez]

Good point. We'll take that into account.