http://www.ciscozine.com/2011/04/30/speed-up-your-reload/

Upgrades were completed this weekend. Site is fully functional again.

We are currently in the process of updating and consolidating some servers. We will update you shortly when the upgrades have been completed.

Testing Twitter UPdate function again.

If you see this on twitter then the wordpress twitter plugin is updating correctly.

We are now accepting Donation Payments through PayPal! Please feel free to donate to help keep Etherninja.org and our infrastructure up and running.

Please enjoy we are back up after the upgrades.

Sincerely,

St0rmShadow

We are currently upgrading irc.etherninja.org. All admins who connect to playground are still up and good to go. We will update you as soon as the upgrade is complete.

St0rmShadow

EtherNinja Would Like to welcome trem0r to our author/contributor. He has already written up a great article about getting Microsoft Clients to connect to a linux vpn. Please check it out at EtherNinja
Thanks again Trem0r! and Welcome to the Team!

Peace!

St0rmShadow

*Note:  This configuration is based on a Redhat/Fedora installation, but should work the same with other linux distributions.  Some commands may differ.

Recently, our organization has had difficulty with a few of the Microsoft clients who were connecting to our network from home and abroad.  Some of them, even though settings were correct, just could not establish a secure tunnel with us.  I won’t go into the details concerning reasons, suffice to say that MS is not always completely reliable.  And yes L2TP is more secure (I know, I know)  but for our application, PPTP is acceptable.

I had my eye on setting up a secondary server which would be running linux and serving as backup pptp server.  We just so happened to have an existing storage server that was pretty bored in life, so I thought I would task it to do something a little more important.  Before I get into the configuration, let me explain a couple of things.  Pre-2.6 kernel’s needed 4 packages to pull this off: PPP, DKMS, MPPE kernel patch, PPTPD.  The configuration involved patching the kernel to allow support for the 128-bit MPPE (Microsoft Point to Point Encryption) that is used in conjunction with the Point-to-Point link.  This required the DKMS package and the MPPE kernel patch.  Fortunately, this is not required as long as your kernel is 2.6 or later.  Also, the PPP (point-to-pint protocol) package is necessary to set up the connection and pass the data to the PPTPD (point to point tunnelling protocol daemon).  However, the PPP package ships standard with most modern distributions and is not required to install.  If you are unsure of whether or not you have ppp installed, simply run this command: “rpm -qa | grep ppp” and you should see that it is installed.  If it isn’t, a simple “yum install ppp” should suffice, or you can find plenty of RPMs available on the net.  Of course, you can always compile this package from source if you’d like.

On to the fun stuff..

Packages Required for PPTP VPN:
Kernel that supports MPPE 128-bit encryption
PPP
PPTPD

Fedora ships out of the box with MPPE and PPP ready to rock.  The only thing I really need to do is add the PPTPD package.

Step 1: Install PPTPD

yum install pptpd

Once yum has installed this package successfully, you will notice that it has created a pptpd.conf file in your /etc directory.  Go ahead and check for it:

[user@hostname ~]# ls /etc | grep pptp
pptpd.conf

At this point, you should have a working pptp daemon.  This is a matter of personal preference, but I like to go ahead and start pptpd just to make sure that the service is functioning and that it opens up the PPTP port (1723) on the machine:

[user@hostname ~]# /etc/init.d/pptpd start
Starting pptpd:                                            [  OK  ]
[user@hostname ~]# telnet localhost 1723
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.

If you get this far and the service starts and you get the message “Connected to localhost.” when you telnet to port 1723, you should be right as rain.

Step 2: Configuration Files:

There are three configuration files we need to worrry about.  They are /etc/pptpd.conf, /etc/ppp/options.pptpd, and /etc/sysctl.conf.

Let’s start with /etc/pptpd.conf.  There are three main criteria that we need to worry about, so you will need to edit this file and make sure these entries are in it. Bear in mind that a “#” symbol in front of the lines means that the line in front of the # is disabled.  You do not want this for the following three lines.  Also, the localip and remoteip fields will need to be changed according to your ip addressing scheme. :

option /etc/ppp/options.pptpd

ppp /usr/sbin/pppd

localip 192.168.1.xxx
remoteip 192.168.1.10-20

In the example above, the first line, “option /etc/ppp/options.pptpd” tells the pptp daemon where to locate the options.pptpd file which contains various options on how to set up the pptp tunnel (encryption type, authentication type, and so on).  the second line, “ppp/usr/sbin/pppd” tells the pptp daemon where to find the ppp  daemon.  This is necessary because the pptp daemon will need to initialize the ppp daemon in order for this all to work. Both daemons work together to create our tunnel.  The final two lines with “localip” and “remoteip” are also quite important.  In your case, localip should be the ip address of your particular linux machine.  The remote ip will be the ip address, or addresses that you will hand out to your mobile VPN clients – similar to a very simple DHCP scope.  For example, the above entry allows for 10 simultaneous connections of which 192.168.10 will be the first address given to the remote user.  Just make sure that these addresses are actually available on yo network and not in any other DHCP scope.  *Note: You may use CIDR if you have a particular subnet that you want to hand remote users, just make sure that your routing can handle it.

Now, on to /etc/ppp/options.pptpd

As stated previously, options.pptpd is concered with how the VPN will authenticate and encrypt.  Below are the options that you actually care about:

name pptpd
require-mschap-v2
require-mppe-128
ms-dns 192.168.1.73
lock
nobsdcomp
auth
require-mppe

I will go through these briefly.  The first line indicates the name of the daemon.  The 2nd and 3rd lines indicate what type of authentication and what kind of encryption is required.  MSCHAP-v2 is preferred for Microsoft clients.  Mppe-128 bit encryption is also preferred.  The fourth line is optional as you can choose whether or not to give your mobile clients a DNS entry so that they access resources by name.  The fith line indicates that each individual session is locked and only accessible by the initial connected party.  This is quite important and should ALWAYS be present.  Sixth line, nobsdcomp, disables BSD type compression, which MS clients tend to have problems with. The last two lines auth and require-mpp just tell the daemon to authenticate the client and require MPPE.

Lastly, /etc/sysctl.conf:

Edit this file and make sure the net.ipv4.ip_forward is set to 1.  This enables ip packet forwarding on the LAN which is required if you expect your VPN users to be able to access any other resources on the network besides the VPN server itself.

net.ipv4.ip_forward = 1

Step 3: Setting up Users:

The users can be set up one of several ways, either through LDAP, MS Active Directory, or /etc/passwd authentication – however, that is outside the realm of this tutorial.  If you did want to do it that way, you would need to modify the above options.pppd file.  The auth in the options.pppd file defaults to the chap-secrets file which we will now modify. The chap-secrets file in the /etc/ppp/ directory.

# Secrets for authentication using CHAP
# client    server    secret            IP addresses
testuser         pptpd       testpass            “*”

The above is pretty self explanatory.  Each line will represent one user.  The “*” specifies that any of the allotted ip addresses will be assigned to that particular user.  You could enter in a specific IP address that you would like each particular user to receive upon connection, if necessary.

Step 4: Test and Troubleshoot:

At this point you will want to restart your pptpd service so that it can read your newly edited config files.

/etc/init.d/pptpd stop
/etc/init.d/pptpd start

You will want to set up a vpn connection on either a windows or linux machine just as you would normally do, and try to connect.  The main output of the attempted connection will be located in /var/log/messages.  More detailed logging can be found in the pptp logs.  My first connection attempt completely failed and here is the output of /var/log/messages:

Apr  2 16:25:56 hostname pppd[4457]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so is for pppd version 2.4.3, this is 2.4.4
Apr  2 16:25:56 hostname pptpd[4456]: GRE: read(fd=6,buffer=804e560,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Apr  2 16:25:56 hostname pptpd[4456]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)

In this case, the first line is the important one.  Re-edit your /etc/pptpd.conf file and comment out (put a # symbol in front of) the line which reads:

# TAG: logwtmp
#    Use wtmp(5) to record client connections and disconnections.
#
#logwtmp

Restart your pptpd service and try the connection again.  If all goes well, this is what you will be staring at:

Apr  2 16:31:59 hostname pptpd[4682]: MGR: Manager process started
Apr  2 16:31:59 hostname pptpd[4682]: MGR: Maximum of 9 connections available
Apr  2 16:33:05 hostname pptpd[4713]: CTRL: Client 192.168.1.120 control connection started
Apr  2 16:33:06 hostname pptpd[4713]: CTRL: Starting call (launching pppd, opening GRE)
Apr  2 16:33:07 hostname kernel: PPP generic driver version 2.4.2
Apr  2 16:33:07 hostname pppd[4714]: pppd 2.4.4 started by root, uid 0
Apr  2 16:33:07 hostname pppd[4714]: Using interface ppp0
Apr  2 16:33:07 hostname pppd[4714]: Connect: ppp0 <–> /dev/pts/1
Apr  2 16:33:07 hostname kernel: PPP MPPE Compression module registered
Apr  2 16:33:07 hostname pppd[4714]: MPPE 128-bit stateless compression enabled
Apr  2 16:33:07 hostname pppd[4714]: found interface eth0 for proxy arp
Apr  2 16:33:07 hostname pppd[4714]: local  IP address 192.168.1.43
Apr  2 16:33:07 hostname pppd[4714]: remote IP address 192.168.1.51

Hooray!!  You’ve done it.  Now you have a shiny new VPN server for your clients to connect to.  Now, one thing to note is that there are some sophisticated loggin options with logwtmp. Unfortunately for this tutorial, it is unnecessary.  There are really only 4 key files that you will need to modify, and once you have done this type of setup once, you will be a pro.  Good luck.