OT: cisco VPN client and NAT

Could someone point me to the best place to ask the following please?

I've got a Linux firewall system built on RedHat 9 (kernel-2.4.20-31.9)
that is performing NAT for selected systems.  We are able to establish
PPTP connections through it.  However, when we try to use the cisco VPN
client it the tunnel will not come up and in fact it never prompts for
the password.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: OT: cisco VPN client and NAT

Michael St. Laurent schrieb:
> Could someone point me to the best place to ask the following please?
>
> I've got a Linux firewall system built on RedHat 9 (kernel-2.4.20-31.9)
> that is performing NAT for selected systems.  We are able to establish
> PPTP connections through it.  However, when we try to use the cisco VPN
> client it the tunnel will not come up and in fact it never prompts for
> the password.
>   
erm .. I do not know the Cisco client in detail, but is that thing not a 
pure IPSec client? If you are saying you want to do IPSec through a NAT 
then that does not work out of the box because you alter the signed 
packets after encryption. There are possibilities but it depends on the 
IPSec _Server_ you are using. Look for "NAT traversal" or so. I think 
the rest is outta the scope of a PPTP VPN list.

Hope this helps,

Jakob Curdes

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: GRE: Discarding packet by header check

I've had the same problem as you with a Intel IXP 425 processor board. I have
PPP 2.4.3 and pptpd 1.3.4. Google returned little information on the
subject, however; this little post shows me at least that someone else
is/was having the same problem. 

I managed to solve this problem by using the "packed" attribute to the
structure defined in pptpdefs.h. The attribute is an artifact of the gcc
compiler, and may not work on other compilers. In fact, if someone have a
better way to fix it, perhaps we should have the maintainer of the pptpd
project pick up this change for future releases of pptpd?

With best regards,
- Eivind

patch:
==== //tps/pptpd/1.3.4/mainline/src/pptpdefs.h#2 (text) ====

312c312
< };
---
> } __attribute__((packed));

I also broke the if-statement apart for easier debugging and to know what
*really* failed in the check.

==== //tps/pptpd/1.3.4/mainline/src/pptpgre.c#2 (text) ====

358,365c358,384
<       if (((ntoh8(header->ver) & 0x7F) != PPTP_GRE_VER) ||    /* version

Re: Bizarre PopTop error

Hi all - 

This has worked for years and it suddenly decided to fail a little while
ago.  I just upgraded to pptpd 1.3.4 and kernel 2.6.18 with fc6 and the
symptoms still show up.  I'm sure there is some kind of buffersize
parameter someplace messed up but I'm at a loss to explain what.  

Oh yes - the problem - 

Anytime anyone connected via PopTop does an RDP session to one of the
internal PCs, or a VNC session, the entire PPTP connection drops
immediately.  I see these messages in /var/log/messages when this
happens:

Jul 18 11:41:22 bb-fw pptpd[2600]: GRE:
read(fd=7,buffer=8050e80,len=8260) from network failed: status = -1
error = Message too long Jul 18 11:41:22 bb-fw pptpd[2600]: CTRL: GRE
read or PTY write failed (gre,pty)=(7,6) Jul 18 11:41:22 bb-fw
pppd[2601]: Modem hangup Jul 18 11:41:22 bb-fw pppd[2601]: Connect time
1.3 minutes.
Jul 18 11:41:22 bb-fw pppd[2601]: Sent 12100 bytes, received 3967 bytes.
Jul 18 11:41:22 bb-fw pppd[2601]: MPPE disabled Jul 18 11:41:22 bb-fw
pppd[2601]: Connection terminated.
Jul 18 11:41:22 bb-fw pppd[2601]: Exit.
Jul 18 11:41:22 bb-fw pptpd[2600]: CTRL: Client 66.173.97.2 control
connection finished

Options.pptpd is right out of the example included with pptpd 1.3.4.
pptpd.conf is also pretty much right out of the box with this on the
bottom:

Re: Bizarre PopTop error

On Wed, 2007-07-18 at 11:58 -0500, Greg Scott wrote:
> Hi all - 
>  
> This has worked for years and it suddenly decided to fail a little while
> ago.  I just upgraded to pptpd 1.3.4 and kernel 2.6.18 with fc6 and the
> symptoms still show up.  I'm sure there is some kind of buffersize
> parameter someplace messed up but I'm at a loss to explain what.  
>  
> Oh yes - the problem - 
>  
> Anytime anyone connected via PopTop does an RDP session to one of the
> internal PCs, or a VNC session, the entire PPTP connection drops
> immediately.  I see these messages in /var/log/messages when this
> happens:
>  
> Jul 18 11:41:22 bb-fw pptpd[2600]: GRE:
> read(fd=7,buffer=8050e80,len=8260) from network failed: status = -1
> error = Message too long Jul 18 11:41:22 bb-fw pptpd[2600]: CTRL: GRE
> read or PTY write failed (gre,pty)=(7,6)

This is MTU-related.

Something is causing a GRE packet to get generated which exceeds the MTU
at some point along the path (maybe the user is on a PPPoE modem with a
149x MTU?). The GRE packets that poptop (linux) generates have the
dont-frag bit set, and the router with the MTU problem therefore returns
an ICMP "too large"; this gets propagated up to poptop on the next
read() call and the connection terminates.

To be clear - the GRE packet triggering the error is from poptop to the

Re: Bizarre PopTop error

Thank you thank you thank you thank you!

Phil, your suggestion was right on.

I'm running a VNC session right now in another window through that PPTP
tunnel.  It's been good for almost an hour so far and I haven't been
able to do this since the problem first showed up.  I also closed and
opened it again, all without issues.  I think we can declare this
problem fixed.  

Per your suggestion, I used tcpdump on the firewall to watch anything
coming from the ISP router.  Ignoring the RIP V1 messages and other
multicast junk, here is the relevant packet from a dropped connection.
(I fudged in the public IP Addresses - 1.2.3.1 is the router and 1.2.3.2
is the firewall. 11.22.33.2 is my place.)

02:01:50.708278 IP (tos 0x0, ttl 255, id 4988, offset 0, flags [DF],
proto: ICMP (1), length: 56) 1.2.3.1 > 1.2.3.2: ICMP 66.173.97.2
unreachable - need to frag (mtu 1434), length 36        IP (tos 0x0, ttl
63, id 19512, offset 0, flags [DF], proto: GRE (47), length: 1457, bad
cksum 2b2f (->2b1b)!) 1.2.3.2 > 11.22.33.2: GREv1, Flags [key present,
sequence# present, ack present], call 4571, seq 0, ack 0, length 1437
[|ppp]

Here are the rules I put in.  The only thing different than your
suggestion is, the iptables man pages say the TCPMSS target is only
valid in the mangle table.  

echo "Handling potential MTU problems"
# Thanks to Phil Mayers <p.mayers <at> imperial.ac.uk> who answered my query

PopTop does not log why I can't connect when ip-pool is exhausted.

All, 

I am testing PopTop 1.3.4 with pppd 2.4.3, and pptpd.conf specifies the
ip-pool. I then ran into the following: 

Launch PopTop with the "-C 2" to limit the number of connections to 2,  now
try to login with two clients. Observe that after two successful logins
pptpd logs this message: 

   MGR: No free connection slots or IPs - no more clients can connect!

You sit there and watch the logs pass by for 5 min and then you try to
connect with a third client. No response which is expected at this time
since you have exhausted the pool of ip-addresses. However, for debugging
purposes I'd still think that displaying the message would be appropriate. 

As a side effect in this case, if I disconnect one of the logged in clients
am seeing X number (X e [1 to 3]) of attempts to launch pptpctrl to handle
these clients. A client may be connected at this time, or what most likely
happens is that pptpctrl is launch, does nothing, and then exits (just
outputs more jumble to syslog). Once a second ip-address is allocated, you
will see the "No free connection slots or IPs" again.

After studied the code for a bit, it seems like the fd that pptpd listens
for incoming connections is never added to the file descriptor set in
pptpmanager.c and hence why the select() never wakes up to tell us about it.
In addition, the listener socket is configured to take at most 3 client
connections in its backlog.

Re: GRE: Discarding packet by header check

The packed attribute patch taken, thanks.

Does anyone else think I should take the second patch that enhances the
reporting of bad header contents?

--

-- 
James Cameron                         http://quozl.netrek.org/
HP Open Source, Volunteer             http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Poptop-server mailing list
Poptop-server <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/poptop-server

Re: OT: cisco VPN client and NAT

> Could someone point me to the best place to ask the following please?
> 
> I've got a Linux firewall system built on RedHat 9 (kernel-2.4.20-31.9)
> that is performing NAT for selected systems.  We are able to establish
> PPTP connections through it.  However, when we try to use the cisco VPN
> client it the tunnel will not come up and in fact it never prompts for
> the password.

I haven't dealt with this in a while, but IIRC NAT breaks IPsec that uses
AH.  I think you have to switch to ESP, though that presents its own
problems.

http://www.isp-planet.com/technology/2001/ipsec_nat.html

--Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/