shh pppd vpn

I've successfully got SSH and PPPD creating a VPN.

Now, I'm setting it up on a couple of different computers and getting very
confused.

It seems the pppd at the remote end is never completing its negotiation
but the local end thinks it has.

Logs are appended.

Questions:

1. I don't understand why I'm seeing .130 as well as .131 addresses in
the debug log. Does this make sense? Shouldn't the log only
show address on the PPPD link (i.e. 10.1.1.99 and 212.7.16.131)?

2. I'm also not clear on the whether firewall rules are required for
the link to complete negotiation. The 212.7.16.130 computer is a
live firewall so I can add firewall rules, but I can't take
the firewall down for testing purposes.
In other words, do the packets on the PPPD link go through
ipchains before they are allowed out?

3. In the PPPD logs, the IP address shown confuses me. In a rcvd
message is it the sender, and in the send message is it the
receiver (target)? Or is vice versa?
The 10.1.1.99 computer seems to be sending and receiving packets
to/from itself, as does the 212.7.16.131 computer?
Does this indicate the SSHD is echoing? I have almost the identical
SSH setup on a VPN that works fine.

******************************

The remote computer is 212.7.16.130 (not its real address - obfuscated
for security reasons).

The script command (runs as root on the local computer):

/usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log debug updetach \
noauth nobsdcomp nodeflate passive \
pty '/usr/bin/ssh -P -C -i /home/vpntest/.ssh/id_vpntest \
212.7.16.130 -lvpntest \
-o BatchMode=yes sudo \
/usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log nodetach \
notty noauth nobsdcomp nodeflate debug ipparam vpntest' \
ipparam vpntest,10.1.0.0/16,212.7.16.0/24 10.1.1.99:212.7.16.131

route add -net 212.7.16.0 netmask 255.255.255.0 gw 212.7.16.131

The ip-up.local on the local computer does this:

ipchains -A forward -s $SERVER_NET_SLASH -d $CLIENT_NET_SLASH -j ACCEPT
ipchains -A forward -d $SERVER_NET_SLASH -s $CLIENT_NET_SLASH -j ACCEPT

where SERVER_NET_SLASH is 212.7.16.0/24
and CLIENT_NET_SLASH is 10.1.0.0/16

(extracted from data passed with the ipparm argument).

The ip-up-local on the remote computer is never executed.

*****************************************

The PPPD debug log from the 212.7.16.130 computer.

***********************
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
sent [IPCP ConfReq id=0x1 <addr 212.7.16.130>]
rcvd [IPCP ConfReq id=0x1 <addr 10.1.1.99>]
sent [IPCP ConfAck id=0x1 <addr 10.1.1.99>]
rcvd [IPCP ConfNak id=0x1 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x2 "No network protocols running"]
sent [LCP TermReq id=0x3 "No network protocols running"]
Connection terminated.
Couldn't release PPP unit: Invalid argument
Waiting for 1 child processes...
script pppd (charshunt), pid 17273
Script pppd (charshunt) finished (pid 17273), status = 0x0
*********************************

The PPPD log from the local computer (10.1.1.99)

************************************
script /usr/bin/ssh -P -C -i /home/vpntest/.ssh/id_vpntest
212.7.16.130 -lvpntest -o
BatchMode=yes sudo /usr/sbin/pppd logfile /tmp/pppd.log nodetach notty
noauth n
obsdcomp nodeflate debug ipparam vpntest, pid 6102
using channel 233
Using interface ppp2
Connect: ppp2 <--> /dev/pts/3
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
sent [IPCP ConfReq id=0x1 <addr 10.1.1.99>]
rcvd [IPCP ConfReq id=0x1 <addr 212.7.16.130>]
sent [IPCP ConfNak id=0x1 <addr 212.7.16.131>]
rcvd [IPCP ConfAck id=0x1 <addr 10.1.1.99>]
rcvd [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
sent [IPCP ConfAck id=0x2 <addr 212.7.16.131>]
local IP address 10.1.1.99
remote IP address 212.7.16.131
Script /etc/ppp/ip-up started (pid 6302)
Script /etc/ppp/ip-up finished (pid 6302), status = 0x0
*************************************

4 hours into this now, and not making progress.

tia,
RR

RR <(E-Mail Removed)> wrote:
> I've successfully got SSH and PPPD creating a VPN.

> Now, I'm setting it up on a couple of different computers and getting very
> confused.

> It seems the pppd at the remote end is never completing its negotiation
> but the local end thinks it has.

> Logs are appended.

> Questions:

> 1. I don't understand why I'm seeing .130 as well as .131 addresses in
> the debug log. Does this make sense? Shouldn't the log only
> show address on the PPPD link (i.e. 10.1.1.99 and 212.7.16.131)?

The 212.7.16.130 IP address is picked up by pppd from a LAN interface
on the machine that requested it. Add the pppd option noipdefault to
prevent that (more below). Doing that may solve the problem. "May"
because I haven't done PPP over a ssh connection and there are many
things in your post that I don't feel qualified to comment on.

> 2. I'm also not clear on the whether firewall rules are required for
> the link to complete negotiation. The 212.7.16.130 computer is a
> live firewall so I can add firewall rules, but I can't take
> the firewall down for testing purposes.
> In other words, do the packets on the PPPD link go through
> ipchains before they are allowed out?

The PPP link negotiations are not affected by the firewall in any way.

The IP packets that go in and out a completed pppd/ssh tunnel are subject
to the firewall rules.

> 3. In the PPPD logs, the IP address shown confuses me. In a rcvd
> message is it the sender, and in the send message is it the
> receiver (target)? Or is vice versa?

A rcvd message is from the remote host; a send message is from the local
host. local host = whichever host with the logs containing the messages.

> The 10.1.1.99 computer seems to be sending and receiving packets
> to/from itself, as does the 212.7.16.131 computer?

No, at least I saw no evidence in the logs that was happening. What makes
you think it was?

> Does this indicate the SSHD is echoing? I have almost the identical
> SSH setup on a VPN that works fine.

Insufficient information for a meaningful answer.

> ******************************

> The remote computer is 212.7.16.130 (not its real address - obfuscated
> for security reasons).

> The script command (runs as root on the local computer):

> /usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log debug updetach \
> noauth nobsdcomp nodeflate passive \
> pty '/usr/bin/ssh -P -C -i /home/vpntest/.ssh/id_vpntest \
> 212.7.16.130 -lvpntest -o BatchMode=yes sudo \
> /usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log nodetach \
> notty noauth nobsdcomp nodeflate debug ipparam vpntest' \

The noipdefault can be added just after vnptest above. You might also
add " 212.7.16.131:" - without the quotes - to minimize IPCP negotiations.

> ipparam vpntest,10.1.0.0/16,212.7.16.0/24 10.1.1.99:212.7.16.131

> route add -net 212.7.16.0 netmask 255.255.255.0 gw 212.7.16.131

> The ip-up.local on the local computer does this:

> ipchains -A forward -s $SERVER_NET_SLASH -d $CLIENT_NET_SLASH -j ACCEPT
> ipchains -A forward -d $SERVER_NET_SLASH -s $CLIENT_NET_SLASH -j ACCEPT

> where SERVER_NET_SLASH is 212.7.16.0/24
> and CLIENT_NET_SLASH is 10.1.0.0/16

> (extracted from data passed with the ipparm argument).

> The ip-up-local on the remote computer is never executed.

That's because PPP there never comes up for IP (i.e., completes IPCP
negotiation).

> *****************************************

> The PPPD debug log from the 212.7.16.130 computer.

> ***********************
> Using interface ppp0
> Connect: ppp0 <--> /dev/pts/1
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 212.7.16.130>]
> rcvd [IPCP ConfReq id=0x1 <addr 10.1.1.99>]
> sent [IPCP ConfAck id=0x1 <addr 10.1.1.99>]
> rcvd [IPCP ConfNak id=0x1 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]

An Ack for the above request was sent by the other host but wasn't
received by this one. I'm not sure why, but the noipdefault and IP
address options suggested above should allow negotiations to complete
without a Nak from the other host.

> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> IPCP: timeout sending Config-Requests
> sent [LCP TermReq id=0x2 "No network protocols running"]
> sent [LCP TermReq id=0x3 "No network protocols running"]
> Connection terminated.
> Couldn't release PPP unit: Invalid argument
> Waiting for 1 child processes...
> script pppd (charshunt), pid 17273
> Script pppd (charshunt) finished (pid 17273), status = 0x0
> *********************************

> The PPPD log from the local computer (10.1.1.99)

> ************************************
> script /usr/bin/ssh -P -C -i /home/vpntest/.ssh/id_vpntest
> 212.7.16.130 -lvpntest -o BatchMode=yes sudo /usr/sbin/pppd
> logfile /tmp/pppd.log nodetach notty
> noauth nobsdcomp nodeflate debug ipparam vpntest, pid 6102
> using channel 233
> Using interface ppp2
> Connect: ppp2 <--> /dev/pts/3
> rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xdc10908c> <pcomp> <accomp>]
> rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xcbd17750> <pcomp> <accomp>]
> sent [IPCP ConfReq id=0x1 <addr 10.1.1.99>]
> rcvd [IPCP ConfReq id=0x1 <addr 212.7.16.130>]
> sent [IPCP ConfNak id=0x1 <addr 212.7.16.131>]
> rcvd [IPCP ConfAck id=0x1 <addr 10.1.1.99>]
> rcvd [IPCP ConfReq id=0x2 <addr 212.7.16.131>]
> sent [IPCP ConfAck id=0x2 <addr 212.7.16.131>]

This Ack wasn't received by the other host.

> local IP address 10.1.1.99
> remote IP address 212.7.16.131
> Script /etc/ppp/ip-up started (pid 6302)
> Script /etc/ppp/ip-up finished (pid 6302), status = 0x0
> *************************************

Here the PPP negotiations successfully completed, apparently before
receiving the duplicate configure requests from the other host for
212.7.16.131. So this pppd didn't know that the Ack it sent was not
received at the other host.

> 4 hours into this now, and not making progress.

> tia,
> RR

Good Luck!

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Emacs vs vi:
Sort of like a Swiss Army knife versus a rapier. */

Hi Clifford,

Thanks for your reply.

>
> The 212.7.16.130 IP address is picked up by pppd from a LAN interface
> on the machine that requested it. Add the pppd option noipdefault to
> prevent that (more below). Doing that may solve the problem. "May"
> because I haven't done PPP over a ssh connection and there are many
> things in your post that I don't feel qualified to comment on.

I think you were correct or close to it here. I fixed the problem by
telling the remote end what IP addresses to use:
********
/usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log debug updetach \
noauth nobsdcomp nodeflate passive \
pty '/usr/bin/ssh -P -C -i /home/vpntest/.ssh/id_vpntest \
212.7.16.130 -lvpntest \
-o BatchMode=yes sudo \
/usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log nodetach \
notty noauth nobsdcomp nodeflate debug ipparam vpntest
212.7.16.131:10.1.1.99' \
ipparam vpntest,10.1.0.0/16,212.7.16.0/24 10.1.1.99:212.7.16.131
**********

The addition is the switch of the local and remote IP addresses on the
second last line
above (after "debug ipparam vpntest").

Now, the negotiation completes.

> The PPP link negotiations are not affected by the firewall in any way.

Thanks for confirming this.

> > The 10.1.1.99 computer seems to be sending and receiving packets
> > to/from itself, as does the 212.7.16.131 computer?
>
> No, at least I saw no evidence in the logs that was happening. What makes
> you think it was?
>

The log on 10.1.1.99 has this:

************************************
sent [IPCP ConfReq id=0x1 <addr 10.1.1.99>]
rcvd [IPCP ConfReq id=0x1 <addr 212.7.16.130>]
sent [IPCP ConfNak id=0x1 <addr 212.7.16.131>]
rcvd [IPCP ConfAck id=0x1 <addr 10.1.1.99>]
************************************

So, here's my reasoning:
1. Assume "sent" shows the IP address the packet is sent "to":
then 10.1.1.99 is sending to itself (line 1).
2. Assume "sent" shows the IP address the packet is sent "from":
then 10.1.99 is sending a packet and showing itself as
"212.7.16.131" (line 3).

#2 seems less likely, so I conclude #1.

3. Assume "rcvd" shows the IP address the packet is sent "to":
then 10.1.1.99 has received a packet addressed to "212.7.16.130"
(line 2).
4. Assume "rcvd" shows the IP address the packet is sent "from":
then 10.1.99 is has received a packet from itself (line 4).

#3 seems less likely, so I conclude #4.

Either the meanings of the IP addresses shown are changing, or I'm
very confused. :-)

I guess the meaning of the IP address could be related to the type of packet
(ConfReq is different from ConfAck, etc), but I'm still not clear what it's
telling me.

Anyway, thanks for your help. I still haven't got this working, but the
negotiation is completing and I think I've just got problems with firewall
rules now.

If you can clarify the log entry IP address information, I would be very
grateful.

regards,
RR

RR <(E-Mail Removed)> wrote:
> Hi Clifford,

> Thanks for your reply.

>> The 212.7.16.130 IP address is picked up by pppd from a LAN interface
>> on the machine that requested it. Add the pppd option noipdefault to
>> prevent that (more below). Doing that may solve the problem. "May"
>> because I haven't done PPP over a ssh connection and there are many
>> things in your post that I don't feel qualified to comment on.

> I think you were correct or close to it here. I fixed the problem by
> telling the remote end what IP addresses to use:
> ********
> /usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log debug updetach \
> noauth nobsdcomp nodeflate passive \
> pty '/usr/bin/ssh -P -C -i /home/vpntest/.ssh/id_vpntest \
> 212.7.16.130 -lvpntest \
> -o BatchMode=yes sudo \
> /usr/sbin/pppd novj novjccomp logfile /tmp/pppd.log nodetach \
> notty noauth nobsdcomp nodeflate debug ipparam vpntest
> 212.7.16.131:10.1.1.99' \
> ipparam vpntest,10.1.0.0/16,212.7.16.0/24 10.1.1.99:212.7.16.131
> **********

> The addition is the switch of the local and remote IP addresses on the
> second last line above (after "debug ipparam vpntest").

> Now, the negotiation completes.

Okay, that's in agreement with what you appeared to want anyway.

>> The PPP link negotiations are not affected by the firewall in any way.

> Thanks for confirming this.

>> > The 10.1.1.99 computer seems to be sending and receiving packets
>> > to/from itself, as does the 212.7.16.131 computer?
>>
>> No, at least I saw no evidence in the logs that was happening. What makes
>> you think it was?

> The log on 10.1.1.99 has this:

> ************************************
> sent [IPCP ConfReq id=0x1 <addr 10.1.1.99>]
> rcvd [IPCP ConfReq id=0x1 <addr 212.7.16.130>]
> sent [IPCP ConfNak id=0x1 <addr 212.7.16.131>]
> rcvd [IPCP ConfAck id=0x1 <addr 10.1.1.99>]
> ************************************

> So, here's my reasoning:
> 1. Assume "sent" shows the IP address the packet is sent "to":
> then 10.1.1.99 is sending to itself (line 1).

No, it's sending an IPCP request to the remote host for permission
to *use* the IP address 10.1.1.99 for itself the over PPP data link
when it's established.

> 2. Assume "sent" shows the IP address the packet is sent "from":
> then 10.1.99 is sending a packet and showing itself as
> "212.7.16.131" (line 3).

The ConfNak is a refusal to accept the remote's request to use the
IP address 212.7.16.130, in the preceding ConfReq received (rcvd)
from the remote. The ConfNak also contains a suggestion as to which
IP address the local host wants the remote to request, 212.7.16.131 in
this case. When you switched to 10.1.1.99:212.7.16.131 the Nak went
away since the remote accepted it instead of using it's LAN IP address
to negotiate with.

> #2 seems less likely, so I conclude #1.

Sorry, you're a bit confused. The local and remote hosts aren't sending
to or from the IP addresses; they are negotiating which IP addresses
will be used once the PPP link comes up for IP data at the end of the
PPP negotiations. Then, and only then, they will be IP address that are
IP datagrams are send "to" or "from" over the PPP link.

> 3. Assume "rcvd" shows the IP address the packet is sent "to":
> then 10.1.1.99 has received a packet addressed to "212.7.16.130"
> (line 2).
> 4. Assume "rcvd" shows the IP address the packet is sent "from":
> then 10.1.99 is has received a packet from itself (line 4).

> #3 seems less likely, so I conclude #4.

See my preceding comments for 1) and 2).

> Either the meanings of the IP addresses shown are changing, or I'm
> very confused. :-)

These are two hosts _negotiating_ the IP address each will use _after_
the PPP negotiations complete and IP data can be sent and received via
the network-layer using the addresses.

> I guess the meaning of the IP address could be related to the type
> of packet (ConfReq is different from ConfAck, etc), but I'm still
> not clear what it's telling me.

> Anyway, thanks for your help. I still haven't got this working,
> but the negotiation is completing and I think I've just got problems
> with firewall rules now.

> If you can clarify the log entry IP address information, I would
> be very grateful.

I've tried to clarify the log messages, but if I've failed, you might
try reading RFC 1661 and RFC 1332 - they describe PPP negotiation in
general and IPCP NCP negotiation in particular, respectively.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* 97.3% of all statistics are made up. */

Hi Clifford,

> Sorry, you're a bit confused. The local and remote hosts aren't sending
> to or from the IP addresses; they are negotiating which IP addresses
> will be used once the PPP link comes up for IP data at the end of the
> PPP negotiations. Then, and only then, they will be IP address that are
> IP datagrams are send "to" or "from" over the PPP link.
>

Now the logs make sense. Thanks!

>
> I've tried to clarify the log messages, but if I've failed, you might
> try reading RFC 1661 and RFC 1332 - they describe PPP negotiation in
> general and IPCP NCP negotiation in particular, respectively.
>

Thanks for the RFC references. I expected the PPPD man page to describe the
debug output, but I'm happy if the RFCs will clarify what the debug log is
showing.

regards,
RR