Linksys BEFSX41 makes a VPN con.. on XP computer. Cannot for the life of me makemit under Vista ultimate HELP ....

Was having the same issues. Used SSH Sentinel client on XP to tunnel to BEFSX41 (IPsec Pass Through enabled) and then use VNC viewer (local subnet) to control Win98 machine with an ancient database program. My client has recently aquired a Vista Home Pro laptop and wants similar remote access to his database. Finally had success with NCP Secure Entry Client after configuring IPsec IP setttings proposalproperly. See next post with the settings that worked. Tried for days to configure Vista VPN, MMC IPSEC services and Windows Firewall to no avail. No luck at first with the 30-day trial of NCP client (one of the first for Vista) - am able to complete Phase1 connection, but Phase2 fails (maybe because SSH Sentinel allows the option of NOT aquiring a virtual IP address, which is the only way it seems to work). SafeNet software client has no trial (not going to gamble on either one of these $150 programs without being able to get it to work first!) NGX_R60 client doesn't appear to support PFS preshared key - couldn't get to first base with its settings.My working XP configuration: manual preshared key, PFS, 3DES, MD5, main, DH2 3DES, MD5, DH2 28800 seconds on both endsIt is amazing how obscure and convoluted the settings are in this realm. It makes 802.11 look like kindergarten stuff. Where are the 10 people in the world that designed this mess with their job security in mind when we need them?

SUCCESSFUL TUNNEL CONNNECTIONVista client to BEFSX41 endpoint. remote client NATs through DI704P router - wireless (DI-624 as AP) or wired both work cable modem DSL modem connected to BEFSX41 Windows Vista Firewall Active including exceptions added by NCP clientNCP Secure Entry Client (http://www.ncp.de) 30-day free trial, then 100 for single user - ouch!NCP PROFILE SETTINGS (all others left as installed)Basic Settings - Profile Name: anything goes, for user reference to identify profile Connection Type: VPN Connection to IPSec Gateway Communication Medium: LAN (over IP) - works with either ethernet or wireless adapter on remote hostLine Management - Connection Mode: manual Inactivity Timeout: 800 secondsIPSec General Settings - Policy Lifetimes: Duration is selected and greyed out, size had no effectAdvanced IPsec Options - all uncheckedIdentities - Type: Fully Qualified Username - or - IP address (BEFSX41 set to "Any") ID: "computername" - or - "0.0.0.0" Preshared Key: the "secret" wordIP Address Assignment - Assignment of the private IP address: local IP address IP Address: left grayed out 0.0.0.0 DNS/WINS Servers: unchecked, 0.0.0.0Remote Networks - (this is the local subnet on the BEFSX41) 192.168.1.0: 255.255.255.0Certificate Check - Not ApplicableLink Firewall - Stateful inspection: when connected all others: unchecked

im having the same issues with Vista and VPN, its really starting to piss me off. i have a gateway to gateway VPN tunnel set up and it works FINE in XP... but my Vista machines just cannot find the IP address at the other end. i have tried disabling firewall, opening ports, etc... WTF is in Vista that is preventing a G2G VPN tunnel from working?!?

i still havent gotten this to work... but no responses on here isnt all that helpful either. is no one having issue with a gateway to gateway hardware VPN tunnel issue with Vista machines on the network? all my XP machines access the other network fine, but get nothing on vista machines.

All of my gateway to gateway VPN links are Windows Server 2003 to Windows Server 2003 gateways, and they are all working. I have a BEFSX41 for my home router, and I can establish a VPN connection to other VPN endpoints via IPSec, and they work as well. (I have Vista Ultimate x64.) But there are many factors that could be causing the problem you are having. For gateway to gateway scenarios, you may want to check your local routing table on the Vista machine. I have seen routing tables on Vista that have the wrong Network ID and subnet mask combinations, which will prevent routing from working properly (which includes any gateway to gateway routing). This happens quite frequently if you are using addresses in the 10.x.x.x range on either the local or remote networks. (See below for an example of this anomaly... it occurrs every time with a VPN connection to a 10.x.x.x network.) I hope that this gives you one more place to look... I share your frustration with Microsoft's ignorance with their networking disaster that they call Vista. In case you experience any VPN issues from your Vista box to a RRAS Server, read on... Otherwise, you can ignore the following related information... For VPN issues in general, It should be noted that Microsoft completely destroyed normal VPN functionality in Vista in three key areas: 1) DNS Server addresses are used in reverse order from the order that the server side issues them. Also, you cannot get Vista tocorrect the problemby statically assigning the addresses since it will still use the addresses provided by the server side before using the static addresses. 2) DNS Domain Name suffixes that are provided by the RRAS server are ignored (but you can manually enter them for each connection as long asyou do not need to dynamically assign them based on RADIUS logon credentials, as more complex networks do.) 3) The Network ID and subnet mask values are entered into the local routing table based on the IP address issued by the RRAS server instead of using what the RRAS server gives out. For example, if you are establishing a VPN connection to a network that uses a network of 10.1.1.0/24 (aka 10.1.1.0 mask 255.255.255.0), and then to a second VPN connection to a network that uses 10.2.2.0/24, you will find that you lose connectivity to the first network, even though Vista shows that you are still connected. The truth is that you actually are still connected to both networks, but your routing table is now corrupt. In this example, the routing table should have (among other entries) two routes that look like this (likely with different gatweway and interface addresses): Network Destination Netmask Gateway Interface Metric 10.1.1.0 255.255.255.0 10.1.1.25 10.1.1.2711 10.2.2.0 255.255.255.010.2.2.2110.2.2.29 11 But in Vista, when you establish the first connection you get this: Network Destination Netmask Gateway Interface Metric 10.0.0.0 255.0.0.0 10.1.1.25 10.1.1.27 11 And, when you establish the second connection, instead of getting a second entry, the first one is overwritten like this: Network Destination Netmask Gateway Interface Metric 10.0.0.0 255.0.0.0 10.2.2.2110.1.1.2911 To correct this, even after establishing both VPN connections, you can delete the 10.0.0.0 route entry, and add the two entries that are correct. Once you do that, you will immediately regain access to both remote networks. Has anyone other than myself reported these issues to Microsoft? I think the only way we can get them to fix their broken product is for all of us to call and complain like I have. The more voices that are heard, the more pressure Microsoftbe underto fix what they broke. I wish you and everybody else with Vista networking issues the very best. PS - These Operating Systems do not have these problems: Windows XP, Linux, Mac OS, etc...

i meant to come back and post to this... turns out its limited to my Vista 64bit machines as the 32bit versions access across the VPN just fine. weird... so im trying to figure out what could be different. also this machine has a static IP rather than using the DHCP.

I do have a few 32-bit Vista machines that are having the DNS issues, but may not have the routing table issue... I'll look into it. Here is what I found out regarding the routing table issue: To improve the odds of not having routing table corruption under Vistawhen connectingvia VPN to a 10.x.x.x/24 network, the server side (whichusers such as field reps that do not work directly for the companywillnot have any control over) must meet the following conditions: 1) If the RRAS server isa Microsoft RRAS Server, itmust be set up as both a router and RAS server 2) If the RRAS server isa Microsoft RRAS Server, it must be set up to allow broadcast name resolution 3) If the RRAS server isa Microsoft RRAS Server, it must be set up to use DHCP for address assignment 4) The RRAS server must have a DHCP relay agent installed and configured to point to a working DHCP server 5) There must be a working WINS server set up in the environment, and... 6) The DHCP server must give out the address of the working WINS server along with 0x8 as the node type Even with all of these steps taken, the issue is not completely eliminated... it is now intermittnet. (At least we are making some progress.) Interestingly, it looks like the RRAS server needs to be a Microsoft RRAS server for this to work. (Can you say antitrust lawsuit? I think Microsoft is already familiar with that concept.) It is important to note that Windows XP, Linux, and the Mac OS do not need all of these conditions to be met in order to work properly. Vista along with its counterpart, Windows Server 2008, are the only two operating systems that require such an extravagant set up to work properly. What did Microsoft change? (The world may never know...)