Very Computer

Attempting to setup a Checkpoint SecurePlatform (Linux +
Firewall-1/VPN-1) box to connect with Bellsouth DSL.  I've set our
Cayman 3220 into bridged mode. We have been assigned an IP address and
told to append %static to our username.  I can connect by adding


it fails.

pppd version: 2.4.1
Kernel version: 2.4.9

tcpdump:
Dynamic:
13:09:54.438084 PPPoE PADS [ses 0x5ee0] [Service-Name] [Host-Uniq
UTF8] [AC-Name "62031100014480-SMS08BCT/SMB00BCT"]
13:09:54.521971 PPPoE  [ses 0x5ee0] LCP 21: Conf-Req(196), MRU=1492,
Auth-Prot CHAP/MD5, Magic-Num=1ab70778
13:09:54.524047 PPPoE  [ses 0x5ee0] LCP 16: Conf-Req(1), MRU=1492,
Magic-Num=6e552ca6
13:09:54.524356 PPPoE  [ses 0x5ee0] LCP 21: Conf-Ack(196), MRU=1492,
Auth-Prot CHAP/MD5, Magic-Num=1ab70778
13:09:54.588124 PPPoE  [ses 0x5ee0] LCP 16: Conf-Ack(1), MRU=1492,
Magic-Num=6e552ca6
13:09:54.588916 PPPoE  [ses 0x5ee0] LCP 10: Echo-Req(0),
Magic-Num=6e552ca6
13:09:54.589986 PPPoE  [ses 0x5ee0] CHAP 40: Chal(1),
Value=d9fce828df2bf0b69ff6793edc0d4268, Name=SMS08BCT/SMB00BCT
13:09:54.590957 PPPoE  [ses 0x5ee0] CHAP 45: Resp(1),

13:09:54.636583 PPPoE  [ses 0x5ee0] LCP 10: Echo-Rep(0),
Magic-Num=1ab70778
13:09:55.670146 PPPoE  [ses 0x5ee0] CHAP 43: Succ(1), Msg=CHAP
authentication success, unit 628
13:09:55.670738 PPPoE  [ses 0x5ee0] IPCP 24: Conf-Req(1),
IP-Addr=0.0.0.0, Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0
13:09:55.673856 PPPoE  [ses 0x5ee0] IPCP 12: Conf-Req(120),
IP-Addr=67.34.251.1
13:09:55.674241 PPPoE  [ses 0x5ee0] IPCP 12: Conf-Ack(120),
IP-Addr=67.34.251.1

Static:
13:12:32.944489 PPPoE PADS [ses 0x5f93] [Service-Name] [Host-Uniq
UTF8] [AC-Name "62031100014480-SMS08BCT/SMB00BCT"]
13:12:33.094536 PPPoE  [ses 0x5f93] LCP 21: Conf-Req(175), MRU=1492,
Auth-Prot CHAP/MD5, Magic-Num=1ab72ca0
13:12:33.096478 PPPoE  [ses 0x5f93] LCP 16: Conf-Req(1), MRU=1492,
Magic-Num=6fada90c
13:12:33.096866 PPPoE  [ses 0x5f93] LCP 11: Conf-Rej(175), Auth-Prot
CHAP/MD5
13:12:33.160700 PPPoE  [ses 0x5f93] LCP 16: Conf-Ack(1), MRU=1492,
Magic-Num=6fada90c
13:12:33.162561 PPPoE  [ses 0x5f93] LCP 20: Conf-Req(176), MRU=1492,
Auth-Prot PAP, Magic-Num=1ab72ca0
13:12:33.163212 PPPoE  [ses 0x5f93] LCP 10: Conf-Rej(176), Auth-Prot
PAP
13:12:33.226883 PPPoE  [ses 0x5f93] LCP 16: Conf-Req(177), MRU=1492,
Magic-Num=1ab72ca0
13:12:33.228042 PPPoE  [ses 0x5f93] LCP 16: Conf-Ack(177), MRU=1492,
Magic-Num=1ab72ca0
13:12:33.228796 PPPoE  [ses 0x5f93] LCP 10: Echo-Req(0),
Magic-Num=6fada90c
13:12:33.229151 PPPoE  [ses 0x5f93] IPCP 24: Conf-Req(1),
IP-Addr=0.0.0.0, Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0
13:12:33.278136 PPPoE  [ses 0x5f93] LCP 6: Term-Req(178)
13:12:33.279332 PPPoE  [ses 0x5f93] LCP 6: Term-Ack(178)
13:12:33.280078 PPPoE  [ses 0x5f93] LCP 10: Echo-Rep(0),
Magic-Num=1ab72ca0

Maybe you should use

but that may not work either.

They would have to have a way of obtaining the username (or other
identifier) outside the PPP negotiations regardless of which form you
need to use.  The second (unsuccessful) log showed BS as rejecting all
forms of CHAP as well as all forms of PAP out of hand, preventing *any*
CHAP or PAP authentication negotiation.  If they had something else that
they use for authentication then I would have expected a Configure-Nak
suggesting that you use it.

No authentication = No access.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/

Hi Clifford,

I suppose the Reject was from the user.

If one does change the username in /etc/ppp/(p,ch)ap-secrects this
change has to be reflected within the command line parameters of pppd
too. This might be done by editing one of the configurations files in
/etc/ppp/ or the script causing the call or some other method of
configuration - it really depends on how the distribution does want it
to be done.

Michael

No - unless perhaps BS is paying him to make the connection. :)

If side A requests a particular type of authentication from side B
then it is requesting side B to agreed to authenticate the identity of
side A using that type.  If side B is an ISP then it is always side A
that sends those requests.  (It was rather annoying that the logging
failed to define whether a message is received or sent.)

Side B has basically three options for it's response:  agreed with a
Configure-Ack, disagree and suggest an authentication protocol it is
willing to use with a Configure-Nak, or reject the entire protocol class
with a Configure-Reject.  If it rejects all the authentication classes
that side A requests then it means that side B will not authenticate
side A at all, at least not within the PPP negotiations.

Quote:> If one does change the username in /etc/ppp/(p,ch)ap-secrects this
> change has to be reflected within the command line parameters of pppd
> too. This might be done by editing one of the configurations files in
> /etc/ppp/ or the script causing the call or some other method of
> configuration - it really depends on how the distribution does want it
> to be done.

Not in this case.  No authentication was actually attempted because
the ISP rejected of all authentication protocols that side B offered,
so what's in the secrets files doesn't matter.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/

                                                        ^^^^^^
Oops.  That should be "pppd".

Quote:> so what's in the secrets files doesn't matter.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/

Hi Clifford,

No: "Receiving a Configure-Request for this option means that the peer
wants the receiving system to identify itself using the indicated
protocol." (James Carlson; PPP Design, Implementation and Debugging;
page 77; Addison-Welsey Pearson Education; Second Edition; July 2000;
ISBN 0-201-70053-0)

Quote:> that sends those requests.  (It was rather annoying that the logging
> failed to define whether a message is received or sent.)

So it will be side B (the ISP) asking for it.

Quote:> Side B has basically three options for it's response:  agreed with a
> Configure-Ack, disagree and suggest an authentication protocol it is

And the client answers with ConfAck, ConfNak or ConfRej.

pppd will answer with ConfRej if it can not find the username given on
the command line (or in a configuration file) within either pap-secrets
or chap-secrets.

Michael

You are absolutely right.  I got it totally backward and have no good
excuse for doing so, it was pure carelessness on my part.  Thanks for
correcting my blunder!

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/

I tried it that way too....

The *only* thing difference between these two traces is the username
in the chap-secrets.  I tried a bogus username and I get the same
trace.  The username does work with the Cayman router in pppoe mode,
but I need to terminate the connection on the Checkpoint device.
Could there be a problem parsing the %static usename?

As I hope you saw, I was way off-track saying that it was BS that
rejected all authentication.  That said, if you are still having a
problem then I have to ask some silly questions since some things
aren't clear to me.  But first be aware that I've never used PPPoE
or any other kind of DSL - so it's likely that some of my questions
will be really silly.

1)  Have you talked to BS support about the problem?  If not then do so.
Confirm the username, character-by-character.  Confirm that the number
you call to connect with the static IP address is correct.   Make sure,
if you don't know it to be a certainty already, that you should be using
PPPoE for a static IP address as well as for a dynamic IP address.

2)  You said the posted messages were a tcpdump of messages.  I'm not
familiar with them, and even surprised that tcpdump recognizes them, but
there has to be a network interface up and running for tcpdump to work.
Which interface does tcpdump use?

3)  In the case of PPPoE under Linux I'd expect pppd to be involved,
so is there to be a log of PPP negotiations from pppd in /var/log/?
If so then post those.  Unless the username is passed to the ISP then
I don't see how it can be a part of the problem.  The posted log didn't
show any username; the authentication negotiations never started.

4)  Do you have the same username configured in the pppd user option as

what is in the secrets file?  (That seems to me to be irrelevant unless
the username is actually passed to BS and isn't in their database for
the connection, or authentication is attempted and the password is not
in the database.)

5)  I also don't know how Linux PPPoE and the router in bridged mode
play together.  Have you read the DSL-HOWTO, and in particular the
last sentence in section 3.1.2 (at least for the version here)?

Well, you were warned. :)

--

PPP-Q&A links, downloads:           http://ckite.no-ip.net/
/* They that can give up essential liberty to obtain a little temporary
   safety deserve neither liberty nor safety."  Benjamin Franklin */

Username confirmed...for their Cayman router.  Using the dynamic UID

I do.  I've tried the static as user%static,

the only way they provide connectivity, static or otherwise.
Disclaimer: BS only supports the Cayman 3220, blah blah...

Quote:> 2)  You said the posted messages were a tcpdump of messages.  I'm not
> familiar with them, and even surprised that tcpdump recognizes them, but
> there has to be a network interface up and running for tcpdump to work.
> Which interface does tcpdump use?

The dump is from eth1

Quote:> 3)  In the case of PPPoE under Linux I'd expect pppd to be involved,
> so is there to be a log of PPP negotiations from pppd in /var/log/?
> If so then post those.  Unless the username is passed to the ISP then
> I don't see how it can be a part of the problem.  The posted log didn't
> show any username; the authentication negotiations never started.

I'll paste these at the end of the message.  I tried adding 'debug' to
the options file, but I saw no chanage in the logged output.

No name configured, although I did try this.

Quote:> 5)  I also don't know how Linux PPPoE and the router in bridged mode
> play together.  Have you read the DSL-HOWTO, and in particular the
> last sentence in section 3.1.2 (at least for the version here)?

The bridging I'm refering to is pretty much a simple ethernet bridge
that allows only PPPoE traffic.  This mode turns off the router/NAT
functions and leaves it as a ADSL modem with an ethernet LAN
interface.  Other than line negotiation, it is a passive device.

Quote:> Well, you were warned. :)

Mar 11 08:04:08 cpmodule adsl-connect: ADSL connection lost;
attempting re-connection.
Mar 11 08:04:13 cpmodule pppd[28638]: pppd 2.4.1 started by root, uid
0
Mar 11 08:04:13 cpmodule pppd[28638]: Using interface ppp0
Mar 11 08:04:13 cpmodule pppd[28638]: Connect: ppp0 <--> /dev/pts/0
Mar 11 08:04:13 cpmodule pppoe[28639]: PPP session is 33102
Mar 11 08:04:14 cpmodule pppd[28638]: LCP terminated by peer
Mar 11 08:04:17 cpmodule pppd[28638]: Connection terminated.
Mar 11 08:04:17 cpmodule pppoe[28639]: read (asyncReadFromPPP):
Input/output error
Mar 11 08:04:17 cpmodule pppoe[28639]: Sent PADT
Mar 11 08:04:17 cpmodule pppd[28638]: Exit.

I take that to mean that you can get a dynamic PPPoE connection for your
network with the Cayman as a stand-alone device operating in some mode
other than bridged.

Quote:> but with Linux I do.

dynamic IP address assigned when the Cayman is in the bridged mode and
PPP negotiations are being conducted by pppoe/pppd on the Checkpoint.

If you can get any PPPoE connection with the static IP address using
the Checkpoint then I'd expect that user%static would be correct.

Quote:> PPPoE is the only way they provide connectivity, static or otherwise.

Okay, that figures. /:

Quote:> Disclaimer: BS only supports the Cayman 3220, blah blah...

Yeah, that would be SoP for support.

Quote:>> 2)  You said the posted messages were a tcpdump of messages.  I'm not
>> familiar with them, and even surprised that tcpdump recognizes them, but
>> there has to be a network interface up and running for tcpdump to work.
>> Which interface does tcpdump use?
> The dump is from eth1

I take it that would be eth1 on Checkpoint.  Does Checkpoint connect
to the Cayman via eth1?  If so then I'm really in over my head since
I'd expect that the Checkpoint eth1 would have to be connected to the
DSL line in order for it to negotiate the PPPoE link.

Quote:>> 3)  In the case of PPPoE under Linux I'd expect pppd to be involved,
>> so is there to be a log of PPP negotiations from pppd in /var/log/?
>> If so then post those.  Unless the username is passed to the ISP then
>> I don't see how it can be a part of the problem.  The posted log didn't
>> show any username; the authentication negotiations never started.
> I'll paste these at the end of the message.  I tried adding 'debug' to
> the options file, but I saw no chanage in the logged output.

Right, there was even less in those than in the tcpdump output.

If there is no pppd "user userid" option then how is pppd to know about
the line in the secrets file?  No wonder it rejected all authentication
options.

Quote:>> 5)  I also don't know how Linux PPPoE and the router in bridged mode
>> play together.  Have you read the DSL-HOWTO, and in particular the
>> last sentence in section 3.1.2 (at least for the version here)?
> The bridging I'm refering to is pretty much a simple ethernet bridge
> that allows only PPPoE traffic.  This mode turns off the router/NAT
> functions and leaves it as a ADSL modem with an ethernet LAN
> interface.  Other than line negotiation, it is a passive device.

It doesn't sound to me like a "passive device," it sounds like a real
DSL mode rather than a PPPoE mode.  But I've already admitted that I'm
no expert.

It seems to me that I can't contribute much more.  Your best bet
may be to post on comp.protocols.ppp and hope that someone like Bob
Carrick replies, who might be able to say with some confidence what
is happening, as well as what should be happening, in this situation.
I certainly don't have the background to do so.

Quote:> Mar 11 08:04:08 cpmodule adsl-connect: ADSL connection lost;
> attempting re-connection.
> Mar 11 08:04:13 cpmodule pppd[28638]: pppd 2.4.1 started by root, uid
> 0
> Mar 11 08:04:13 cpmodule pppd[28638]: Using interface ppp0
> Mar 11 08:04:13 cpmodule pppd[28638]: Connect: ppp0 <--> /dev/pts/0
> Mar 11 08:04:13 cpmodule pppoe[28639]: PPP session is 33102
> Mar 11 08:04:14 cpmodule pppd[28638]: LCP terminated by peer
> Mar 11 08:04:17 cpmodule pppd[28638]: Connection terminated.
> Mar 11 08:04:17 cpmodule pppoe[28639]: read (asyncReadFromPPP):
> Input/output error
> Mar 11 08:04:17 cpmodule pppoe[28639]: Sent PADT
> Mar 11 08:04:17 cpmodule pppd[28638]: Exit.

--

PPP-Q&A links, downloads:                      http://ckite.no-ip.net/

Here's a little more; you might try these:

http://www.carricksolutions.com/pppoe.htm
comp.dcom.xdsl

--

PPP-Q&A links, downloads:                      http://ckite.no-ip.net/

Or perhpas userid %static%

a Broadband gateway device- I don't believe the static IP PVC's are
sent this way; I believe they are reprovisioned to a static PVC, and