|
Posted by Howard Johnson on February 16, 2008, 12:46 pm
If you were Registered and logged in, you could reply and use other advanced 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.
|