Very Computer

I am running RH 5.2 with 2.0.36 kernel with the ip_masq_vpn_patch, and
downloaded and installed (with kernel recompile) ppp-mppe-2.4.0 and
pptp-linux-1.0.3.  I am attempting to open a tunnel from my Linux box
which acts as a server, gateway, firewall, etc. for the internal home
network, to the work machine which is a Windows NT box.

I have gotten past the point of basic negotiation and successfully got
local and remote IP addresses set and the ppp0 interface comes up.
However, immediately after that, a storm of CCP messages appears,
almost all of which come in pairs that look like:

Nov 29 00:17:08 serv pppd[11493]: rcvd [CCP ConfReq id=0x4c <mppe 1 0
0 20>]
Nov 29 00:17:08 serv pppd[11493]: sent [CCP ConfRej id=0x4c <mppe 1 0
0 20>]

with the id incrementing by one each time.

Also, in /var/log/messages, I always get the following:

Nov 29 00:32:30 serv kernel: ip_fw_demasq_gre(): Inbound from
12.162.1.22 has no masq table entry.
Nov 29 00:32:55 serv last message repeated 718 times
Nov 29 00:33:52 serv last message repeated 1294 times

I have tried completely opening up my firewall and allowing
masquerading for every forwarded packet, with no change.

Does anyone have a clue what this means?  I've been struggling with it
for 3 late nights now.

I have tried every version of pppd I could find directions for using
it (2.3.8, 2.3.11) and numerous versions of pptp as well, and they all
end up doing pretty much the same thing, so I am beginning to believe
that it is some other thing specific to my system --- but what?

The initial negotiation looked pretty good and I'll include it below.

Other relevant info:

==== /etc/ppp/options: ====

lock
noauth
debug
user pixim.com\\klein
remotename PPTP
mru 1000
mtu 1000
#+chap
#+chapms
#+chapms-v2
#mppe-stateless
mppe-40
mppe-128
nodeflate
nobsdcomp
asyncmap 0xa0000

====

Initial negotiation:

Nov 29 00:17:01 serv pppd[11493]: pppd 2.4.0 started by root, uid 0
Nov 29 00:17:01 serv pppd[11493]: Using interface ppp0
Nov 29 00:17:01 serv pppd[11493]: Connect: ppp0 <--> /dev/ttyp4
Nov 29 00:17:01 serv pppd[11493]: sent [LCP ConfReq id=0x1 <mru 1000>
<asyncmap 0xa0000> <magic 0xffff9a03> <pcomp> <accomp>]
Nov 29 00:17:04 serv pppd[11493]: sent [LCP ConfReq id=0x1 <mru 1000>
<asyncmap 0xa0000> <magic 0xffff9a03> <pcomp> <accomp>]
Nov 29 00:17:04 serv pppd[11493]: rcvd [LCP ConfReq id=0x1 <mru 338>
<auth chap 81> <magic 0xa788c9c7> <pcomp> <accomp>]
Nov 29 00:17:04 serv pppd[11493]: sent [LCP ConfAck id=0x1 <mru 338>
<auth chap 81> <magic 0xa788c9c7> <pcomp> <accomp>]
Nov 29 00:17:04 serv pppd[11493]: rcvd [LCP ConfRej id=0x1 <asyncmap
0xa0000>]
Nov 29 00:17:04 serv pppd[11493]: sent [LCP ConfReq id=0x2 <mru 1000>
<magic 0xffff9a03> <pcomp> <accomp>]
Nov 29 00:17:04 serv pppd[11493]: rcvd [LCP ConfAck id=0x2 <mru 1000>
<magic 0xffff9a03> <pcomp> <accomp>]
Nov 29 00:17:04 serv pppd[11493]: rcvd [CHAP Challenge id=0x1
<aab92df2c4ef363c1b99583cf977fea4>, name = "watchguard"]
Nov 29 00:17:04 serv pppd[11493]: sent [CHAP Response id=0x1
<082466f06343e9d2aebe86b1c4256b580000000000000000987c0fe76c9a3773154a808beed7cf76d299e211ec1a3feb00>,
name = "pixim.com\\klein"]
Nov 29 00:17:04 serv pppd[11493]: rcvd [CHAP Success id=0x1
"S=18ff1e87be6cdb42e388e1913c4d6e5b7195ca5e"]
Nov 29 00:17:04 serv pppd[11493]: Remote message:
S=18ff1e87be6cdb42e388e1913c4d6e5b7195ca5e
Nov 29 00:17:04 serv pppd[11493]: sent [IPCP ConfReq id=0x1 <addr
192.168.0.1> <compress VJ 0f 01>]
Nov 29 00:17:04 serv pppd[11493]: rcvd [IPCP ConfReq id=0x1 <addr
172.16.0.1>]
Nov 29 00:17:04 serv pppd[11493]: sent [IPCP ConfAck id=0x1 <addr
172.16.0.1>]
Nov 29 00:17:05 serv pppd[11493]: rcvd [CCP ConfReq id=0x1 <mppe 1 0 0
40>]
Nov 29 00:17:05 serv pppd[11493]: sent [CCP ConfReq id=0x1]
Nov 29 00:17:05 serv pppd[11493]: sent [CCP ConfRej id=0x1 <mppe 1 0 0
40>]
Nov 29 00:17:05 serv pppd[11493]: rcvd [IPCP ConfRej id=0x1 <compress
VJ 0f 01>]
Nov 29 00:17:05 serv pppd[11493]: sent [IPCP ConfReq id=0x2 <addr
192.168.0.1>]
Nov 29 00:17:05 serv pppd[11493]: rcvd [CCP ConfAck id=0x1]
Nov 29 00:17:05 serv pppd[11493]: rcvd [CCP ConfReq id=0x2 <mppe 1 0 0
20>]
Nov 29 00:17:05 serv pppd[11493]: sent [CCP ConfRej id=0x2 <mppe 1 0 0
20>]
Nov 29 00:17:05 serv pppd[11493]: rcvd [IPCP ConfNak id=0x2 <addr
172.16.100.2>]
Nov 29 00:17:05 serv pppd[11493]: sent [IPCP ConfReq id=0x3 <addr
172.16.100.2>]
Nov 29 00:17:05 serv pppd[11493]: rcvd [CCP ConfReq id=0x3 <mppe 1 0 0
20>]
Nov 29 00:17:05 serv pppd[11493]: sent [CCP ConfRej id=0x3 <mppe 1 0 0
20>]
Nov 29 00:17:05 serv pppd[11493]: rcvd [IPCP ConfAck id=0x3 <addr
172.16.100.2>]
Nov 29 00:17:05 serv pppd[11493]: local  IP address 172.16.100.2
Nov 29 00:17:05 serv pppd[11493]: remote IP address 172.16.0.1
Nov 29 00:17:05 serv pppd[11493]: Script /etc/ppp/ip-up started (pid
11496)
Nov 29 00:17:05 serv pppd[11493]: rcvd [CCP ConfReq id=0x4 <mppe 1 0 0
20>]
Nov 29 00:17:05 serv pppd[11493]: sent [CCP ConfRej id=0x4 <mppe 1 0 0
20>]

Quote:> I am running RH 5.2 with 2.0.36 kernel with the ip_masq_vpn_patch, and
> downloaded and installed (with kernel recompile) ppp-mppe-2.4.0 and
> pptp-linux-1.0.3.  I am attempting to open a tunnel from my Linux box
> which acts as a server, gateway, firewall, etc. for the internal home
> network, to the work machine which is a Windows NT box.
> I have gotten past the point of basic negotiation and successfully got
> local and remote IP addresses set and the ppp0 interface comes up.
> However, immediately after that, a storm of CCP messages appears,
> almost all of which come in pairs that look like:
> Nov 29 00:17:08 serv pppd[11493]: rcvd [CCP ConfReq id=0x4c <mppe 1 0
> 0 20>]
> Nov 29 00:17:08 serv pppd[11493]: sent [CCP ConfRej id=0x4c <mppe 1 0
> 0 20>]
> with the id incrementing by one each time.

The NT wants MS-PPC CCP with MPPE stateless mode with 40 bit encryption.
The pppd you are using either cannot do that, or is not configured to
do it.  The Microsoft mindset is that when encryption is included in a CCP
request then the CCP must be accepted, although the draft reads SHOULD.

I don't know where to get a pppd with MPPE that will work correctly, or
how to configure it.  MPPE is not a part of the standard Linux PPP.

Quote:> Also, in /var/log/messages, I always get the following:
> Nov 29 00:32:30 serv kernel: ip_fw_demasq_gre(): Inbound from
> 12.162.1.22 has no masq table entry.
> Nov 29 00:32:55 serv last message repeated 718 times
> Nov 29 00:33:52 serv last message repeated 1294 times

Don't really know little about this.  The GRE is General Routing
Encapsulation which is often used in tunneling.  The ip_fw_demasq_gre
appears to be complaining about 12.162.1.22 not having an entry in
the masquerading table.  Should that IP address have an entry in that
table, or should there be some other special exception for it?

/* All the world's a net!  And all the data in it merely packets
   come to store-and-forward in the queues a while and then are
   heard no more.  'Tis a network waiting to be switched!
           -Vint Cerf, RFC 1121 */

Cliff, thanks for the reply.  I dug more into the server side with our
company's IT people and found that actually they are using a
WatchGuard FireBox, a turnkey box with a modified Linux OS.  Sorry
about the misinformation on the initial post.

I have tried all the settings in /etc/ppp/options that I have found in
many web pages an Usenet postings, including specifying only mppe-40
encryption, and I always get the same result.

Quote:> I don't know where to get a pppd with MPPE that will work correctly, or
> how to configure it.  MPPE is not a part of the standard Linux PPP.

Correct; I downloaded ppp-mppe-2.4.0-4 (along with pptp-linux-1.0.3-1)
and that is what I am using now.

Quote:> > Also, in /var/log/messages, I always get the following:

> > Nov 29 00:32:30 serv kernel: ip_fw_demasq_gre(): Inbound from
> > 12.162.1.22 has no masq table entry.
> > Nov 29 00:32:55 serv last message repeated 718 times
> > Nov 29 00:33:52 serv last message repeated 1294 times

> Don't really know little about this.  The GRE is General Routing
> Encapsulation which is often used in tunneling.  The ip_fw_demasq_gre
> appears to be complaining about 12.162.1.22 not having an entry in
> the masquerading table.  Should that IP address have an entry in that
> table, or should there be some other special exception for it?

Late last night, I happened across a web page on ipfwd-1.0.0
(http://cag.lcs.mit.edu/~cananian/Projects/IPfwd/)where the author
explains in the package's README file how masquerading in the default
Linux kernel is only for packets originating on the internal side of
the firewall.  But in the PPTP case masquerading needs to be supported
for packets originating on either side of the firewall.  I have not
yet gotten the configuration understood yet but am pursuing this
approach next.

Hopefully progress will continue slowly... thanks for the info so far!

                      -Mike

Mike:

I'm understanding this right, the client is on the firewall?
not behind it?
-------------quote-----------
I am running RH 5.2 with 2.0.36 kernel with the ip_masq_vpn_patch, and
downloaded and installed (with kernel recompile) ppp-mppe-2.4.0 and
pptp-linux-1.0.3.  I am attempting to open a tunnel from my Linux box
which acts as a server, gateway, firewall, etc. for the internal home
network, to the work machine which is a Windows NT box.
-----------------------------

You can't run the masq patch and be a client at the same time, that
confuses the kernel and the result is:

-----------quote------------
Nov 29 00:32:30 serv kernel: ip_fw_demasq_gre(): Inbound from  
12.162.1.22 has no masq table entry.
Nov 29 00:32:55 serv last message repeated 718 times
Nov 29 00:33:52 serv last message repeated 1294 times
----------------------------
Try not loading the masq module and try it again.

Jerry Vonau