I realize that VPN issues have been beaten to death in various forums on this site, but...
How in the heck does Windows Mobile 2003 do VPN? Put another way, how does one tell the Axim to use a particular VPN connection at a particular time? Frankly, I'm just confused. On a PC, VPN connections act more or less like dial-up connections. On the Axim, I set up the connection and then what? No documentation I've found explains this.
Judging from the "documentation" (and I use the term loosely) in the help file on the device, all one needs to do is enter the info and it just works like magic. But it doesn't.
If anyone can shed any light on this for me, I'd be grateful. My guess is that my background as a computer tech is somehow blinding me to the obvious.
A little background on the situation: Everything is a-ok on my home WiFi network. My issue is trying to connect at the university, which uses a VPN for security. I know the server name and that it uses PPTP. I'm getting an IP address from the DHCP server, but I'm not able to browse the web, check email, etc, presumbably due to the VPN.
BTW, I've been waiting for two weeks for a reply from the university IT staff. My guess is that they have no idea how to solve the problem and are waiting on me to send them a solution after I've made it work...
lol at the last part. I use PPC2002 so for WM2003 I'm as in the dark as you are. I used to use Movian which was an IPSec client. But it did not function like a dialup. More like a switch. Turn it on and I had encryption, turn it off and no encryption.
__________________
Always read stuff that will make you look good if you die in the middle of it.
Tap Select Networks. Under "Programs that automatically connect to a private netowkr should connect using," tap New. Enter your VPN settings in the VPN tab here.
Soft reset to lock in the freshness.
Now, when you tap the connectivity icon (the double arrow next to the clock) you'll have an option to connect to the new network you just created.
The reason I say this might work is that while I have the option to connect, I'm told there's a "problem" connecting to the VPN server. Precisely what kind of "problem" isn't specified. I'm still working on that part... might have something to do with my university's VPN setup.
The reason I say this might work is that while I have the option to connect, I'm told there's a "problem" connecting to the VPN server. Precisely what kind of "problem" isn't specified. I'm still working on that part... might have something to do with my university's VPN setup.
Troy
Any luck so far ??
I've having the same issue with pptp on the WindowsMobile VPN since WM2002 and even after I switched to WM2003SE the problem didn't change.
At our university the IT-Saff told me that there should be a bug in the VPN software of my PPC or maybe Dell didn't implement this feature because of the cost.
For me this explanation sounds like bullsh***. Even Google couldn't help me much. :waaa:
I only got the error message (Your Username / password might be wrong).
Does maybe anybody know the maximum size of the password for VPN? (we are using 20 characters - so maybe this could be the point)
I've been trying to find out as much as I can about VPNs on my Axim X50v. I finally found the "key" today on another site. I have yet to see it mentioned here at all, in my searches, so I figured i'd mention it here in case others haven't seen it yet.
The "key" is that VPN communication will only work inside the network with addresses that don't use a period! Sounds silly, but I'll bet it's stumped a lot of people.
For instance, once you establish a VPN connection, and open up PIE or Netfront or Terminal Services, you CANNOT use an IP address (blah.blah.com or #.#.#.#). If you do, it redirects the request to the internet (sometimes dropping the VPN connection in the process). But let's say you've got a computer called "BKF" inside the VPN network. If you've got a VPN connection properly setup (in the connections menu) and, for instance, open up Terminal Services Client, and tell it to connect to BKF (intead of an actual IP address), it'll automatically connect the VPN and then make the request over the VPN connection. I had always tried using the actual IP address of my computer on the network, but that was wrong.
I should also mention I use pockethosts. I don't know it this is required, but I have BKF set as the IP address it really is on the network inside the VPN.
I'm tickled that I got it working tonight. I was able to VPN into my home computer from my fiance's sister's house over her wireless router, fire up Internet Explorer on the computer, log into a wireless internet camera I have set up at work, and watch a rat trying to knock over a peanut butter jar on top of the fridge (don't ask... heh), in real-time!
I've heard that the PPC VPN is pretty picky about what VPN servers it'll connect with, but it connected with my home 3Com VPN router just fine using PPTP.
Here's the site I used to setup the VPN connection.
I still have yet to figure out how to connect to a VPN over a Bluetooth connection to my SE T616 GSM phone. The actual VPN connection never seems to establish like it does with WI-FI, even though I have internet access.
Guess that's my next project... Trying to figure that one out.
For instance, once you establish a VPN connection, and open up PIE or Netfront or Terminal Services, you CANNOT use an IP address (blah.blah.com or #.#.#.#). If you do, it redirects the request to the internet (sometimes dropping the VPN connection in the process).
You can't use a public IP, but local IPs (on the other end of the VPN) work just fine. I VPN in to my work computer and I can use the local address (192.168.x.x) it's using for VPN to connect via Terminal Services or whatever.
Odd. I can't do that. On my X50v it'll either just not work, or it'll drop the VPN connection. I HAVE to use a computer name, and not an IP in Terminal Services, or it won't work. I'm also using 192.168.x.x addressing.
Not sure what the difference is, but I know after I read that information about not using addresses with periods in it), it worked.
The first question you need to ask is what flavor of VPN are you using? There is more than one version. There is IPSec and L2TP. Microsoft supports L2TP. Were I work we do not allow L2TP. If you need IPSec and not L2TP, see this thread with a client that supports it http://www.aximsite.com/boards/showthread.php?t=67793.
If you need L2TP, then there is another problem with L2TP that will not let it work through NAT (Network Address Translation). This is what I think all Cable/DSL routers do. The router has a "real" IP addresses and the PCs on the back side use "private" IP addresses. I have heard some devices now support Pass Through on L2TP, but I have neever checked.
We had to enable IPSec NAT Traversal (Port 10001) on our Contivity servers due to NAT Router connection issues. So, it appears that this NAT issues can occur with IPSec. Also, I believe XP SP2's IPv6 improved VPN connections from behind NAT routers. What are your thoughts on this DL?
Odd. I can't do that. On my X50v it'll either just not work, or it'll drop the VPN connection. I HAVE to use a computer name, and not an IP in Terminal Services, or it won't work. I'm also using 192.168.x.x addressing.
I suppose it depends on what flavor of VPN you're using. I use the MS VPN software - if you want to use the local IP of the machine you're connecting to, the trick is to make sure you enter the IP it's using for the VPN, not the normal LAN IP.
L2TP does work behind a NAT router as long as the router supports pass-through; I have a Linksys WRT54G, and they finally got that functionality working correctly in the latest firmware.
We had to enable IPSec NAT Traversal (Port 10001) on our Contivity servers due to NAT Router connection issues. So, it appears that this NAT issues can occur with IPSec. Also, I believe XP SP2's IPv6 improved VPN connections from behind NAT routers. What are your thoughts on this DL?
All VPN concentrators call these terms something slightly different. There is first what I prefer to call pure IPSec. This sends and outbound UDP 500 and the concentrator replies back with either IP protocal 50 or 51.
For this to work through NAT, the device needs to support IPSec pass through. If you are using a version of NAT called PAT (Port Address Translation), then there is still another issue. If two or more clients tried to connect to the same concentrator via the same router, then there is a problem. The device doing the address translation can not tell the streams apart. We got this all the time when several people from our company all attended the same conference and stayed in the same hotel.
The next version I like to call IPSec via TCP port 10000 for Cisco. It looks like Contivity uses port 10001. This fixed two problem. First if the device doing NAT was old and did not support IPsec pass through, then this option would get around it. It also gets around the more that one user problem, because it will create data streams the NAT device can tell apart.
The last version I like to call IPSec via L2TP which is what Microsoft VPN does. Even with Contivity, they make there own client that most people use. The problem with L2TP is the same problem you can run into with several applications when you go through NAT, the source IP address is included in the packet. For most things, this is not a problem. As an example, if you are behind a Linksys Cable/DLS router your PC will have a 192.168.1.XXX IP address. When you go through the Linksys router, the source address gets changed to the IP address the router got from the IPS. With other applications, they just fix that in the packet during the address translation.
The problem is that most IPSec traffic is encrypted, so it is not possible to change it. I have heard that changes are being made to L2TP by Microsoft to correct this. We do not use it, so I have not checked into it though. All that is needed is to remove the source IP address reference from the encrypted payload. It might be as easy as just having the VPN concentrator ignore the fact that the source address of the packet is different from the source address of the encrypted packet. The best way to find if this has been corrected is to check with someone who actually uses IPSec via L2TP.
Follow Us
RSS Feed
Follow on Twitter
Facebook
YouTube
Addicted Member
