home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.dcom.vpn      VPN protocols, clients, awesomeness      2,348 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 697 of 2,348   
   daytripper to Gerald Meazell   
   Re: Advice Request   
   11 Jan 04 19:58:09   
   
   XPost: comp.os.ms-windows.networking.misc   
   From: day_trippr@REMOVEyahoo.com   
      
   On Sun, 11 Jan 2004 15:28:29 GMT, Gerald Meazell  wrote:   
   >daytripper wrote:   
   >>   
   >>Are you trying to access the vpn server using the external address for your   
   >>modem - from a client on the LAN side of your router?   
   >>   
   >>I don't think that will work.   
   >>   
   >Well, yes, that's what I'm trying as a test.  I do have some external   
   >machines I can test with but they're a 20-minute drive down the road.  I   
   >guess I'll call over there and walk the non-techies through some   
   >testing.  I've never claimed to be up on the WAN stuff but, out of   
   >curiosity, why wouldn't it work?   
      
   I've been there, tried this about a year or more ago. Never got it working,   
   eventually got distracted and never revisited it.   
      
   If I try to access the VPN server on my LAN from another system on my LAN, by   
   using my WAN address (external IP address of my cable modem) the client side   
   attempts to connect, the server side has the same port activated, and then   
   they sit there with the "Verifying username and password" pop-up on the   
   client.   
      
   At this point, if I examine the end node ports, the client shows the correct   
   destination address and port, the server shows the router's LAN address and   
   the matching application port. That the router's LAN address shows up   
   signifies to me that the "outbound" WAN request was routed back to the LAN   
   side correctly and that the holes in the firewall at the server were correct   
   (more on that later) .   
      
   So there they sit until the attempt times out and the  "Error 721: The remote   
   computer did not repond..." message appears on the client.   
      
   Examining Event Viewer - System Events on the server shows the entry:   
   "The user connected to port VPN5-1 has been disconnected because the   
   authentication process did not complete within the required amount of time."   
      
   Ok. Now what? They can see each other so the router appears to be configured   
   correctly, and the firewall applications (on both end nodes) are allowing   
   requests out one end and in the other (ISS BlackIce PC Protection, fwiw, and   
   the same thing fails if I totally drop the firewalls), so the firewall isn't a   
   factor. I'm using the exact same username and password that works if I use the   
   *LAN* address of the server. They're both in the same domain/workgroup either   
   way. So why does this get derailed?   
      
   What makes this odd is I can access the VNC server on my LAN from a client   
   also on my LAN using the same external IP address. And the opened VNC   
   application port was opened by the router's LAN address.   
      
   So I have to take the server log at face value: something is pooching the   
   authentication process.   
      
   This is where things get interesting. The immediate suspicion is the router or   
   the firewall isn't passing IP Protocol 47 (GRE). Well, it's not the firewall,   
   as I can burrow right through it from a LAN client.   
      
   Much longer story shortened a bit: I did some Googling and various results   
   pointed me to a possible Linksys firmware problem. I ended up at   
      
   http://www.linksys.com/download/firmware.asp?fwid=3   
      
   and now have a copy of the updated firmware, fwiw.   
      
   But I may not install same as   
   (1) Everything I actually need to do works, and   
   (2) I don't consider the inability to access my VPN server from within my LAN   
   using the WAN address enough justification to possibly screw up (1)...   
      
   If, otoh, you were to give the updated firmware a try, please do let us know   
   how you make out.   
      
   /daytripper (who knows that it's the pioneers that catch the arrows ;-)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca