recommendation for vpn

Hello We have depolyed a Microsoft vpn for a small office using SBS server. The users do a lot of travelling so do most of their work from home, offices around the world, and from hotels.

Although we have been able to get the MS vpn working in 80% of cases from home with a decent home router/firewall cable modem (such as the linksys and netgear), most of the time when they are connecting to alien networks either at a friends house or a hotel etc the vpn fails to work in over 50% occassions.

This is not really an acceptable solution for the client, so I was wandering if anyone can suggest a reliable vpn that works from most places. I recently was reading about Ciscos SSL vpn which works over https - maybe this is a better solution?

Thanks Chris

Reply to
chris-c
Loading thread data ...

Or,

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

That's even less popular... :-)

Reply to
Kerry Liles

Reply to
Kerry Liles

In article , chris-c wrote: [..]

Netscreen (Juniper) SSL is way superior to Cisco's. It actually works.

alan

Reply to
Alan Strassberg

My guess would be the network you setup at the office conflicts with the subnet used at the locations where it fails.

If your network at the office uses 10.0.0.0/8, 192.168.0.0/24,

192.168.1.0/24 then you are going to have problems with the default network address space at many homes and hotels and many offices around the country.

Try using 192.168.10.0/24 for your office network.

Reply to
Leythos

You were suppose to keep that secret, it's only found in the RFC's that are secreted away on all of the web :-)

Reply to
Leythos

I'm using the RA-510, SMB version, for both Remote Access VPN and Wireless VPN (wireless security). Beautifully easy product to implement, use and manage.

The RA series is for Windows 2k/XP/2003 clients only at this stage. If you want to support other clients you need to go for the bigger SA series.

Reply to
Mark S

Some routers, I'm thinking of linksys, suprisingly :-), are hard wired so you can't use it :-(

Reply to
jasee

I think that it varies on Model and Firmware, I think, hard to remember, that I have a linksys unit that allows all octets to be set to anything you want.

Reply to
Leythos

Perhaps then as you consistently seem to recommend Linksys you could recommend one model which, with the latest firmware, does?

Reply to
jasee

I had to actually go look at the SETUP page on one, but I figure you're worth it :)

The BEFSX41 unit, running Firmware 1.45.3 (Sept 2003), allows all octets to be set, the DHCP service follows the first three octets and allows only the 4th to be set, but that's just for DHCP.

I have one set for 10.0.0.0 and use 255.255.0.0 with a starting DHCP of

10.0.0.50 through 99

I also have one with a 192.168.250.0/24 and a DHCP scope of

192.168.250.200 through 219
Reply to
Leythos

Ah, then at least the BEFSX41 doesn't! (same as the UK model). Still not working for me BTW, the Safecom I've just got looks much more promising and no spontaneous reboots!

Reply to
jasee

OK. Time for a networking lesson.

First the addresses listed above are private network space and should not be routed. Anyone routing these addresses should have their internet access revoked and never renewed.

Because these addresses are private anyone can use them as long as they do not try to route them off their network. And it doesn't make a bit of difference how many homes and hotels are using the same network space as long as they NAT anything leaving their network.

Second the gear you have talked about, Linksys, NAT's the source ip address to its own wan ports ip address before putting the packet on the wire. This ensures that the receiving machine knows how to get back to your machine.

I think you need to have your clients do a traceroute to your system when they cannot log in to ensure that the path is there. If the path isn't there then you are not going to get connected. Your clients should also ensure that they have a valid ip address on their machines when they cannot connect. Have them load a web page. If this doesn't work have them contact the front desk to ensure that they are in fact allowed to use the network. If they are allowed on the network and they do have a valid ip address ask them to ask the desk if the ports that you need to use are blocked.

The point I am trying to make here is that the private address space as being the problem is 100% BS. If everyone is doing their part then all private address space is being NAT'ed.

At the same time you should be looking at your own network and firewall. Are you blocking any address range or only allowing certain ranges in? Check your logs to see if you see them hitting the firewall when they claim they cannot get connected.

Reply to
Robert Spangler

Well, here's something new for you then - it's nice when everything works as it "should" work, but it's almost never the way that it "should" be.

If you have two networks connected via VPN (IPSec tunnels) and each network is using 192.168.0.0/24, machines on each side of the network will not see each other - since they are each using the same subnet the traffic will not be passed to the others network.

In remote locations, not all remote connection software works as one might think. In most cases, when you make a connection to the remote network your local ability is blocked so that you can only communicate with the remote network - this is a client based solution, not like a network solution. In many cases the client software works as it should, but in some cases the client software gets confused by NAT and by both sides having the same network scope.

Over the years, the simple method to keep from having problems has been to use something other than the standard HOME users network for the offices (of any size) or to use public IP's in the company (still protected by a firewall).

If you set your office to use 192.168.0.0/24 or 192.168.1.0/24, and create IPSec tunnels between end-point devices that have the same default subnet, if you can even create the tunnels, you will have problems with one side not being able to reach the other side, since it won't pass through the tunnel. Now, if you create a network with

192.168.10.0/24 at office "A" and 192.168.11.0/24 at office "B" and then setup an IPSec tunnel routing 192.168.10.0/24 network to 192.168.11.0/24 and the reverse, then all nodes can reach each other, even through the tunnel.

The same is true for many hotel networks, when they use 10.0.0.0/8 or

192.168.0.0/24, people trying to connect to their homes through PPTP or IPSec clients, or to the office, can "sometimes" have difficulty doing it. It doesn't matter if that's not the way it's "suppose" to happen, it does in the real world and there is little that a Guest in a hotel can do to tell the out-sourced IT people to change their network.

The last key part is DNS/Name resolution: If you form a connection with the remote office, then you better have a means to resolve names. In many cases, if you setup a simple PPTP connection, and don't specify a DNS server inside the remote office (or get it assigned by DHCP) you won't be able to reach anything by name (a very common problem).

With remote offices, A & B, you want DSN servers on either side to replicate the node names between the local DNS server and the remote one (both directions) so that one side can find the other my name.

Reply to
Leythos

Dude you need to do a few more lessons before lecturing people yourself.

You seem to have no clue about IPSEC tunnels, Leythos is 100% on the money as far as configuring IPSEC VPNs goes. If the IP subnet on the remote network is the same as the host VPN networks internal subnet the packets will not tunnel.

Reply to
Mark S

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.