Topic: 5.6SME and VPN PPTP Call id issues - bug found and resolutio

[sidney]

could someone please give me easy instruction to fix this.

Thank you

[Mark Otoupal]

This is how I did it:

1) mkdir /etc/e-smith/templates-custom/etc/rc.d/init.d/masq

2) cp /etc/e-smith/templates/etc/rc.d/init.d/masq/10masq.pptp /etc/e-smith/templates-custom/etc/rc.d/init.d/masq

3) edit the 10masq.pptp in the templates-custom directory and comment out the two lines:
# /sbin/modprobe ip_nat_pptp
# /sbin/modprobe ip_conntrack_pptp

4) remove the 10masq.pptp from the templates directory

5) run /sbin/e-smith/expand-template /etc/rc.d/init.d/masq

6) reboot

The /etc/init.d/masq should now reflect the custom template changes. Hope this is easy enough.

_Mark

[Brian Mills]

Thanks, I will be trying this later when I finish work

Millsey

[Millsey]

Yes setting up exactly as Mark Otupal listed works just fine for my PPTP dial IN to the server. Thanks for all input.

Millsey

[Bill Talcott]

Mark Otoupal wrote:
>
> 4) remove the 10masq.pptp from the templates directory

Custom templates take precedence over the defaults. You do not need to remove the default template, and its absence could cause problems if you later remove your custom template.

http://www.e-smith.org/custom/

[Joost De Raeymaeker]

I installed the most recent rpms from your contrib directory, and my outbound pptp connections seem to run a LOT better. Haven't tested inbound. Do you have the code for the modules without debugging included? My log is being filled with too much information for me Everytime I open up a message in exchange (connected through the vpn), I hear my sme's disk going

Joost
PS: What I installed:
e-smith-packetfilte~3.0-07.noarch.rpm
ppp-mppe-modules-2.4.2-4es.i686.rpm
pptp-conntrack-nat-1.0.1-1es.i686.rpm

[Jim Huneycutt]

I also installed the dev PPTP contribs (ftp://ftp.e-smith.org/pub/e-smith/contrib/CharlieBrady/5.6-PPTP/) on a 5.6 test server. Unfortunately, I used it as a gateway (XP pro machine connected to the 5.6 server/gateway) to connect to a client's production SME 5.5U2 server using PPTP. I crashed the production server twice within a few hours (see my previous post http://www.e-smith.org/bboard//read.php?v=t&f=1&i=24464&t=23997). I saw that the message log on the production server was filled with hundreds if not thousands of PPTP messages. Below is a section of the message log from the second crash. After I reverted to a 5.5 server/gateway to make the connection to the 5.5 server, the server has run continuosly with no problems. I thought I was safe going OUT to connect to the production server. This behavior concerns me because of the possibility that anyone with this faulty 5.6 setup may be able to crash a production SME 5.5 server just by making a PPTP connection. Perhaps there was some other issue. Unfortunately, it is not something I want to try again to test with the client's server. If anyone else has enough test servers to try this on, the results could be useful in debugging this problem or concluding that my case was a fluke.

Thanks,
jim

MESSAGE LOG extract: (Note that the first 4 lines had been repeated hundreds of times, as though some sort of negotiation was taking place - soory I am not expert on the proper PPTP terminolgy.)
------------------------------------
Feb 19 02:52:38 gateway pptpd[1740]: CTRL: Received PPTP Control Message (type: 5)
Feb 19 02:52:38 gateway pptpd[1740]: CTRL: Made a ECHO RPLY packet
Feb 19 02:52:38 gateway pptpd[1740]: CTRL: I wrote 20 bytes to the client.
Feb 19 02:52:38 gateway pptpd[1740]: CTRL: Sent packet to client
Feb 19 02:52:58 gateway kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Feb 19 02:52:58 gateway kernel: current->tss.cr3 = 2ca55000, %%cr3 = 2ca55000
Feb 19 02:52:58 gateway kernel: *pde = 00000000
Feb 19 02:52:58 gateway kernel: Oops: 0000
Feb 19 02:52:58 gateway kernel: CPU:    0
Feb 19 02:52:58 gateway kernel: EIP:    0010:[kmalloc+81/348]
Feb 19 02:52:58 gateway kernel: EIP:    0010:[]
Feb 19 02:52:58 gateway kernel: EFLAGS: 00010006
Feb 19 02:52:58 gateway kernel: eax: f7ff86a0   ebx: f7ff86a0   ecx: 00000000   edx: 00000550
Feb 19 02:52:58 gateway kernel: esi: f7fff2c0   edi: 00000015   ebp: 00000286   esp: eca57d98
Feb 19 02:52:58 gateway kernel: ds: 0018   es: 0018   ss: 0018
Feb 19 02:52:58 gateway pptpd[1596]: MGR: Reaped child 1740
Feb 19 02:52:58 gateway pppd[1741]: Modem hangup
Feb 19 02:52:58 gateway kernel: Process smbd (pid: 1771, process nr: 82, stackpage=eca57000)
Feb 19 02:52:58 gateway kernel: Stack: 00000015 eca57e34 c014f549 00000604 00000015 e9ffeb80 eca57e30 e9ffeb80
Feb 19 02:52:58 gateway kernel:        c014ed4c 00000600 00000015 0000ff00 00000550 c01692c5 e9ffeb80 00000600
Feb 19 02:52:58 gateway kernel:        00000000 00000015 eca57e30 eca57ed4 e9ffeb80 c01783ec 00000001 00000600
Feb 19 02:52:58 gateway kernel: Call Trace: [alloc_skb+113/220] [sock_wmalloc_err+52/104] [tcp_do_sendmsg+965/2168] [inet_sendmsg+0/144] [tcp_v4_sendmsg+92/104] [inet_sendmsg+131/144] [sock_sendmsg+136/172]
Feb 19 02:52:58 gateway kernel: Call Trace: [] [] [] [] [] [] []
Feb 19 02:52:58 gateway kernel:        [inet_sendmsg+0/144] [sys_sendto+199/236] [update_atime+94/100] [do_generic_file_read+1492/1504] [generic_file_read+99/124] [sys_send+30/36] [sys_socketcall+269/480] [system_call+52/56]
Feb 19 02:52:58 gateway kernel:        [] [] [] [] [] [] [] []
Feb 19 02:52:58 gateway kernel: Code: 8b 01 89 03 85 c0 74 2b 8b 7b 04 85 ff 75 10 89 19 89 c8 2b
Feb 19 02:52:58 gateway kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Feb 19 02:52:58 gateway kernel: current->tss.cr3 = 2c804000, %%cr3 = 2c804000
Feb 19 02:52:58 gateway kernel: *pde = 00000000
Feb 19 02:52:58 gateway kernel: Oops: 0000
Feb 19 02:52:58 gateway kernel: CPU:    0
Feb 19 02:52:58 gateway kernel: EIP:    0010:[kmalloc+81/348]
Feb 19 02:52:58 gateway kernel: EIP:    0010:[]
Feb 19 02:52:58 gateway kernel: EFLAGS: 00010006
Feb 19 02:52:58 gateway kernel: eax: f7ff86a0   ebx: f7ff86a0   ecx: 00000000   edx: ffffffe0
Feb 19 02:52:58 gateway kernel: esi: f7fff2c0   edi: 00000015   ebp: 00000286   esp: ec819e18
Feb 19 02:52:58 gateway kernel: ds: 0018   es: 0018   ss: 0018
Feb 19 02:52:58 gateway kernel: Process pptpctrl (pid: 1740, process nr: 81, stackpage=ec819000)
Feb 19 02:52:58 gateway kernel: Stack: 00000015 00000040 c014f549 000005c4 00000015 e9ffe340 00000000 ec818000
Feb 19 02:52:58 gateway kernel:        c014eceb 000005bc 00000015 e9ffe340 c014ef5f e9ffe340 000005bc 00000000
Feb 19 02:52:58 gateway kernel:        00000015 00000010 00000040 0000059d e5781a20 ec818000 c0167144 e9ffe340
Feb 19 02:52:58 gateway kernel: Call Trace: [alloc_skb+113/220] [sock_wmalloc+35/80] [sock_alloc_send_skb+99/168] [ip_build_xmit+228/780] [raw_sendmsg+556/612] [raw_getfrag+0/36] [inet_sendmsg+0/144]
Feb 19 02:52:58 gateway kernel: Call Trace: [] [] [] [] [] [] []
Feb 19 02:52:58 gateway kernel:        [inet_sendmsg+131/144] [sock_sendmsg+136/172] [inet_sendmsg+0/144] [sock_write+146/156] [sys_write+229/280] [sock_write+0/156] [system_call+52/56]
Feb 19 02:52:58 gateway kernel:        [] [] [] [] [] [] []
Feb 19 02:52:58 gateway kernel: Code: 8b 01 89 03 85 c0 74 2b 8b 7b 04 85 ff 75 10 89 19 89 c8 2b
Feb 19 02:52:58 gateway pppd[1741]: Connection terminated.
Feb 19 02:52:58 gateway pppd[1741]: Connect time 151.4 minutes.
Feb 19 02:52:58 gateway pppd[1741]: Sent 830358081 bytes, received 22174413 bytes.
Feb 19 08:39:32 gateway syslogd 1.4.1: restart.
Feb 19 08:39:32 gateway syslog: syslogd startup succeeded
-------------------------------------------------
MESSAGE LOG EXTRACT ENDS

[Joost De Raeymaeker]

After running an outgoing PPTP session for a day from behind a 5.6 sme with the latest modules from Charly Brady, I still have problems, but less than before.

- If the link is up very long without traffic, it just stays up, but no traffic can flow accross it.
- If I ping something on the other side from my windows box: (ping xx.xx.xx.xx -t -l 1 it also stays up.

I suspect it might be iptables forgetting about gre and closing the hole, or am I completely missing the point here?

Joost

[Charlie Brady]

Joost De Raeymaeker wrote:

> I suspect it might be iptables forgetting about gre and
> closing the hole, or am I completely missing the point here?

No, you are likely to be correct in your diagnosis. Do you have firewall (masq) logging enabled? You might be able to confirm your diagnosis if it is, by seeing blocked packets being logged.

Try adding:

lcp-echo-interval 30
lcp-echo-failure 4

to /etc/ppp/options.pptpd

Thanks for your testing and clear result reporting, BTW.

Charlie

[Charlie Brady]

Charlie Brady wrote:
 
> Try adding:
>
> lcp-echo-interval 30
> lcp-echo-failure 4
>
> to /etc/ppp/options.pptpd

Don't bother. That will enable lcp-echo/keepalive packets for inbound PPTP connections, but won't do anything for masqueraded connections.

See if you can find any configuration options for the VPN client. Or enable lcp-echo on the remote server you are connecting too.  The packets every thirty seconds should keep the firewall pinhole open for you.

Let me know how you get on.

Charlie

[sidney]

I realy need some help getting my vpn to work.
I have tried Mark Otoupal post but with out any luck.

would some mind helping me. I realy need to get my vpn to work.


Thanks...

[Joost De Raeymaeker]

Update:

I went into Charlie's contrib directory and downloaded and installed pptp-conntrack-nat-1.0.1-2es, apart from the other updates that are also in there. This doesn't seem to have debugging enabled

The problems remain:
-If I run a PPTP session from behind an SME server it fails pretty fast (usually only a couple of minutes, unless you ping a host on the other side ping host -t -l 1 (from a windows machine)
If I comment the following two lines in /etc/rc.d/init.d
# /sbin/modprobe ip_nat_pptp
# /sbin/modprobe ip_conntrack_pptp
and reboot the server, the connection seems to be more stable, although I must confess I never really tried to shut down the ping for too long.
-Off course, if you do that, only 1 machine from behind the sme server can connect via pptp to the outside world, so now I'm back to loading these modules and pinging from both machines.

Any other news on this?
Joost