I setup a ppp-over-ssh vpn between my home machine and office network, but one of the last instructions in the cookbook said:
"add a new section to /etc/ppp/ppp.conf"

and the last instruction said:
"bring up the link: ppp -auto work"

Great. Close to success I thought.

But then I realized that though I have a /etc/ppp directory, there is no ppp.conf file. Besides, there is no ppp binary, either.
I have pppd, instead. I thought these are different programs, so I downloaded and wanted to install the ppp.rpm, but my system said it conflicts with the already installed ppp.rpm.

My questions are:
- if I have ppp.rpm installed, why do not I have a neat ppp binary, and ppp.conf file?
- can I bring up the link using the pppd binary just like I would do it with the ppp binary: pppd -auto work
(Where "work" should be a section in the non-existing ppp.conf; but that is the next question)
- where can I specify options to the pppd binary (instead of ppp.conf)?
- do these options have the same syntax as they would in /etc/ppp/ppp.conf?

Basically, all I want to do is to bring up a second ppp link (beside and through the one I have to my ISP) via ssh, without dialing, with no authentication (that is the job of ssh), with local IP 192.168.227.2 and remote IP 192.168.227.1 netmask 255.255.255.255, not becoming the defaul route, but being able to add some static routes to subnets on the remote network.

So, is it possible with pppd?

Thanks in advance!

ppp is the name of the protocol, pppd is the name of the daemon the you are going to use.


So as far as that goes they are one in the same.

Check out this script to bring up the connection

[david@zeus david]$ cat /usr/share/doc/ppp-2.4.1/scripts/ppp-on-ssh
#!/bin/sh
#
# A sample script to establish PPP session(s) via SSH 1.x
#
# Adi Masputra <adi.masputra@sun.com>
# Jan 24, 2000
#

#
# You'd definitely want to change the following addresses to suit
# your network configuration
#
LOC_IP=10.0.0.1
REM_IP=10.0.0.2
NETMASK=255.255.0.0

export LOC_IP REM_IP

#
# This is the remote peer where sshd is running, either
# its hostname or IP address
#
PPPD_RHOST=myremotehost

#
# For this example, we assume that pppd on both local and remote
# machines reside in the same place, /usr/local/bin/pppd
#
PPPD_LOC=/usr/local/bin/pppd

#
# The location of local options file (where ssh client is running).
# Note that the sample options file included in the distribution
# may need further customizations, depending on your needs. The 'noauth'
# option specified in the file is there to simplify the example, although
# some may choose to have it there and rely on ssh authentication
# instead.
#
PPPD_LOC_OPT=/etc/ppp/options-ssh-loc

#
# The location of remote options file (where sshd daemon is running)
# Note that the sample options file included in the distribution
# may need further customizations, depending on your needs. The 'noauth'
# option specified in the file is there to simplify the example, although
# some may choose to have it there and rely on ssh authentication
# instead. Also note that the remote options file need to include the 'notty'
# options for this to work.
#
PPPD_REM_OPT=/etc/ppp/options-ssh-rem

#
# The location of ssh client on the local machine
#
SSH_LOC=/usr/local/bin/ssh

export PPPD_LOC PPPD_LOC_OPT PPPD_REM_OPT PPPD_RHOST SSH_LOC

#
# Uncomment the following to enable IPv6, note that the IPv6 support
# needs to be enabled during compilation
#
# PPPD_IPV6='+ipv6 ipv6cp-use-ipaddr'
export PPPD_IPV6

#
# And execute pppd with the pty option, specifying ssh client as the
# slave side of the pseudo-tty master/slave pair. Note that on this example,
# ssh has been compiled to allow NULL encryption (thus the '-c none' option),
# but in reality, you'd probably want to specify the encryption algorithm.
# See the man page of ssh(1) for details.
#
exec $PPPD_LOC \
pty '$SSH_LOC -c none $PPPD_RHOST $PPPD_LOC $REM_IP:$LOC_IP $PPPD_IPV6 file $PPPD_REM_OPT' \
$LOC_IP:$REM_IP netmask $NETMASK $PPPD_IPV6 file $PPPD_LOC_OPT

[david@zeus david]$

I could bring up the link with a pppd command very similar to that you posted.
The problem is that it does not work very well.

When I ping the remote end of the link, ping replies do not show up in the xwindow where I issued the ping command, meanwhile I see every single byte in the xwindow where I started pppd daemon, and so I see that the replies come back.

I think this may do something with the fact that the the default ip-up script is automatically run when I bring up the link. (They should not)

How can I disable running those scripts just for this link? (However, I need them to connect to my ISP) I did not see anything in /etc/ppp/options that calls these scripts.

As for the ppp binary: it is actually there on FreeBSD, so it not just a protocol name, but also the name of a program (which I do not have on Linux).

I have never tried it so I don't know what the problem would be.


I guess one thing to try is to check the mru of the primary connection, then set the mru of the secondary connection to be at least 40 below that, maybe 80 would be even better.

Sorry, my previous post was not quite accurate: the first ping reply always shows up in the xwindow of ping, but the others are only shown up on the xwindow of pppd. (The same applies if I do it all in the konsole)
In the meantime I added a static route to our internal network (192.168.226.0/24). I could also ping any other host on that network, but there is the same problem: only the first ping reply shows up. It looks like as if the ping replies would be received by pppd, but would not be passed to ping.
I will try to reduce MRU, thanks for the tip.

pppd should be running in daemon mode. So when you start it the terminal should return to the users prompt.

Maybe we need to do some more troubleshooting of the connection.

Add these two line to /etc/syslog.conf

local2.* /var/log/ppp
daemon.* /var/log/ppp

Then restart the syslog daemon

killall -1 syslogd


Then you can monitor the file like this

tail -f /var/log/ppp

Note: the ppp file may contain sensative data so you might want to turn it off and remove it when your done.


Another thing you could do is add this option to pppd

record filename

Then check out the file "filename"
I'm not sure if that would be of use or not.

Hoping that the command-line options take precedence over the default configuration options (whatever the config file of pppd is) I put all options on the command line that expressly denies:
- any compression methods
- anything that seemed to me too specific to default connections to ISPs,
and look what happened: it began to work!
I could even mount an smb share from an other server on the office network.

Thanks for your help!

cool

maybe you should post the commandline your using for other prople that may want to try it.

Here are some details:
My reference document was: http://unix.za.net/gateway/documenta.../vpn/fbsd.html
Changes from reference document:
- my home machine (client) is Linux, not Freebsd, so I had to use pppd there instead of ppp
- my Linux client has no network attached
- I choosed 192.168.227.1 and 192.168.227.2 as the server and client ppp interface IP addresses, respectively
- I did not create a vpn user (for the case of simplicity), but used the root account instead. I would not recommend this to anyone; I only risked it as this was only a temporary test setup, and the firewalls restricted access to the ssh port on the server and client, too

So here is the minimum command line that could bring up the ppp-over-ssh link on my Linux client:
pppd nodeflate noauth 192.168.227.2:192.168.227.1 pty "ssh -l root -i /etc/ppp/ppp.key server.foo.bar"

For me the "nodeflate" parameter has proven to be critical: the link did not work without that. It is probably due to an incompatibility in the ppp compression protocols used by the FreeBSD 4.4 server and my Linux client.

Now I also have a problem regarding to pppossh. I refered the article -- http://pptpclient.sourceforge.net/routing.phtml. My environment is "Romote
IP of tunnel is the same as IP of server". I followed the instructions to do
configuration. But the routing still works. Packets cannot go through tunnel.
Any commnet ??!!!!

It's possible that it would be due to packet size, you can try setting the mtu and mru size.

I have seen the problem on pppoe which is fixed by mss clamping. Setting the packet size to be 40 or 80 less than the interface is now should be good..

did the mtu size change work, I have been trying to get routing to work over a ppp connections for some time. I haven't had the chance to test it yet but my research indicates you either have to add a new route on the connection open and tear it down when connection closes or use ipchains/iptables to add routing through the ppp connection

To add a root on FreeBSD was as easy as adding this line to the relevant section of /etc/ppp/ppp.ini:
add 192.168.2.0/24 HISADDR

The above line tells ppp to automatically add a root to the remote 192.168.2.0/24 network via the IP address of the ppp interface once the link is up.

There must be a similar, automatic solution for the Linux pppd daemon, too, but I still could not find out what configuration files it uses and how to add custom settings for specific links.
(I must admit that I did not seach for the pppd config files very hard, because my final aim was to connect two FreeBSD LANs together, and I could do that easily using ppp. At home (Linux), I add the route manually at present.)

Just one last note: I mentioned in my previous posts that I could not bring up the link without the nodeflate parameter, and I suspected there is some incompatibility between the FreeBSD ppp and the Linux pppd deflate implementations.
It turned to be true: the FreeBSD ppp manual mentions this incompatibility with pppd 2.3.x, and points out that you either use the nodeflate parameter on the pppd client (no deflate compression) or start ppp on the server with the deflate24 parameter, which makes the ppp server and pppd client correctly negotiate the deflate compression.