VPN over port other than 1723
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||||||||||||||
|
Posted by =?iso-8859-1?q?Tom=E1s_=D3_h=C on February 8, 2008, 1:54 pm
Please log in for more thread options I'm working on a network at the moment where there's a firewall in place that blocks outgoing TCP segments unless their destination port is 80 or 443 (the ports assigned to HTTP and HTTPS). I want to access a VPN, and, so, obviously I'll have to access it over port 80 or 443 somehow. The VPN I'm trying to access is a private network where all the machines have private addresses (e.g. 10.*), but the router that they're behind performs NAT in order to enable the machines to access the internet via TCP and UDP. The router's NAT has an option whereby it can accept a TCP segment on the WAN on TCP port 80, and forward it to TCP port 1723 on the LAN, meaning I don't need a special VPN daemon that can listen on ports other than 1723. Hurray for that. I'm running Windows XP on the VPN server, and also on the client that wants to connect. The problem, however, is that the built-in Windows XP VPN _client_ application won't let met specify a different port. The list of possible solutions, I think, are: 1) Find the .exe/.dll for the Windows VPN client, go thru it with a HexEditor and replace 1723 with 443. So does anyone know what file this is. . ? 2) Use a different VPN client application (possibly in conjunction with a different VPN daemon application). Can anyone suggest a good one? Or if there's any other ideas, please throw them out there! -- Tomás Ó hÉilidhe | |||||||||||||||||||||||||
|
Posted by Howard Johnson on February 9, 2008, 1:01 am
Please log in for more thread options > The list of possible solutions, I think, are:
> >1) Find the .exe/.dll for the Windows VPN client, go thru it with a >HexEditor and replace 1723 with 443. So does anyone know what file this >is. . ? That won't work even if you do what you describe. The Microsoft VPN client uses port 1723 for the control channel only; a different IP protocol (not TCP and not UDP) is used for the data channel. >2) Use a different VPN client application (possibly in conjunction with
>a different VPN daemon application). Can anyone suggest a good one? See http://openvpn.net for free VPN software that does this. Look for proto tcp-client and proto tcp-server configuration parameters to do what you want. Port 443 has the best chance of working. The default proto udp works better when it can be used, but it probably won't work in your situation. You will also want to confirm that the people running the local LAN permit the use of VPN clients on their network. | |||||||||||||||||||||||||
|
Posted by =?iso-8859-1?q?Tom=E1s_=D3_h=C on February 9, 2008, 8:42 am
Please log in for more thread options Howard Johnson:
> That won't work even if you do what you describe. The Microsoft VPN
> client uses port 1723 for the control channel only; a different IP > protocol (not TCP and not UDP) is used for the data channel. Are you certain that we need to accomodate a different Transport Layer protocol? I set up a VPN daemon on my machine at home which has a private IP address (e.g. 10.*). I then went into my router settings at home and configured NAT to forward TCP segments whose destination port is 1723 from the WAN to my home machine which is running the VPN daemon. I then went to a friend's house and tried to connect to my VPN at home and it worked perfectly. Seeing as how my router's NAT only forwards TCP and UDP, how could it be that we need to accomodate a different Layer 4 protocol (keeping in mind that I've already gotten it to work perfectly)? > See http://openvpn.net for free VPN software that does this. Look for
> proto tcp-client and proto tcp-server configuration parameters to do > what you want. Port 443 has the best chance of working. The default > proto udp works better when it can be used, but it probably won't work > in your situation. But isn't UDP designed for stuff like streaming audio where it's best to ignore dropped packets and move on? Since TCP is designed for reliable transmission, would it not be better to use TCP rather than UDP? Thanks for the reply, I'm going to give openvpn.net a shot. -- Tomás Ó hÉilidhe | |||||||||||||||||||||||||
|
Posted by Howard Johnson on February 16, 2008, 12:46 pm
Please log in for more thread options >Howard Johnson:
> > >> That won't work even if you do what you describe. The Microsoft VPN
>> client uses port 1723 for the control channel only; a different IP >> protocol (not TCP and not UDP) is used for the data channel. >
> > Are you certain that we need to accomodate a different Transport >Layer protocol? I set up a VPN daemon on my machine at home which has a >private IP address (e.g. 10.*). I then went into my router settings at >home and configured NAT to forward TCP segments whose destination port >is 1723 from the WAN to my home machine which is running the VPN daemon. > > I then went to a friend's house and tried to connect to my VPN at >home and it worked perfectly. Seeing as how my router's NAT only >forwards TCP and UDP, how could it be that we need to accomodate a >different Layer 4 protocol (keeping in mind that I've already gotten it >to work perfectly)? I know that's the case with PPTP, but L2TP may be able to use TCP or UDP. Also, some routers "know" how to handle these protocols. I don't trust things to "just work"; I have to read the details carefully. >> See http://openvpn.net for free VPN software that does this. Look for
>> proto tcp-client and proto tcp-server configuration parameters to do >> what you want. Port 443 has the best chance of working. The default >> proto udp works better when it can be used, but it probably won't work >> in your situation. >
> >But isn't UDP designed for stuff like streaming audio where it's best to >ignore dropped packets and move on? Since TCP is designed for reliable >transmission, would it not be better to use TCP rather than UDP? Yes, but you typically run TCP over that UDP channel. You can run TCP over TCP, but the overhead can cause problems on lossy connections. >Thanks for the reply, I'm going to give openvpn.net a shot.
| |||||||||||||||||||||||||
|
Posted by =?iso-8859-1?q?Tom=E1s_=D3_h=C on February 11, 2008, 5:39 pm
Please log in for more thread options
Just to give an update, I got everything working perfectly by using OpenVPN. I have a "tap" interface (as opposed to "tun") which encapsulates Ethernet rather than just encapsulating IP. The result is that it's as if I've got a cable running back to my house and into my network switch; I even get my IP address from my broadband router's DHCP server! If anyone's curious as to how I got it going then just give me a shout and I'll send you my OpenVPN config files. -- Tomás Ó hÉilidhe | |||||||||||||||||||||||||
| Similar Threads | Posted |
| VPN over port other than 1723 | February 8, 2008, 1:54 pm |
| vpn port 80 | May 19, 2005, 11:17 pm |
| When connecting to VPN, got error "specified port not available" | July 28, 2005, 10:29 am |
| BEFSX41 Dead Internet Port | March 5, 2006, 11:03 pm |
| 3005 VPN does not respond on console port | May 29, 2006, 5:02 pm |
| eBay: Linksys RVS4000 4-port gigabit security router w/VPN | December 7, 2007, 5:30 pm |
> I'm working on a network at the moment where there's a firewall in
>place that blocks outgoing TCP segments unless their destination port is
>80 or 443 (the ports assigned to HTTP and HTTPS).
>
> I want to access a VPN, and, so, obviously I'll have to access it
>over port 80 or 443 somehow.