Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PPTP and VPN connection not compatible?

52 views
Skip to first unread message

Not

unread,
Jul 13, 2009, 2:18:06 AM7/13/09
to
I need to access a Mac on the LAN which I do regularly. When connected,
I sometimes need to establish an international connection to another
Mac using PPTP.

I configure PPTP in Internet Connect (the client Mac uses Tiger). I use
either Chicken Of The VNC or JollyFastVNC client for the VNC connection.

While connected via VNC, if I establish a PPTP connection originating
either at the VNC client Mac or the VNC server Mac (the server Mac uses
Leopard 10.5.6), the VNC connection freezes up; the cursor moves but
the clock does not update and none of the window controls or menus are
responsive on the display of the remote VNC server Mac.

As soon as the PPTP connection is terminated, the VNC connection is
once again normal.

Is this something that is logical? Are these communication
metholodogies mutually exclusive? Is there any way to get around this
such that both connections can be established at the same time?

Thanks.
N.

Geoffrey S. Mendelson

unread,
Jul 13, 2009, 4:29:03 AM7/13/09
to
Not wrote:
> I need to access a Mac on the LAN which I do regularly. When connected,
> I sometimes need to establish an international connection to another
> Mac using PPTP.
>
> I configure PPTP in Internet Connect (the client Mac uses Tiger). I use
> either Chicken Of The VNC or JollyFastVNC client for the VNC connection.

Let me see if I understand this correctly. You are using a Mac, lets call it
A and want to connect to another Mac, let's call it B, and want to access
the desktop of Mac B while at Mac A.

In reality the relative locations are irrelevant except for issues of figuring
out IP address and network delay.

First of all, on Leopard, the the VNC server is built in. The client is also
but I find that Jolly's Fast VNC works better. I like it better than Chicken
of the VNC. If it works on Tiger, you would IMHO be better off using it.

Second, PPTP is one of the worst ways of connecting to another Mac. It's
good if you want an Internet connection, but it's unsecured and not the
best protocol.

IMHO the best thing to do is to use SSH. If you are running your VC server
at port 5900(Mac B), you type in terminal (Mac A):

ssh -o "ConnectTimeout 30" -o "ConnectionAttempts 6"
-o "ServerAliveInterval 5" -o "ServerAliveCountMax 3"
-L 5999:ipaddressofserver:5900 -f ipaddressofserver
sleep 14400

The server is Mac B in the example above and the client is Mac A.

(all on one line or make a shell script out of it)

This creates a secure encrypted tunnel to the remote server and passes VNC
data from port 5900 to your local computer port 5999. The extra stuff is to
make the tunnel close if the connection drops, without hanging around with you
wondering why you are getting no response.

The sleep command is to keep the tunnel open for 4 hours, it will stay open
until the time expires or you disconnect VNC, whichever is later.

To access the server connect your VNC client to localhost port 5999.

Geoff.

--
Geoffrey S. Mendelson, Jerusalem, Israel g...@mendelson.com N3OWJ/4X1GM

Not

unread,
Jul 13, 2009, 10:20:26 AM7/13/09
to
On 2009-07-13 01:29:03 -0700, "Geoffrey S. Mendelson" <g...@mendelson.com> said:

> Let me see if I understand this correctly. You are using a Mac, lets call it
> A and want to connect to another Mac, let's call it B, and want to access
> the desktop of Mac B while at Mac A.

I want:
VNC access from A to B (on LAN), and simultaneously
TTPT access from A to C (internationally), or optionally,
TTPT access from B to C.

I have no control over C; it is TTPT and that I must use.

> ssh -o "ConnectTimeout 30" -o "ConnectionAttempts 6"
> -o "ServerAliveInterval 5" -o "ServerAliveCountMax 3"
> -L 5999:ipaddressofserver:5900 -f ipaddressofserver
> sleep 14400
>
> The server is Mac B in the example above and the client is Mac A.

Your example uses 2 "servers". One is supposed to be the client?

Thanks.
N.

Geoffrey S. Mendelson

unread,
Jul 13, 2009, 2:04:03 PM7/13/09
to
Not wrote:
>> ssh -o "ConnectTimeout 30" -o "ConnectionAttempts 6"
>> -o "ServerAliveInterval 5" -o "ServerAliveCountMax 3"
>> -L 5999:ipaddressofserver:5900 -f ipaddressofserver
>> sleep 14400
>>
>> The server is Mac B in the example above and the client is Mac A.
>
> Your example uses 2 "servers". One is supposed to be the client?

No, the first one says forward local port 5999 to port 5900 of the system
at the address in the middle, the second is the address of the computer
you want to run ssh on.

In most cases, they would be the same.

Here's an example I found:

http://homepage.mac.com/kelleherk/iblog/C755751163/E20060918221834/index.html

Note that he redirects local port 5900 to the remote's port 5900. The
disadvantage to doing that is then you can't have VNC enabled on your
computer as the ports conflict.

I prefer Jolly's fast VNC,

http://www.jinx.de/JollysFastVNC.html

He says it's an alpha product, I have not had a problem with it, and he
updates it often.

The whole point of doing this is that you no longer need PPTP, or any other
tunneling protocol. Note that this method is not specific to VNC, it will work
with anything. I use it with POP3, SMTPAUTH (receiving and sending email) and
SOCKS5 (I use it as an http proxy).

If your sysadmin is familar with ssh, they can set it up to use encrypted key
handshake instead of password authorization to make the remote Mac hard to
crack.

Not

unread,
Jul 13, 2009, 3:20:44 PM7/13/09
to
> I prefer Jolly's fast VNC,
>
> http://www.jinx.de/JollysFastVNC.html

Yes, Patrick (the author) and I have communicated much during my
configuration issues (nothing to do with JollyFastVNC, which is an
excellent, quick client app.). I like it very much.

> The whole point of doing this is that you no longer need PPTP, or any other
> tunneling protocol. Note that this method is not specific to VNC, it will work
> with anything. I use it with POP3, SMTPAUTH (receiving and sending email) and
> SOCKS5 (I use it as an http proxy).
>
> If your sysadmin is familar with ssh, they can set it up to use encrypted key
> handshake instead of password authorization to make the remote Mac hard to
> crack.

I have no control over the remote (international) server. They use PPTP
and that is what I must use. They have no interest in any other
protocol, I think. If I could use SSH -- it looks so much better than
PPTP -- I'd use it.

Thanks.
N.

nospam

unread,
Jul 13, 2009, 5:22:55 PM7/13/09
to
In article <h3g1ea$8rh$1...@news.eternal-september.org>, Not <n...@not.net>
wrote:

> I have no control over the remote (international) server. They use PPTP
> and that is what I must use. They have no interest in any other
> protocol, I think. If I could use SSH -- it looks so much better than
> PPTP -- I'd use it.

you need to set up split tunneling which is generally considered a
security hole.

Geoffrey S. Mendelson

unread,
Jul 13, 2009, 5:29:03 PM7/13/09
to
Not wrote:

> I have no control over the remote (international) server. They use PPTP
> and that is what I must use. They have no interest in any other
> protocol, I think. If I could use SSH -- it looks so much better than
> PPTP -- I'd use it.

If you can access the computer with PPTP and VNC, can't you turn on ssh?
It's far less of a security hole than PPTP, which sends everything unencrypted.

Bob Harris

unread,
Jul 13, 2009, 9:45:47 PM7/13/09
to
In article <h3ejit$aia$1...@news.eternal-september.org>,
Not <n...@not.net> wrote:

Most VPN connections force all communications over the VPN
connection, which means once you establish the VPN connection, all
access must come from the connection with the "international"
connection.

Most of the time it is the VPN server that establishes this
requirement and the VPN client honors the VPN server's desires.

Geoffrey S. Mendelson

unread,
Jul 14, 2009, 1:29:04 AM7/14/09
to
Bob Harris wrote:


> Most VPN connections force all communications over the VPN
> connection, which means once you establish the VPN connection, all
> access must come from the connection with the "international"
> connection.
>
> Most of the time it is the VPN server that establishes this
> requirement and the VPN client honors the VPN server's desires.


What happens in technical terms is that they each set a default route
via them as they are connected. The problem is that there can only be
one default route. You can check by opening a terminal window and typing
"netstat -r", or for IP address instead of names "netstat -rn".

Routes are taken from the most specific to the least, so a route to
a specific host is taken first, then the route to a specific subnet,
then the route to a less specific subnet if there is one, and so on.
If none of those exist, the default route is used.

Note that an interface implies a route to it's subnet, (which shows up
in a netstat), so for example if you have an ethernet interface
192.168.1.123 with a netmask of 255.255.255.0, it implies a route to
192.168.1.0 to 192.168.1.255 (.0 and .255 are special). You can see
the ip addresses of an interface by typing "ifconfig -a" or ifconfig and
the interface name, e.g. "ifconfig en0"

The VPN tunnel and the PPTP tunnel each create their own interface.

You can then use route commands to set up the proper routing.

Basicly, you want a route to the pptp tunneling host via the correct path,
a route to the VPN host (also some sort of tunnel) via the correct path,
a route to the computers (subnet, or just one) via the PPTP tunnel
and a default route to the VPN.

You can get information about the route command by typing "man route" in a
terminal window.

From there, I got that the syntax of a MacOS route command is:

route [-n] command [-net | -host] destination gateway [netmask]

This is all basic IP routing, which except for the actual syntax of the
commands is the same on UNIX, LINUX and Windows/NT/XP/VISTA so almost
any tutorial will do with some tweaking.

The reason I suggested SSH tunneling instead of PPTP, is it's much easier
to setup, much more secure, and since it only forwards IP ports on the
local computer does not mess with routing at all.

IMHO IP routing is one of those things that is very simple in concept, and
sometimes darn near impossible to "get right".

0 new messages