Linksys BEFSX41, VPN..What am I doing wrong?

[MountainNetworks]

Hello:

I'm trying to setup a vpn so than anyone from any location with a preshared key can get in to the office network. Of course, nothing is as simple as it should be.

Here's a text diagram of my network:

Internet
Linksys-BEFSX41..192.168.2.2
Windows 2000 Workstations (Static IP) 192.168.2.x

Remote PC trying to access...Windows XP Home over Dialup.

I purchased the Linksys device with the belief that it was an endpoint which would authenticate and connect so that I could map network drives to any shared network device.

Here's how I set up the Linksys VPN:

This Tunnel: Enable
Tunnel Name: whatever
Local Secure Group: Subnet 192.168.2.0
Mask: 255.255.255.0

Remote Secure Group: Any (This Gateway accepts request from any IP address!)

Remote Security
Gateway: Any (This Gateway accepts request from any IP address!)

Encryption: DES 3DES Disable
Authentication: MD5 SHA Disable

Key Management:
Auto. (IKE)Manual
PFS (Perfect Forward Secrecy)
Pre-shared Key: (something-stupid)
Key Lifetime: Sec. 3500


Now, on the WinXP Home side, I've tried any number of configuration combinations. None of them work. What am I missing?

Here's the VPN Log from the Linksys:

2003-05-22 12:26:06 IKE[6] Rx << MM_I1 : 66.248.81.40
2003-05-22 12:26:06 IKE[6] TX >> MM_R1 : 66.248.81.40
2003-05-22 12:26:06 IKE[6] ISAKMP SA CKI=[9f8b9fee 7dc2b8c5] CKR=[c6f48884 17286057]
2003-05-22 12:26:06 IKE[6] ISAKMP SA 3DES / SHA / PreShared / MODP_1024 / 28800 sec
2003-05-22 12:26:08 IKE[6] Rx << MM_I2 : 66.248.81.40
2003-05-22 12:26:08 IKE[6] Tx >> MM_R2 : 66.248.81.40
2003-05-22 12:26:10 This connection request matches tunnel 1 setting !
2003-05-22 12:26:10 IKE[1] Rx << MM_I3 : 66.248.81.40
2003-05-22 12:26:10 IKE[1] Tx >> MM_R3 : 66.248.81.40
2003-05-22 12:26:11 IKE[1] Rx << QM_I1 : 66.248.81.40
2003-05-22 12:26:11 IKE[1] **Check your Encryption and Authentication method settings !
2003-05-22 12:26:11 IKE[1] Tx >> Notify : NO-PROPOSAL-CHOSEN
2003-05-22 12:26:11

As I'm trying to use the Linksys as the endpoint, I've tried loggin in as &quot;Admin&quot; with the password. When I do this, I don't get the error on the VPN Log, but I don't get in either. Otherwise, I enter a login and password of someone on the network. Then I get the error. But I shouldn't be actually logging in at all because there's nothing to authenticate the login. I haven't set up any of the workstations behind the network to authenticate with VPN. That's what I thought the Linksys was supposed to do!

I'm totally confused. Help.

 

[Navaldis]

I know you have solved your problem but...

This would have worked for if you had done two things.

1. Seems like you used the same local secure group for all of your tunnels?

You would have to use different subnets in your local subnets for each tunnel...

Tunnel 1: 192.168.1.0
Tunnel 2: 192.168.2.0

Perhaps you had done this but...

2. ANY can't be used on multiple tunnels. Hence the message

2003-05-22 12:26:10 This connection request matches tunnel 1 setting !

You would have to dyndns you incoming tunnels and change each to FQDN.

But this is problematic as well as the Linksys doesn't respond well when the dynamic address changes.

I too, wouldn't be using the Linksys for Enterprise type VPN connectivity. I'm giving FreeS/WAN a try now and may even look at Clark Connect or Smoothwall.

 

[MountainNetworks]

Marku:

I'm using terminal services. The only thing I don't like about it is that I've got some very non-technical users accessing the server directly, and they're complaining about the 25 character password I gave them. I asked them what would they like more...a 25 character, nearly impossible to crack, string of numbers and letters, or something easy that any idiot can get to and mess with all their patient data. I get to win that argument. The fines for HIPAA are pretty stiff.

Having said that, I'm really anxious to get off of terminal services and enable VPN, but I've got to address this speed issue. I found a microsoft consulting services article on technet. It's called &quot;Configuring a VPN Solution.&quot; Imagine that...a microsoft artical that actually talks about what you need to do

Navaldis:

I was already aware of the subnet issue. One site is 192.168.1.1 and the other is 2.1 I didn't use the any/any since it was a site to site. Both ends had 512K static ip broadband. It took our remote site 10 minutes to print a schedule. So I had to rush into the office, turn off the vpn settings, and give them back their PcAnywhere access.
This simple project is turning out to be a real nightmare. How much of my training and education am I supposed to bill these people for?

 

[Navaldis]

All I can say is welcome to Linksys hell.
I've got a good connection on the go but am unable to access any subnets at my corporate office.

Local subnet is just fine but if I want to go to another location it's just a no go.

Tried various routes but just will not go.

I might have to do FreeS/WAN to FreeS/WAN connection to get this thing going.

I guess there is a lot to be said about purchasing a more expensive VPN device.

 

[markku]

Navaldis,

You can establish parallel tunnels in your VPN-box in order to access your corporate network. Works fine. In your corporate network you need to establish necessary routes for different networks though.

MountainNetworks,

If you use Terminal Services over VPN, the security is as good as can be. Breaking of 3DES takes 64 billion years. The passwords can be short since all traffic goes encrypted. Your speed issue is limited by your upload/upload specs. Have a customer using VPN / Terminal Server for 200 users, total bandwidth needed < 1 Mb/s.

 

[MountainNetworks]

If I establish VPN, then I don't need terminal services. I hadn't thought about the upload speed as the cause for the incredible slowness after the VPN connection was established. I kinda thought it was the fault of Linksys and their devices.

Ok, so let's assume you're right, and that the VPN connects was slower than dialup because of the upload speed. Why does PcAnywhere work without any speed issues? Why does terminal services connect without any speed issues?

My client will be a &quot;disappointed&quot; if I make them spend the money for two SonicWall SOHO3s, and the throughput is still constipated. They don't want to hear from me why it doesn't work. They just want me to fix it and make it work...and at low cost.

 

[markku]

Why don't you need Terminal Services if you use VPN?

Only thing VPN is doing is to encrypt your traffic compared with direct connection. This makes the connection secure, no open ports in firewalls.

Try Terminal Services thru VPN tunnel directly to your remote LAN IP. This is the standard way, especially if you have SQL-based client/server applications which tend to move lots of data between server and workstation, which makes them unusable for remote access.

Terminal Server , PCAnywhere, VNC, PC-DUO and other remote access applications perform all the processing in the remote computer transferring only necessary display, keyboard and mouse information between sites.

 

[MountainNetworks]

I don't have a problem using terminal services, per se. The issue I have is that Terminal Services is just like having one of your users physically sit at the server, type in their login name, and work from there. This gives them full access to the Windows 2000 server's C:\ drive.

What I like about VPN, if the speed issue can be resolved, is that I can install their application on their computer, and have them point to their server data directory in the remote (main) office...but not having to give them access to the entire server's C:\ drive.

In theory, this did work. However, it took them 10 minutes to send a simple print job to a computer in the remote office.

So now we're back to it. At the very beginning of this thread, what I wanted was a VPN connection, which would authenticate clients with the use of a specific software VPN client (like ssh sentinal). But the only choices I've been given are a hardware to hardware VPN solution, which in the end, didn't work because one of my connections has a very, very slow &quot;upstream&quot; speed.

 

[markku]

Mission impossible.

If, as usually is the case, the client/server applications are programmed so that they move a lot of data between server and client you cannot use them.

100 Mb/s compared with 128 kb/s is 1000 times more.

Use Terminal Services, this is the standard way to solve this mission. If you need to limit the user rights, you have to purchase M$ Terminal Server licences.