https://wiki.archlinux.org/api.php?action=feedcontributions&user=Lir&feedformat=atomArchWiki - User contributions [en]2024-03-19T06:26:17ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=QEMU&diff=192776QEMU2012-04-04T05:31:46Z<p>Lir: /* Mounting qcow2 image */ prettied the link</p>
<hr />
<div>[[Category:Emulators (English)]]<br />
[[Category:Virtualization]]<br />
[[de:Qemu]]<br />
[[fr:Qemu]]<br />
{{i18n|QEMU}}<br />
<br />
From the [http://wiki.qemu.org/Main_Page QEMU about page],<br />
<blockquote><br />
<p>QEMU is a generic and open source machine emulator and virtualizer.</p><br />
<br />
<p>When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.</p><br />
<br />
<p>When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests.</p><br />
</blockquote><br />
<br />
== Difference between qemu and qemu-kvm ==<br />
Depending on your needs, you can choose either to install upstream {{Pkg|qemu}} or {{Pkg|qemu-kvm}} from the [[Official Repositories|official repositories]].<br />
<br />
KVM (Kernel Virtual Machine) is a Linux kernel module that allows a user space program to utilize the hardware virtualization features of various processors. Today, it supports recent Intel and AMD processors (x86 and x86_64), PPC 440, PPC 970, and S/390 processors.<br />
<br />
QEMU can make use of KVM when running a target architecture that is the same as the host architecture. For instance, when running qemu-system-x86 on an x86 compatible processor, you can take advantage of the KVM acceleration - giving you benefit for your host and your guest system. <br />
<br />
Not all processors support KVM. You will need an x86-based machine running a recent ( >= 2.6.22 ) Linux kernel on an Intel processor with VT-x (virtualization technology) extensions or an AMD processor with SVM (Secure Virtual Machine) extensions (also called AMD-V). Xen has an [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors (outdated) list] of compatible processors. For Intel processors, see also the [http://ark.intel.com/VTList.aspx Intel® Virtualization Technology List].<br />
<br />
== Installing QEMU ==<br />
To install the machine emulator version (normal QEMU), [[pacman|install]] the {{Pkg|qemu}} package.<br />
<br />
To install the KVM version (please see the [[KVM]] article for more details), [[pacman|install]] the {{Pkg|qemu-kvm}} package.<br />
<br />
== Choosing Windows version==<br />
QEMU can run any version of Windows. However, 98, Me and XP will run at quite a low speed. You should choose either Windows 95 or Windows 2000. Surprisingly, 2000 seems to run faster than 98. The fastest one is 95, which can from time to time make you forget that you are running an emulator :)<br />
<br />
If you own both Win95 and Win98/WinME, then 98lite (from http://www.litepc.com) might be worth trying. It decouples Internet Explorer from operating system and replaces it with original Windows 95 Explorer. It also enables you to do a minimal Windows installation, without all the bloat you normally cannot disable. This might be the best option, because you get the smallest, fastest and most stable Windows this way.<br />
<br />
== Creating the hard disk image==<br />
To run QEMU you will probably need a hard disk image. This is a file which stores the contents of the emulated hard disk.<br />
<br />
Use the command:<br />
qemu-img create -f qcow2 win.qcow 4G<br />
to create the image file named "win.qcow". The "4G" parameter specifies the size of the disk - in this case 4 GB. You can use suffix M for megabytes (for example "256M"). You should not worry too much about the size of the disk - the qcow2 format compresses the image so that the empty space does not add up to the size of the file.<br />
<br />
== Preparing the installation media==<br />
The installation CD-ROM/floppy should not be mounted, because QEMU accesses the media directly. It is a good idea to dump CD-ROM and/or floppy to a file, because it both improves performance and does not require you to have direct access to the devices (that is, you can run QEMU as a regular user). For example, if the CD-ROM device node is named {{ic|/dev/cdrom}}, you can dump it to a file with the command:<br />
dd if=/dev/cdrom of=win98icd.iso<br />
<br />
Do the same for floppies:<br />
dd if=/dev/fd of=win95d1.img<br />
<br />
When you need to replace floppies within QEMU, just copy the contents of one floppy over another. For this reason, it is useful to create a special file that will hold the current floppy:<br />
touch floppy.img<br />
<br />
== Installing the operating system==<br />
This is the first time you will need to start the emulator.<br />
One thing to keep in mind: when you click inside the QEMU window, the mouse pointer is grabbed. To release it press {{Keypress|Ctrl+Alt}}.<br />
<br />
If you need to use a bootable floppy, run QEMU with:<br />
qemu -cdrom <nowiki>[[cdrom''image]]</nowiki> -fda <nowiki>[[floppy''image]]</nowiki> -boot a <nowiki>[[hd_image]]</nowiki><br />
<br />
or if you are on a x86_64 system (will avoid many problems afterwards):<br />
qemu-system-x86_64 -cdrom <nowiki>[[cdrom''image]]</nowiki> -fda <nowiki>[[floppy''image]]</nowiki> -boot a <nowiki>[[hd_image]]</nowiki><br />
<br />
If your CD-ROM is bootable or you are using ISO files, run QEMU with:<br />
qemu -cdrom <nowiki>[[cdrom''image]]</nowiki> -boot d <nowiki>[[hd''image]]</nowiki><br />
<br />
or if you are on a x86_64 system (will avoid many problems afterwards):<br />
qemu-system-x86_64 -cdrom <nowiki>[[cdrom''image]]</nowiki> -boot d <nowiki>[[hd''image]]</nowiki><br />
<br />
Now partition the virtual hard disk, format the partitions and install the OS.<br />
<br />
A few hints:<br />
# If you are using Windows 95 boot floppy, then choosing SAMSUNG as the type of CD-ROM seems to work<br />
# There are problems when installing Windows 2000. Windows setup will generate a lot of edb*.log files, one after the other containing nothing but blank spaces in {{ic|C:\WINNT\SECURITY}} which quickly fill the virtual hard disk. A workaround is to open a Windows command prompt as early as possible during setup (by pressing {{Keypress|Shift+F10}}) which will allow you to remove these log files as they appear by typing:<br />
del %windir%\security\*.log<br />
<br />
{{Note|According to the official QEMU website, "Windows 2000 has a bug which gives a disk full problem during its installation. When installing it, use the {{ic|-win2k-hack}} QEMU option to enable a specific workaround. After Windows 2000 is installed, you no longer need this option (this option slows down the IDE transfers)."}}<br />
<br />
== Running the system==<br />
To run the system simply type:<br />
qemu [hd_image]<br />
<br />
A good idea is to use overlay images. This way you can create hard disk image once and tell QEMU to store changes in external file.<br />
You get rid of all the instability, because it is so easy to revert to previous system state :)<br />
<br />
To create an overlay image, type:<br />
<nowiki>qemu-img create -b [[base''image]] -f qcow2 [[overlay''image]]</nowiki><br />
<br />
Substitute the hard disk image for base_image (in our case win.qcow). After that you can run qemu with:<br />
qemu [overlay_image]<br />
<br />
or if you are on a x86_64 system:<br />
qemu-system-x86_64 [overlay_image]<br />
<br />
and the original image will be left untouched. One hitch, the base image cannot be renamed or moved, the overlay remembers the base's full path.<br />
<br />
== Moving data between host and guest OS ==<br />
If you have servers on your host OS, they will be accessible with the IP address 10.0.2.2 without any further configuration. So you could just FTP, SSH, etc. to 10.0.2.2 from Windows to share data, or if you would like, you can use [[Samba]].<br />
<br />
=== Samba ===<br />
QEMU supports [[Samba]] which allows you to mount host directories during the emulation. It seems that there is an incompatibility with Samba 3.x. and some versions of QEMU. But at least with a current snapshot of QEMU it should be working.<br />
<br />
First, you need to have a working Samba installation. Then add the following section to your {{ic|smb.conf}}:<br />
{{bc|<nowiki><br />
[qemu]<br />
comment = Temporary file space<br />
path = /tmp<br />
read only = no<br />
public = yes<br />
</nowiki>}}<br />
<br />
Now start QEMU with:<br />
qemu [hd_image] -smb qemu<br />
<br />
Then you should be able to access your host's Samba server with the IP address 10.0.2.2. If you are running Win9x as a guest OS, you may need to add<br />
10.0.2.2 smbserver<br />
to {{ic|C:\Windows\lmhosts}} (Win9x has Lmhosts.sam as a SAMple, rename it!).<br />
<br />
=== Mounting the hard disk image - raw image===<br />
Fortunately there is a way to mount the hard disk image with a loopback device. Login as root, make a temporary directory and mount the image with the command:<br />
mount -o loop,offset=32256 [hd_image] [tmp_dir]<br />
<br />
Now you can copy data in both directions. When you are done, umount with:<br />
umount [hd_image]<br />
<br />
The drawback of this solution is that you cannot use it with qcow images (including overlay images). So you need to create you images without \"-f qcow\" option.<br />
{{Tip|Create a second, raw hard drive image. This way you will be able to transfer data easily and use qcow overlay images for the primary drive.}}<br />
<br />
{{Warning|Never run QEMU while the image is mounted!}}<br />
<br />
=== Mounting qcow2 image ===<br />
You may mount a qcow2 image using {{ic|qemu-nbd}}. See [[http://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host Wikibooks]].<br />
<br />
=== Using any real partition as the single primary partition of a hard disk image ===<br />
Sometimes, you may wish to use one of your system partition from within QEMU (for instance, if you wish booting both your real machine or QEMU using a given partition as root). You can do this using software RAID in linear mode (you need the linear.ko kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.<br />
<br />
Suppose you have a plain, unmounted {{ic|/dev/hdaN}} partition with some filesystem on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:<br />
dd if=/dev/zero of=/path/to/mbr count=32<br />
<br />
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:<br />
losetup -f /path/to/mbr<br />
<br />
Let's assume the resulting device is {{ic|/dev/loop0}}, because we would not already have been using other loopbacks. Next step is to create the "merged" MBR + {{ic|/dev/hdaN}} disk image using software RAID:<br />
modprobe linear<br />
mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hdaN<br />
<br />
The resulting {{ic|/dev/md0}} is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of {{ic|/dev/hdaN}} inside {{ic|/dev/md0}} (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using {{ic|fdisk}} on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:<br />
fdisk /dev/md0<br />
<br />
Press {{Keypress|X}} to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your MBR file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.<br />
<br />
Now, press {{Keypress|R}} to return to the main menu. <br />
<br />
Press {{Keypress|P}} and check that the cylinder size is now 16k.<br />
<br />
Now, create a single primary partition corresponding to {{ic|/dev/hdaN}}. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.<br />
<br />
Finally, 'w'rite the result to the file: you are done. You know have a partition you can mount directly from your host, as well as part of a QEMU disk image: <br />
<br />
qemu -hdc /dev/md0 [...]<br />
<br />
You can of course safely set any bootloader on this disk image using QEMU, provided the original {{ic|/dev/hdaN}} partition contains the necessary tools.<br />
<br />
==Optimizing Windows 9X CPU usage==<br />
Windows 9X uses an idle loop instead of the HLT (halt) instruction. Consequently, the emulator will consume all CPU resources when running Windows 9X guests -- even if no work is being done. This only applies to DOS and DOS-based Windows versions (3.X, 95/98/ME) -- NT-based and later Windows versions are not affected.<br />
<br />
To resolve this issue, install [http://www.benchtest.com/rain.html Rain], [http://www.benchtest.com/wfp.html Waterfall] or [http://www.benchtest.com/cpuidle.html CpuIdle] in the Windows 9X guest. (Rain might be preferred because it does only what is needed -- replacing the idle loop with the HLT instruction -- and nothing more.)<br />
<br />
See [https://forums.virtualbox.org/viewtopic.php?f=28&t=9918 Tutorial: Windows 95/98 guest OSes] for more information.<br />
<br />
== Using the Kernel-based Virtual Machine ==<br />
<br />
[[KVM]] is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc.<br />
<br />
This technology requires an x86 machine running a recent ( >= 2.6.22) Linux kernel on an Intel processor with VT-x (virtualization technology) extensions, or an AMD processor with SVM (Secure Virtual Machine) extensions. It is included in the mainline Linux kernel since 2.6.20 and is enabled by default in the Arch Linux kernel.<br />
<br />
Even though QEMU in recent versions ( < 0.15.0) does have initial KVM support ({{ic|qemu --enable-kvm}}), it is not recommended to use this, as many KVM-related functions still have not been implemented in upstream QEMU. Instead, you should go for the {{Pkg|qemu-kvm}} package in the [[Official Repositories|official repositories]], which is released by the KVM development team and contains all of the latest features (and bugfixes) of KVM userspace. Please refer to the [[KVM]] page itself, for more information on using QEMU with KVM on Arch Linux.<br />
<br />
{{Note|{{Pkg|qemu}} ><nowiki>=</nowiki> 0.15.0 has full support for KVM, as the qemu-kvm tree has been completely merged into the upstream qemu tree. There should be no difference between {{ic|qemu -enable-kvm}} and {{ic|qemu-kvm}} if your version of {{Pkg|qemu}} is ><nowiki>=</nowiki> 0.15.0.}}<br />
<br />
To take advantage of KVM, you simply need a compatible processor (the following command must return something on the screen):<br />
grep -E "(vmx|svm)" --color=always /proc/cpuinfo<br />
<br />
And load the appropriate module from your {{ic|/etc/[[rc.conf]]}}.<br />
<br />
* For Intel® processors add {{ic|kvm-intel}} to your {{ic|MODULES}} array in {{ic|/etc/rc.conf}}<br />
* for AMD® processors add {{ic|kvm-amd}} to your {{ic|MODULES}} array in {{ic|/etc/rc.conf}}<br />
<br />
Also, you will need to add yourself to the group {{ic|kvm}}.<br />
gpasswd -a <Your_User_Account> kvm<br />
<br />
==Networking==<br />
===Basic Networking===<br />
To add basic networking to your virtual machine, you may have to simply load QEMU with these options: {{ic|<nowiki>-net nic,vlan=1 -net user,vlan=1</nowiki>}}. For example, to load a CD-ROM, you could use:<br />
qemu -kernel-kqemu -no-acpi -net nic,vlan=1 -net user,vlan=1 -cdrom dsl-4.3rc1.iso<br />
Note that this only supports the TCP and UDP protocols. In particular ICMP and thus ping will not work.<br />
<br />
=== Tap Networking with QEMU ===<br />
==== Basic Idea ====<br />
Tap networking in QEMU lets virtual machines register themselves as though with separate Ethernet adapters and have their traffic bridged directly onto your local area network. This is sometimes very desirable, if you want your virtual machines to be able to talk to each other, or for other machines on your LAN to talk to virtual machines.<br />
<br />
==== Security Warning ====<br />
You probably '''should not''' use this networking method if your host Arch machine is directly on the Internet. It can expose your virtual machines directly to attack!<br />
<br />
In general, Arch Linux disclaims any responsibility for security implications (or implications of any kind, really) from following these instructions.<br />
<br />
==== Nitty Gritty ====<br />
To set all of this up, you will need to install the following packages:<br />
*{{Pkg|bridge-utils}} (provides {{ic|brctl}}, to manipulate bridges)<br />
*{{Pkg|uml_utilities}} (for tunctl, to manipulate taps)<br />
<br />
We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it. See http://en.gentoo-wiki.com/wiki/KVM#Networking_2 .<br />
<br />
Make sure IPv4 forwarding is set. You should have the line {{ic|<nowiki>net.ipv4.ip_forward=1</nowiki>}} in your {{ic|/etc/sysctl.conf}}.<br />
<br />
Take the following steps:<br />
<br />
1. Add {{ic|bridge}} and {{ic|tun}} to your {{ic|MODULES}} array in {{ic|/etc/rc.conf}}:<br />
<br />
MODULES=( ... bridge tun)<br />
<br />
2. Configure your bridge {{ic|br0}} to have your real Ethernet adapter (assuming {{ic|eth0}} for the rest of this guide) in it, in {{ic|/etc/conf.d/bridges}}:<br />
bridge_br0="eth0"<br />
control_br0="setfd br0 0"<br />
BRIDGE_INTERFACES=(br0)<br />
<br />
{{Note|This is not described anywhere, but adding the {{ic|control_br0}} line is vital for the bridge to work! For more details look here: {{bug|16625}}}}<br />
<br />
3. Change your networking configuration so that you just bring up your real Ethernet adapter without configuring it, allowing real configuration to happen on the bridge interface. In {{ic|/etc/rc.conf}}:<br />
eth0="eth0 up"<br />
br0="dhcp"<br />
INTERFACES=(eth0 br0)<br />
<br />
Remember, especially if you are doing DHCP, it is essential that the bridge comes up AFTER the real adapter, otherwise the bridge will not be able to talk to anything to get a DHCP address!<br />
<br />
If DHCP does not work, try with a static IP address in {{ic|/etc/rc.conf}}:<br />
eth0="eth0 0.0.0.0"<br />
br0="br0 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255"<br />
INTERFACES=(eth0 br0)<br />
gateway="default gw 192.168.0.1"<br />
ROUTES=(gateway)<br />
<br />
and then in {{ic|/etc/resolv.conf}}:<br />
domain lan<br />
nameserver 192.168.0.1<br />
<br />
4. Install the script that QEMU uses to bring up the tap adapter in {{ic|/etc/qemu-ifup}} with root:kvm 750 permissions:<br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifup"<br />
echo "Bringing up $1 for bridged mode..."<br />
sudo /sbin/ifconfig $1 0.0.0.0 promisc up<br />
echo "Adding $1 to br0..."<br />
sudo /usr/sbin/brctl addif br0 $1<br />
sleep 2<br />
<br />
5. Use {{ic|visudo}} to add the following to your {{ic|sudoers}} file:<br />
Cmnd_Alias QEMU=/sbin/ifconfig,/sbin/modprobe,/usr/sbin/brctl,/usr/bin/tunctl<br />
%kvm ALL=NOPASSWD: QEMU<br />
<br />
6. Make sure the user(s) wishing to use this new functionality are in the {{ic|kvm}} group. Exit and log in again if necessary.<br />
<br />
7. You launch QEMU using the following {{ic|run-qemu}} script:<br />
#!/bin/bash<br />
USERID=`whoami`<br />
IFACE=$(sudo tunctl -b -u $USERID)<br />
<br />
qemu-kvm -net nic -net tap,ifname="$IFACE" $*<br />
<br />
sudo tunctl -d $IFACE &> /dev/null<br />
<br />
Then to launch a VM, do something like this<br />
$ run-qemu -hda myvm.img -m 512 -vga std<br />
<br />
8. If you cannot get a DHCP address in the host, it might be because iptables are up by default in the bridge. In that case (from http://www.linux-kvm.org/page/Networking ):<br />
# cd /proc/sys/net/bridge<br />
# ls<br />
bridge-nf-call-arptables bridge-nf-call-iptables<br />
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged<br />
# for f in bridge-nf-*; do echo 0 > $f; done<br />
<br />
And if you still cannot get networking to work, see: [[Linux_Containers#Bridge_device_setup]]<br />
<br />
=== Networking with [[VDE2]] ===<br />
==== What is VDE? ====<br />
VDE stands for Virtual Distributed Ethernet. It started as an enhancement of [[User-mode Linux|uml]]_switch. It is a toolbox to manage virtual networks.<br />
<br />
The idea is to create virtual switches, which are basically sockets, and to "plug" both physical and virtual machines in them. The configuration I show here is quite simple; However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. Your are invited to read [http://wiki.virtualsquare.org/wiki/index.php/Main_Page the documentation of the project].<br />
<br />
The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.<br />
<br />
==== Basics ====<br />
VDE is in the [[Official Repositories|official repositories]], so...<br />
<br />
# pacman -S vde2<br />
<br />
In my config, I use tun/tap to create a virtual interface on my host. Load the {{ic|tun}} module (or add it to your {{ic|MODULES}} array in {{ic|[[rc.conf]]}}):<br />
<br />
# modprobe tun<br />
<br />
Now create the virtual switch:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group kvm<br />
<br />
This line creates the switch, creates tap0, "plugs" it, and allows the users of the group {{ic|kvm}} to use it.<br />
<br />
The interface is plugged in but not configured yet. Just do it:<br />
<br />
# ifconfig tap0 192.168.100.254 netmask 255.255.255.0<br />
<br />
That is all! Now, you just have to run KVM with these {{ic|-net}} options as a normal user:<br />
<br />
$ qemu-kvm -net nic -net vde -hda ...<br />
<br />
Configure your guest as you would do in a physical network. I gave them static addresses and let them access the WAN using IP forwarding and masquerading on my host:<br />
<br />
# echo "1" > /proc/sys/net/ipv4/ip_forward<br />
# iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE<br />
<br />
==== Putting it together ====<br />
I added this init script to run all this at start-up:<br />
<br />
#!/bin/bash <br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
case "$1" in<br />
start)<br />
stat_busy "Starting VDE Switch"<br />
vde_switch -tap tap0 -daemon -mod 660 -pidfile $PIDFILE -group kvm<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
echo "1" > /proc/sys/net/ipv4/ip_forward && \<br />
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE && \<br />
ifconfig tap0 192.168.100.254 netmask 255.255.255.0 && \<br />
stat_done || stat_fail<br />
fi<br />
;;<br />
stop)<br />
stat_busy "Stopping VDE Switch"<br />
# err.. well, i should remove the switch here...<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
sleep 1<br />
# Aem.. As long as stop) is not implemented, this just fails<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}" <br />
esac<br />
exit 0<br />
<br />
Well, I know it is dirty and could be more configurable. Feel free to improve it. VDE has an rc script too, but I had to make one anyway for the IP forwarding stuff.<br />
<br />
====Alternative method====<br />
If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq and iptables you can do the following for the same result.<br />
<br />
vde_switch -daemon -mod 660 -group kvm<br />
<br />
slirpvde --dhcp --daemon<br />
<br />
Then to start the vm with a connection to the network of the host:<br />
<br />
kvm -net nic,macaddr=52:54:00:00:EE:03 -net vde whatever.qcow<br />
<br />
== Graphics ==<br />
QEMU can use the following different graphic outputs: std, cirrus, vmware, qxl, xenfs and vnc.<br />
With the {{ic|vnc}} option you can run your guest standalone and connect to it via VNC. Other options are using {{ic|std}}, {{ic|vmware}}, {{ic|cirrus}}:<br />
<br />
===std===<br />
With {{ic|-vga std}} you can get a resolution of up to 2560 x 1600 pixels.<br />
<br />
===vmware===<br />
Although it is a bit buggy, it performs better than std and cirrus. On the guest, install the VMware drivers:<br />
pacman -S xf86-video-vmware xf86-input-vmmouse<br />
<br />
===Windows guest===<br />
If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. Use: (if you are using a VLAN or are not in the same network as the guest)<br />
qemu -nographic -net user,hostfwd=tcp::5555-:3389<br />
Then connect with either rdesktop or freerdp to the guest, for example:<br />
xfreerdp -g 2048x1152 localhost:5555 -z -x lan<br />
<br />
== Front-ends for QEMU ==<br />
There are a few GUI Front-ends for QEMU:<br />
* {{Pkg|qemu-launcher}}<br />
* community/qemulator<br />
* {{Pkg|qtemu}}<br />
<br />
==Keyboard seems broken / Arrow keys do not work==<br />
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in {{ic|/usr/share/qemu/keymaps}}.<br />
{{bc|<br />
qemu -k [keymap] [disk_image]<br />
}}<br />
<br />
==Starting QEMU virtual machines on boot==<br />
To run QEMU VMs on boot, you can use following rc-script and config.<br />
<br />
{| border="1"<br />
|+ Config file options<br />
|-<br />
| QEMU_MACHINES || List of VMs to start<br />
|-<br />
| qemu_${vm}_type || QEMU binary to call. If specified, will be prepended with {{ic|/usr/bin/qemu-}} and that binary will be used to start the VM. I.e. you can boot e.g. qemu-system-arm images with qemu_my_arm_vm_type="system-arm". If not specified, {{ic|/usr/bin/qemu}} will be used.<br />
|-<br />
| qemu_${vm} || QEMU command line to start with. Will always be prepended with {{ic|-name ${vm} -pidfile /var/run/qemu/${vm}.pid -daemonize -nographic}}.<br />
|-<br />
| qemu_${vm}_haltcmd || Command to shutdown VM safely. I am using {{ic|-monitor telnet:..}} and power off my VMs via ACPI by sending {{ic|system_powerdown}} to monitor. You can use ssh or some other ways.<br />
|-<br />
| qemu_${vm}_haltcmd_wait || How much time to wait for safe VM shutdown. Default is 30 seconds. rc-script will kill qemu process after this timeout.<br />
|}<br />
<br />
Config file example:<br />
{{hc|/etc/conf.d/qemu.conf|<nowiki><br />
# VMs that should be started on boot<br />
# use the ! prefix to disable starting/stopping a VM<br />
QEMU_MACHINES=(vm1 vm2)<br />
<br />
# NOTE: following options will be prepended to qemu_${vm}<br />
# -name ${vm} -pidfile /var/run/qemu/${vm}.pid -daemonize -nographic<br />
<br />
qemu_vm1_type="system-x86_64"<br />
<br />
qemu_vm1="-enable-kvm -m 512 -hda /dev/mapper/vg0-vm1 -net nic,macaddr=DE:AD:BE:EF:E0:00 \<br />
-net tap,ifname=tap0 -serial telnet:localhost:7000,server,nowait,nodelay \<br />
-monitor telnet:localhost:7100,server,nowait,nodelay -vnc :0"<br />
<br />
qemu_vm1_haltcmd="echo 'system_powerdown' | nc.openbsd localhost 7100" # or netcat/ncat<br />
<br />
# You can use other ways to shutdown your VM correctly<br />
#qemu_vm1_haltcmd="ssh powermanager@vm1 sudo poweroff"<br />
<br />
# By default rc-script will wait 30 seconds before killing VM. Here you can change this timeout.<br />
#qemu_vm1_haltcmd_wait="30"<br />
<br />
qemu_vm2="-enable-kvm -m 512 -hda /srv/kvm/vm2.img -net nic,macaddr=DE:AD:BE:EF:E0:01 \<br />
-net tap,ifname=tap1 -serial telnet:localhost:7001,server,nowait,nodelay \<br />
-monitor telnet:localhost:7101,server,nowait,nodelay -vnc :1"<br />
<br />
qemu_vm2_haltcmd="echo 'system_powerdown' | nc.openbsd localhost 7101"<br />
</nowiki>}}<br />
<br />
rc-script:<br />
{{hc|/etc/rc.d/qemu|<nowiki><br />
#!/bin/bash<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
[ -f /etc/conf.d/qemu.conf ] && source /etc/conf.d/qemu.conf<br />
<br />
PIDDIR=/var/run/qemu<br />
QEMU_DEFAULT_FLAGS='-name ${vm} -pidfile ${PIDDIR}/${vm}.pid -daemonize -nographic'<br />
QEMU_HALTCMD_WAIT=30<br />
<br />
case "$1" in<br />
start)<br />
[ -d "${PIDDIR}" ] || mkdir -p "${PIDDIR}"<br />
for vm in "${QEMU_MACHINES[@]}"; do<br />
if [ "${vm}" = "${vm#!}" ]; then<br />
stat_busy "Starting QEMU VM: ${vm}"<br />
eval vm_cmdline="\$qemu_${vm}"<br />
eval vm_type="\$qemu_${vm}_type"<br />
<br />
if [ -n "${vm_type}" ]; then<br />
vm_cmd="/usr/bin/qemu-${vm_type}"<br />
else<br />
vm_cmd='/usr/bin/qemu'<br />
fi<br />
<br />
eval "qemu_flags=\"${QEMU_DEFAULT_FLAGS}\""<br />
<br />
${vm_cmd} ${qemu_flags} ${vm_cmdline} >/dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
fi<br />
done<br />
add_daemon qemu<br />
;;<br />
<br />
stop)<br />
for vm in "${QEMU_MACHINES[@]}"; do<br />
if [ "${vm}" = "${vm#!}" ]; then<br />
# check pidfile presence and permissions<br />
if [ ! -r "${PIDDIR}/${vm}.pid" ]; then<br />
continue<br />
fi<br />
<br />
stat_busy "Stopping QEMU VM: ${vm}"<br />
<br />
eval vm_haltcmd="\$qemu_${vm}_haltcmd"<br />
eval vm_haltcmd_wait="\$qemu_${vm}_haltcmd_wait"<br />
vm_haltcmd_wait=${vm_haltcmd_wait:-${QEMU_HALTCMD_WAIT}}<br />
vm_pid=$(cat ${PIDDIR}/${vm}.pid)<br />
<br />
# check process existence<br />
if ! kill -0 ${vm_pid} 2>/dev/null; then<br />
stat_done<br />
rm -f "${PIDDIR}/${vm}.pid"<br />
continue<br />
fi<br />
<br />
# Try to shutdown VM safely<br />
_vm_running='yes'<br />
if [ -n "${vm_haltcmd}" ]; then<br />
eval ${vm_haltcmd} >/dev/null<br />
<br />
_w=0<br />
while [ "${_w}" -lt "${vm_haltcmd_wait}" ]; do<br />
sleep 1<br />
if ! kill -0 ${vm_pid} 2>/dev/null; then<br />
# no such process<br />
_vm_running=''<br />
break<br />
fi<br />
_w=$((_w + 1))<br />
done<br />
<br />
else<br />
# No haltcmd - kill VM unsafely<br />
_vm_running='yes'<br />
fi<br />
<br />
if [ -n "${_vm_running}" ]; then<br />
# kill VM unsafely<br />
kill ${vm_pid} 2>/dev/null<br />
sleep 1<br />
fi<br />
<br />
# report status<br />
if kill -0 ${vm_pid} 2>/dev/null; then<br />
# VM is still alive<br />
#kill -9 ${vm_pid}<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
<br />
# remove pidfile<br />
rm -f "${PIDDIR}/${vm}.pid"<br />
fi<br />
done<br />
rm_daemon qemu<br />
;;<br />
<br />
restart)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
<br />
esac<br />
</nowiki>}}<br />
<br />
==See also==<br />
A very good QEMU guide by AlienBOB: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu</div>Lirhttps://wiki.archlinux.org/index.php?title=QEMU&diff=192775QEMU2012-04-04T05:27:41Z<p>Lir: /* Mounting qcow2 image */ The previous link "Wikipedia:Qcow#Mounting_qcow2_images" does not discuss mounting qcow2 images. New wikibooks link does discuss</p>
<hr />
<div>[[Category:Emulators (English)]]<br />
[[Category:Virtualization]]<br />
[[de:Qemu]]<br />
[[fr:Qemu]]<br />
{{i18n|QEMU}}<br />
<br />
From the [http://wiki.qemu.org/Main_Page QEMU about page],<br />
<blockquote><br />
<p>QEMU is a generic and open source machine emulator and virtualizer.</p><br />
<br />
<p>When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.</p><br />
<br />
<p>When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. QEMU supports virtualization when executing under the Xen hypervisor or using the KVM kernel module in Linux. When using KVM, QEMU can virtualize x86, server and embedded PowerPC, and S390 guests.</p><br />
</blockquote><br />
<br />
== Difference between qemu and qemu-kvm ==<br />
Depending on your needs, you can choose either to install upstream {{Pkg|qemu}} or {{Pkg|qemu-kvm}} from the [[Official Repositories|official repositories]].<br />
<br />
KVM (Kernel Virtual Machine) is a Linux kernel module that allows a user space program to utilize the hardware virtualization features of various processors. Today, it supports recent Intel and AMD processors (x86 and x86_64), PPC 440, PPC 970, and S/390 processors.<br />
<br />
QEMU can make use of KVM when running a target architecture that is the same as the host architecture. For instance, when running qemu-system-x86 on an x86 compatible processor, you can take advantage of the KVM acceleration - giving you benefit for your host and your guest system. <br />
<br />
Not all processors support KVM. You will need an x86-based machine running a recent ( >= 2.6.22 ) Linux kernel on an Intel processor with VT-x (virtualization technology) extensions or an AMD processor with SVM (Secure Virtual Machine) extensions (also called AMD-V). Xen has an [http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors (outdated) list] of compatible processors. For Intel processors, see also the [http://ark.intel.com/VTList.aspx Intel® Virtualization Technology List].<br />
<br />
== Installing QEMU ==<br />
To install the machine emulator version (normal QEMU), [[pacman|install]] the {{Pkg|qemu}} package.<br />
<br />
To install the KVM version (please see the [[KVM]] article for more details), [[pacman|install]] the {{Pkg|qemu-kvm}} package.<br />
<br />
== Choosing Windows version==<br />
QEMU can run any version of Windows. However, 98, Me and XP will run at quite a low speed. You should choose either Windows 95 or Windows 2000. Surprisingly, 2000 seems to run faster than 98. The fastest one is 95, which can from time to time make you forget that you are running an emulator :)<br />
<br />
If you own both Win95 and Win98/WinME, then 98lite (from http://www.litepc.com) might be worth trying. It decouples Internet Explorer from operating system and replaces it with original Windows 95 Explorer. It also enables you to do a minimal Windows installation, without all the bloat you normally cannot disable. This might be the best option, because you get the smallest, fastest and most stable Windows this way.<br />
<br />
== Creating the hard disk image==<br />
To run QEMU you will probably need a hard disk image. This is a file which stores the contents of the emulated hard disk.<br />
<br />
Use the command:<br />
qemu-img create -f qcow2 win.qcow 4G<br />
to create the image file named "win.qcow". The "4G" parameter specifies the size of the disk - in this case 4 GB. You can use suffix M for megabytes (for example "256M"). You should not worry too much about the size of the disk - the qcow2 format compresses the image so that the empty space does not add up to the size of the file.<br />
<br />
== Preparing the installation media==<br />
The installation CD-ROM/floppy should not be mounted, because QEMU accesses the media directly. It is a good idea to dump CD-ROM and/or floppy to a file, because it both improves performance and does not require you to have direct access to the devices (that is, you can run QEMU as a regular user). For example, if the CD-ROM device node is named {{ic|/dev/cdrom}}, you can dump it to a file with the command:<br />
dd if=/dev/cdrom of=win98icd.iso<br />
<br />
Do the same for floppies:<br />
dd if=/dev/fd of=win95d1.img<br />
<br />
When you need to replace floppies within QEMU, just copy the contents of one floppy over another. For this reason, it is useful to create a special file that will hold the current floppy:<br />
touch floppy.img<br />
<br />
== Installing the operating system==<br />
This is the first time you will need to start the emulator.<br />
One thing to keep in mind: when you click inside the QEMU window, the mouse pointer is grabbed. To release it press {{Keypress|Ctrl+Alt}}.<br />
<br />
If you need to use a bootable floppy, run QEMU with:<br />
qemu -cdrom <nowiki>[[cdrom''image]]</nowiki> -fda <nowiki>[[floppy''image]]</nowiki> -boot a <nowiki>[[hd_image]]</nowiki><br />
<br />
or if you are on a x86_64 system (will avoid many problems afterwards):<br />
qemu-system-x86_64 -cdrom <nowiki>[[cdrom''image]]</nowiki> -fda <nowiki>[[floppy''image]]</nowiki> -boot a <nowiki>[[hd_image]]</nowiki><br />
<br />
If your CD-ROM is bootable or you are using ISO files, run QEMU with:<br />
qemu -cdrom <nowiki>[[cdrom''image]]</nowiki> -boot d <nowiki>[[hd''image]]</nowiki><br />
<br />
or if you are on a x86_64 system (will avoid many problems afterwards):<br />
qemu-system-x86_64 -cdrom <nowiki>[[cdrom''image]]</nowiki> -boot d <nowiki>[[hd''image]]</nowiki><br />
<br />
Now partition the virtual hard disk, format the partitions and install the OS.<br />
<br />
A few hints:<br />
# If you are using Windows 95 boot floppy, then choosing SAMSUNG as the type of CD-ROM seems to work<br />
# There are problems when installing Windows 2000. Windows setup will generate a lot of edb*.log files, one after the other containing nothing but blank spaces in {{ic|C:\WINNT\SECURITY}} which quickly fill the virtual hard disk. A workaround is to open a Windows command prompt as early as possible during setup (by pressing {{Keypress|Shift+F10}}) which will allow you to remove these log files as they appear by typing:<br />
del %windir%\security\*.log<br />
<br />
{{Note|According to the official QEMU website, "Windows 2000 has a bug which gives a disk full problem during its installation. When installing it, use the {{ic|-win2k-hack}} QEMU option to enable a specific workaround. After Windows 2000 is installed, you no longer need this option (this option slows down the IDE transfers)."}}<br />
<br />
== Running the system==<br />
To run the system simply type:<br />
qemu [hd_image]<br />
<br />
A good idea is to use overlay images. This way you can create hard disk image once and tell QEMU to store changes in external file.<br />
You get rid of all the instability, because it is so easy to revert to previous system state :)<br />
<br />
To create an overlay image, type:<br />
<nowiki>qemu-img create -b [[base''image]] -f qcow2 [[overlay''image]]</nowiki><br />
<br />
Substitute the hard disk image for base_image (in our case win.qcow). After that you can run qemu with:<br />
qemu [overlay_image]<br />
<br />
or if you are on a x86_64 system:<br />
qemu-system-x86_64 [overlay_image]<br />
<br />
and the original image will be left untouched. One hitch, the base image cannot be renamed or moved, the overlay remembers the base's full path.<br />
<br />
== Moving data between host and guest OS ==<br />
If you have servers on your host OS, they will be accessible with the IP address 10.0.2.2 without any further configuration. So you could just FTP, SSH, etc. to 10.0.2.2 from Windows to share data, or if you would like, you can use [[Samba]].<br />
<br />
=== Samba ===<br />
QEMU supports [[Samba]] which allows you to mount host directories during the emulation. It seems that there is an incompatibility with Samba 3.x. and some versions of QEMU. But at least with a current snapshot of QEMU it should be working.<br />
<br />
First, you need to have a working Samba installation. Then add the following section to your {{ic|smb.conf}}:<br />
{{bc|<nowiki><br />
[qemu]<br />
comment = Temporary file space<br />
path = /tmp<br />
read only = no<br />
public = yes<br />
</nowiki>}}<br />
<br />
Now start QEMU with:<br />
qemu [hd_image] -smb qemu<br />
<br />
Then you should be able to access your host's Samba server with the IP address 10.0.2.2. If you are running Win9x as a guest OS, you may need to add<br />
10.0.2.2 smbserver<br />
to {{ic|C:\Windows\lmhosts}} (Win9x has Lmhosts.sam as a SAMple, rename it!).<br />
<br />
=== Mounting the hard disk image - raw image===<br />
Fortunately there is a way to mount the hard disk image with a loopback device. Login as root, make a temporary directory and mount the image with the command:<br />
mount -o loop,offset=32256 [hd_image] [tmp_dir]<br />
<br />
Now you can copy data in both directions. When you are done, umount with:<br />
umount [hd_image]<br />
<br />
The drawback of this solution is that you cannot use it with qcow images (including overlay images). So you need to create you images without \"-f qcow\" option.<br />
{{Tip|Create a second, raw hard drive image. This way you will be able to transfer data easily and use qcow overlay images for the primary drive.}}<br />
<br />
{{Warning|Never run QEMU while the image is mounted!}}<br />
<br />
=== Mounting qcow2 image ===<br />
You may mount a qcow2 image using {{ic|qemu-nbd}}. See [[http://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host]].<br />
<br />
=== Using any real partition as the single primary partition of a hard disk image ===<br />
Sometimes, you may wish to use one of your system partition from within QEMU (for instance, if you wish booting both your real machine or QEMU using a given partition as root). You can do this using software RAID in linear mode (you need the linear.ko kernel driver) and a loopback device: the trick is to dynamically prepend a master boot record (MBR) to the real partition you wish to embed in a QEMU raw disk image.<br />
<br />
Suppose you have a plain, unmounted {{ic|/dev/hdaN}} partition with some filesystem on it you wish to make part of a QEMU disk image. First, you create some small file to hold the MBR:<br />
dd if=/dev/zero of=/path/to/mbr count=32<br />
<br />
Here, a 16 KB (32 * 512 bytes) file is created. It is important not to make it too small (even if the MBR only needs a single 512 bytes block), since the smaller it will be, the smaller the chunk size of the software RAID device will have to be, which could have an impact on performance. Then, you setup a loopback device to the MBR file:<br />
losetup -f /path/to/mbr<br />
<br />
Let's assume the resulting device is {{ic|/dev/loop0}}, because we would not already have been using other loopbacks. Next step is to create the "merged" MBR + {{ic|/dev/hdaN}} disk image using software RAID:<br />
modprobe linear<br />
mdadm --build --verbose /dev/md0 --chunk=16 --level=linear --raid-devices=2 /dev/loop0 /dev/hdaN<br />
<br />
The resulting {{ic|/dev/md0}} is what you will use as a QEMU raw disk image (do not forget to set the permissions so that the emulator can access it). The last (and somewhat tricky) step is to set the disk configuration (disk geometry and partitions table) so that the primary partition start point in the MBR matches the one of {{ic|/dev/hdaN}} inside {{ic|/dev/md0}} (an offset of exactly 16 * 512 = 16384 bytes in this example). Do this using {{ic|fdisk}} on the host machine, not in the emulator: the default raw disc detection routine from QEMU often results in non kilobyte-roundable offsets (such as 31.5 KB, as in the previous section) that cannot be managed by the software RAID code. Hence, from the the host:<br />
fdisk /dev/md0<br />
<br />
Press {{Keypress|X}} to enter the expert menu. Set number of 's'ectors per track so that the size of one cylinder matches the size of your MBR file. For two heads and a sector size of 512, the number of sectors per track should be 16, so we get cylinders of size 2x16x512=16k.<br />
<br />
Now, press {{Keypress|R}} to return to the main menu. <br />
<br />
Press {{Keypress|P}} and check that the cylinder size is now 16k.<br />
<br />
Now, create a single primary partition corresponding to {{ic|/dev/hdaN}}. It should start at cylinder 2 and end at the end of the disk (note that the number of cylinders now differs from what it was when you entered fdisk.<br />
<br />
Finally, 'w'rite the result to the file: you are done. You know have a partition you can mount directly from your host, as well as part of a QEMU disk image: <br />
<br />
qemu -hdc /dev/md0 [...]<br />
<br />
You can of course safely set any bootloader on this disk image using QEMU, provided the original {{ic|/dev/hdaN}} partition contains the necessary tools.<br />
<br />
==Optimizing Windows 9X CPU usage==<br />
Windows 9X uses an idle loop instead of the HLT (halt) instruction. Consequently, the emulator will consume all CPU resources when running Windows 9X guests -- even if no work is being done. This only applies to DOS and DOS-based Windows versions (3.X, 95/98/ME) -- NT-based and later Windows versions are not affected.<br />
<br />
To resolve this issue, install [http://www.benchtest.com/rain.html Rain], [http://www.benchtest.com/wfp.html Waterfall] or [http://www.benchtest.com/cpuidle.html CpuIdle] in the Windows 9X guest. (Rain might be preferred because it does only what is needed -- replacing the idle loop with the HLT instruction -- and nothing more.)<br />
<br />
See [https://forums.virtualbox.org/viewtopic.php?f=28&t=9918 Tutorial: Windows 95/98 guest OSes] for more information.<br />
<br />
== Using the Kernel-based Virtual Machine ==<br />
<br />
[[KVM]] is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. Using KVM, one can run multiple virtual machines running unmodified Linux or Windows images. Each virtual machine has private virtualized hardware: a network card, disk, graphics adapter, etc.<br />
<br />
This technology requires an x86 machine running a recent ( >= 2.6.22) Linux kernel on an Intel processor with VT-x (virtualization technology) extensions, or an AMD processor with SVM (Secure Virtual Machine) extensions. It is included in the mainline Linux kernel since 2.6.20 and is enabled by default in the Arch Linux kernel.<br />
<br />
Even though QEMU in recent versions ( < 0.15.0) does have initial KVM support ({{ic|qemu --enable-kvm}}), it is not recommended to use this, as many KVM-related functions still have not been implemented in upstream QEMU. Instead, you should go for the {{Pkg|qemu-kvm}} package in the [[Official Repositories|official repositories]], which is released by the KVM development team and contains all of the latest features (and bugfixes) of KVM userspace. Please refer to the [[KVM]] page itself, for more information on using QEMU with KVM on Arch Linux.<br />
<br />
{{Note|{{Pkg|qemu}} ><nowiki>=</nowiki> 0.15.0 has full support for KVM, as the qemu-kvm tree has been completely merged into the upstream qemu tree. There should be no difference between {{ic|qemu -enable-kvm}} and {{ic|qemu-kvm}} if your version of {{Pkg|qemu}} is ><nowiki>=</nowiki> 0.15.0.}}<br />
<br />
To take advantage of KVM, you simply need a compatible processor (the following command must return something on the screen):<br />
grep -E "(vmx|svm)" --color=always /proc/cpuinfo<br />
<br />
And load the appropriate module from your {{ic|/etc/[[rc.conf]]}}.<br />
<br />
* For Intel® processors add {{ic|kvm-intel}} to your {{ic|MODULES}} array in {{ic|/etc/rc.conf}}<br />
* for AMD® processors add {{ic|kvm-amd}} to your {{ic|MODULES}} array in {{ic|/etc/rc.conf}}<br />
<br />
Also, you will need to add yourself to the group {{ic|kvm}}.<br />
gpasswd -a <Your_User_Account> kvm<br />
<br />
==Networking==<br />
===Basic Networking===<br />
To add basic networking to your virtual machine, you may have to simply load QEMU with these options: {{ic|<nowiki>-net nic,vlan=1 -net user,vlan=1</nowiki>}}. For example, to load a CD-ROM, you could use:<br />
qemu -kernel-kqemu -no-acpi -net nic,vlan=1 -net user,vlan=1 -cdrom dsl-4.3rc1.iso<br />
Note that this only supports the TCP and UDP protocols. In particular ICMP and thus ping will not work.<br />
<br />
=== Tap Networking with QEMU ===<br />
==== Basic Idea ====<br />
Tap networking in QEMU lets virtual machines register themselves as though with separate Ethernet adapters and have their traffic bridged directly onto your local area network. This is sometimes very desirable, if you want your virtual machines to be able to talk to each other, or for other machines on your LAN to talk to virtual machines.<br />
<br />
==== Security Warning ====<br />
You probably '''should not''' use this networking method if your host Arch machine is directly on the Internet. It can expose your virtual machines directly to attack!<br />
<br />
In general, Arch Linux disclaims any responsibility for security implications (or implications of any kind, really) from following these instructions.<br />
<br />
==== Nitty Gritty ====<br />
To set all of this up, you will need to install the following packages:<br />
*{{Pkg|bridge-utils}} (provides {{ic|brctl}}, to manipulate bridges)<br />
*{{Pkg|uml_utilities}} (for tunctl, to manipulate taps)<br />
<br />
We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it. See http://en.gentoo-wiki.com/wiki/KVM#Networking_2 .<br />
<br />
Make sure IPv4 forwarding is set. You should have the line {{ic|<nowiki>net.ipv4.ip_forward=1</nowiki>}} in your {{ic|/etc/sysctl.conf}}.<br />
<br />
Take the following steps:<br />
<br />
1. Add {{ic|bridge}} and {{ic|tun}} to your {{ic|MODULES}} array in {{ic|/etc/rc.conf}}:<br />
<br />
MODULES=( ... bridge tun)<br />
<br />
2. Configure your bridge {{ic|br0}} to have your real Ethernet adapter (assuming {{ic|eth0}} for the rest of this guide) in it, in {{ic|/etc/conf.d/bridges}}:<br />
bridge_br0="eth0"<br />
control_br0="setfd br0 0"<br />
BRIDGE_INTERFACES=(br0)<br />
<br />
{{Note|This is not described anywhere, but adding the {{ic|control_br0}} line is vital for the bridge to work! For more details look here: {{bug|16625}}}}<br />
<br />
3. Change your networking configuration so that you just bring up your real Ethernet adapter without configuring it, allowing real configuration to happen on the bridge interface. In {{ic|/etc/rc.conf}}:<br />
eth0="eth0 up"<br />
br0="dhcp"<br />
INTERFACES=(eth0 br0)<br />
<br />
Remember, especially if you are doing DHCP, it is essential that the bridge comes up AFTER the real adapter, otherwise the bridge will not be able to talk to anything to get a DHCP address!<br />
<br />
If DHCP does not work, try with a static IP address in {{ic|/etc/rc.conf}}:<br />
eth0="eth0 0.0.0.0"<br />
br0="br0 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255"<br />
INTERFACES=(eth0 br0)<br />
gateway="default gw 192.168.0.1"<br />
ROUTES=(gateway)<br />
<br />
and then in {{ic|/etc/resolv.conf}}:<br />
domain lan<br />
nameserver 192.168.0.1<br />
<br />
4. Install the script that QEMU uses to bring up the tap adapter in {{ic|/etc/qemu-ifup}} with root:kvm 750 permissions:<br />
#!/bin/sh<br />
<br />
echo "Executing /etc/qemu-ifup"<br />
echo "Bringing up $1 for bridged mode..."<br />
sudo /sbin/ifconfig $1 0.0.0.0 promisc up<br />
echo "Adding $1 to br0..."<br />
sudo /usr/sbin/brctl addif br0 $1<br />
sleep 2<br />
<br />
5. Use {{ic|visudo}} to add the following to your {{ic|sudoers}} file:<br />
Cmnd_Alias QEMU=/sbin/ifconfig,/sbin/modprobe,/usr/sbin/brctl,/usr/bin/tunctl<br />
%kvm ALL=NOPASSWD: QEMU<br />
<br />
6. Make sure the user(s) wishing to use this new functionality are in the {{ic|kvm}} group. Exit and log in again if necessary.<br />
<br />
7. You launch QEMU using the following {{ic|run-qemu}} script:<br />
#!/bin/bash<br />
USERID=`whoami`<br />
IFACE=$(sudo tunctl -b -u $USERID)<br />
<br />
qemu-kvm -net nic -net tap,ifname="$IFACE" $*<br />
<br />
sudo tunctl -d $IFACE &> /dev/null<br />
<br />
Then to launch a VM, do something like this<br />
$ run-qemu -hda myvm.img -m 512 -vga std<br />
<br />
8. If you cannot get a DHCP address in the host, it might be because iptables are up by default in the bridge. In that case (from http://www.linux-kvm.org/page/Networking ):<br />
# cd /proc/sys/net/bridge<br />
# ls<br />
bridge-nf-call-arptables bridge-nf-call-iptables<br />
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged<br />
# for f in bridge-nf-*; do echo 0 > $f; done<br />
<br />
And if you still cannot get networking to work, see: [[Linux_Containers#Bridge_device_setup]]<br />
<br />
=== Networking with [[VDE2]] ===<br />
==== What is VDE? ====<br />
VDE stands for Virtual Distributed Ethernet. It started as an enhancement of [[User-mode Linux|uml]]_switch. It is a toolbox to manage virtual networks.<br />
<br />
The idea is to create virtual switches, which are basically sockets, and to "plug" both physical and virtual machines in them. The configuration I show here is quite simple; However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. Your are invited to read [http://wiki.virtualsquare.org/wiki/index.php/Main_Page the documentation of the project].<br />
<br />
The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe.<br />
<br />
==== Basics ====<br />
VDE is in the [[Official Repositories|official repositories]], so...<br />
<br />
# pacman -S vde2<br />
<br />
In my config, I use tun/tap to create a virtual interface on my host. Load the {{ic|tun}} module (or add it to your {{ic|MODULES}} array in {{ic|[[rc.conf]]}}):<br />
<br />
# modprobe tun<br />
<br />
Now create the virtual switch:<br />
<br />
# vde_switch -tap tap0 -daemon -mod 660 -group kvm<br />
<br />
This line creates the switch, creates tap0, "plugs" it, and allows the users of the group {{ic|kvm}} to use it.<br />
<br />
The interface is plugged in but not configured yet. Just do it:<br />
<br />
# ifconfig tap0 192.168.100.254 netmask 255.255.255.0<br />
<br />
That is all! Now, you just have to run KVM with these {{ic|-net}} options as a normal user:<br />
<br />
$ qemu-kvm -net nic -net vde -hda ...<br />
<br />
Configure your guest as you would do in a physical network. I gave them static addresses and let them access the WAN using IP forwarding and masquerading on my host:<br />
<br />
# echo "1" > /proc/sys/net/ipv4/ip_forward<br />
# iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE<br />
<br />
==== Putting it together ====<br />
I added this init script to run all this at start-up:<br />
<br />
#!/bin/bash <br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
case "$1" in<br />
start)<br />
stat_busy "Starting VDE Switch"<br />
vde_switch -tap tap0 -daemon -mod 660 -pidfile $PIDFILE -group kvm<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
echo "1" > /proc/sys/net/ipv4/ip_forward && \<br />
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE && \<br />
ifconfig tap0 192.168.100.254 netmask 255.255.255.0 && \<br />
stat_done || stat_fail<br />
fi<br />
;;<br />
stop)<br />
stat_busy "Stopping VDE Switch"<br />
# err.. well, i should remove the switch here...<br />
stat_done<br />
;;<br />
restart)<br />
$0 stop<br />
sleep 1<br />
# Aem.. As long as stop) is not implemented, this just fails<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}" <br />
esac<br />
exit 0<br />
<br />
Well, I know it is dirty and could be more configurable. Feel free to improve it. VDE has an rc script too, but I had to make one anyway for the IP forwarding stuff.<br />
<br />
====Alternative method====<br />
If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq and iptables you can do the following for the same result.<br />
<br />
vde_switch -daemon -mod 660 -group kvm<br />
<br />
slirpvde --dhcp --daemon<br />
<br />
Then to start the vm with a connection to the network of the host:<br />
<br />
kvm -net nic,macaddr=52:54:00:00:EE:03 -net vde whatever.qcow<br />
<br />
== Graphics ==<br />
QEMU can use the following different graphic outputs: std, cirrus, vmware, qxl, xenfs and vnc.<br />
With the {{ic|vnc}} option you can run your guest standalone and connect to it via VNC. Other options are using {{ic|std}}, {{ic|vmware}}, {{ic|cirrus}}:<br />
<br />
===std===<br />
With {{ic|-vga std}} you can get a resolution of up to 2560 x 1600 pixels.<br />
<br />
===vmware===<br />
Although it is a bit buggy, it performs better than std and cirrus. On the guest, install the VMware drivers:<br />
pacman -S xf86-video-vmware xf86-input-vmmouse<br />
<br />
===Windows guest===<br />
If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. Use: (if you are using a VLAN or are not in the same network as the guest)<br />
qemu -nographic -net user,hostfwd=tcp::5555-:3389<br />
Then connect with either rdesktop or freerdp to the guest, for example:<br />
xfreerdp -g 2048x1152 localhost:5555 -z -x lan<br />
<br />
== Front-ends for QEMU ==<br />
There are a few GUI Front-ends for QEMU:<br />
* {{Pkg|qemu-launcher}}<br />
* community/qemulator<br />
* {{Pkg|qtemu}}<br />
<br />
==Keyboard seems broken / Arrow keys do not work==<br />
Should you find that some of your keys do not work or "press" the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in {{ic|/usr/share/qemu/keymaps}}.<br />
{{bc|<br />
qemu -k [keymap] [disk_image]<br />
}}<br />
<br />
==Starting QEMU virtual machines on boot==<br />
To run QEMU VMs on boot, you can use following rc-script and config.<br />
<br />
{| border="1"<br />
|+ Config file options<br />
|-<br />
| QEMU_MACHINES || List of VMs to start<br />
|-<br />
| qemu_${vm}_type || QEMU binary to call. If specified, will be prepended with {{ic|/usr/bin/qemu-}} and that binary will be used to start the VM. I.e. you can boot e.g. qemu-system-arm images with qemu_my_arm_vm_type="system-arm". If not specified, {{ic|/usr/bin/qemu}} will be used.<br />
|-<br />
| qemu_${vm} || QEMU command line to start with. Will always be prepended with {{ic|-name ${vm} -pidfile /var/run/qemu/${vm}.pid -daemonize -nographic}}.<br />
|-<br />
| qemu_${vm}_haltcmd || Command to shutdown VM safely. I am using {{ic|-monitor telnet:..}} and power off my VMs via ACPI by sending {{ic|system_powerdown}} to monitor. You can use ssh or some other ways.<br />
|-<br />
| qemu_${vm}_haltcmd_wait || How much time to wait for safe VM shutdown. Default is 30 seconds. rc-script will kill qemu process after this timeout.<br />
|}<br />
<br />
Config file example:<br />
{{hc|/etc/conf.d/qemu.conf|<nowiki><br />
# VMs that should be started on boot<br />
# use the ! prefix to disable starting/stopping a VM<br />
QEMU_MACHINES=(vm1 vm2)<br />
<br />
# NOTE: following options will be prepended to qemu_${vm}<br />
# -name ${vm} -pidfile /var/run/qemu/${vm}.pid -daemonize -nographic<br />
<br />
qemu_vm1_type="system-x86_64"<br />
<br />
qemu_vm1="-enable-kvm -m 512 -hda /dev/mapper/vg0-vm1 -net nic,macaddr=DE:AD:BE:EF:E0:00 \<br />
-net tap,ifname=tap0 -serial telnet:localhost:7000,server,nowait,nodelay \<br />
-monitor telnet:localhost:7100,server,nowait,nodelay -vnc :0"<br />
<br />
qemu_vm1_haltcmd="echo 'system_powerdown' | nc.openbsd localhost 7100" # or netcat/ncat<br />
<br />
# You can use other ways to shutdown your VM correctly<br />
#qemu_vm1_haltcmd="ssh powermanager@vm1 sudo poweroff"<br />
<br />
# By default rc-script will wait 30 seconds before killing VM. Here you can change this timeout.<br />
#qemu_vm1_haltcmd_wait="30"<br />
<br />
qemu_vm2="-enable-kvm -m 512 -hda /srv/kvm/vm2.img -net nic,macaddr=DE:AD:BE:EF:E0:01 \<br />
-net tap,ifname=tap1 -serial telnet:localhost:7001,server,nowait,nodelay \<br />
-monitor telnet:localhost:7101,server,nowait,nodelay -vnc :1"<br />
<br />
qemu_vm2_haltcmd="echo 'system_powerdown' | nc.openbsd localhost 7101"<br />
</nowiki>}}<br />
<br />
rc-script:<br />
{{hc|/etc/rc.d/qemu|<nowiki><br />
#!/bin/bash<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
[ -f /etc/conf.d/qemu.conf ] && source /etc/conf.d/qemu.conf<br />
<br />
PIDDIR=/var/run/qemu<br />
QEMU_DEFAULT_FLAGS='-name ${vm} -pidfile ${PIDDIR}/${vm}.pid -daemonize -nographic'<br />
QEMU_HALTCMD_WAIT=30<br />
<br />
case "$1" in<br />
start)<br />
[ -d "${PIDDIR}" ] || mkdir -p "${PIDDIR}"<br />
for vm in "${QEMU_MACHINES[@]}"; do<br />
if [ "${vm}" = "${vm#!}" ]; then<br />
stat_busy "Starting QEMU VM: ${vm}"<br />
eval vm_cmdline="\$qemu_${vm}"<br />
eval vm_type="\$qemu_${vm}_type"<br />
<br />
if [ -n "${vm_type}" ]; then<br />
vm_cmd="/usr/bin/qemu-${vm_type}"<br />
else<br />
vm_cmd='/usr/bin/qemu'<br />
fi<br />
<br />
eval "qemu_flags=\"${QEMU_DEFAULT_FLAGS}\""<br />
<br />
${vm_cmd} ${qemu_flags} ${vm_cmdline} >/dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
fi<br />
done<br />
add_daemon qemu<br />
;;<br />
<br />
stop)<br />
for vm in "${QEMU_MACHINES[@]}"; do<br />
if [ "${vm}" = "${vm#!}" ]; then<br />
# check pidfile presence and permissions<br />
if [ ! -r "${PIDDIR}/${vm}.pid" ]; then<br />
continue<br />
fi<br />
<br />
stat_busy "Stopping QEMU VM: ${vm}"<br />
<br />
eval vm_haltcmd="\$qemu_${vm}_haltcmd"<br />
eval vm_haltcmd_wait="\$qemu_${vm}_haltcmd_wait"<br />
vm_haltcmd_wait=${vm_haltcmd_wait:-${QEMU_HALTCMD_WAIT}}<br />
vm_pid=$(cat ${PIDDIR}/${vm}.pid)<br />
<br />
# check process existence<br />
if ! kill -0 ${vm_pid} 2>/dev/null; then<br />
stat_done<br />
rm -f "${PIDDIR}/${vm}.pid"<br />
continue<br />
fi<br />
<br />
# Try to shutdown VM safely<br />
_vm_running='yes'<br />
if [ -n "${vm_haltcmd}" ]; then<br />
eval ${vm_haltcmd} >/dev/null<br />
<br />
_w=0<br />
while [ "${_w}" -lt "${vm_haltcmd_wait}" ]; do<br />
sleep 1<br />
if ! kill -0 ${vm_pid} 2>/dev/null; then<br />
# no such process<br />
_vm_running=''<br />
break<br />
fi<br />
_w=$((_w + 1))<br />
done<br />
<br />
else<br />
# No haltcmd - kill VM unsafely<br />
_vm_running='yes'<br />
fi<br />
<br />
if [ -n "${_vm_running}" ]; then<br />
# kill VM unsafely<br />
kill ${vm_pid} 2>/dev/null<br />
sleep 1<br />
fi<br />
<br />
# report status<br />
if kill -0 ${vm_pid} 2>/dev/null; then<br />
# VM is still alive<br />
#kill -9 ${vm_pid}<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
<br />
# remove pidfile<br />
rm -f "${PIDDIR}/${vm}.pid"<br />
fi<br />
done<br />
rm_daemon qemu<br />
;;<br />
<br />
restart)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
<br />
esac<br />
</nowiki>}}<br />
<br />
==See also==<br />
A very good QEMU guide by AlienBOB: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu</div>Lirhttps://wiki.archlinux.org/index.php?title=PPTP_Client&diff=41735PPTP Client2008-05-22T18:04:53Z<p>Lir: /* Install */ - package now in core repo instead of community</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
From the [http://pptpclient.sourceforge.net pptpclient] website:<br />
<br />
''"PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based Virtual Private Network (VPN) as used by employers and some cable and ADSL internet service providers."''<br />
<br />
While pptpclient is great and lightweight, it isn't exactly the easiest thing to get up and running by itself. There is another program called [http://quozl.linux.org.au/pptp/pptpconfig/pptpconfig.phtml pptpconfig] which does what I describe below and more. Unfortunately it's not in any of the repos and I couldn't get all the php4 stuff that it depends on to work. If/when it makes it into the repositories, use that instead of this.<br />
<br />
Lastly I got almost all of my information from [http://forum.piratpartiet.se/Topic64139-164-1.aspx this] forum post (connecting to Relakks from Arch) and from the pptpclient's pages on [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand configuring by hand] and [http://pptpclient.sourceforge.net/routing.phtml routing]. If my way doesn't work for you try those pages.<br />
<br />
==Install==<br />
The package we need is pptpclient, which is in the [core] repository.<br />
<br />
pacman -S pptpclient<br />
<br />
If you don't already have ppp installed, make sure pacman picks it up for you.<br />
<br />
==Configuring and Connecting==<br />
<br />
===Firewall Config===<br />
If your smart/safe you're running a firewall. If thats so, we need to make sure some things are open in order for us to be able to connect. Personally I use [http://www.simonzone.com/software/guarddog guarddog], in which case you just need to go to the Protocol Tab->Internet Zone->Networking and make sure PPTP is checked.<br />
<br />
If you use [http://www.fs-security.com/ firestarter], they supposedly have a workaround for VPNs, but it didn't work for me.<br />
<br />
Lastly if you despise all GUIness and still use iptables directly, check out the [http://forum.piratpartiet.se/Topic64139-164-1.aspx forum] post from above, it uses iptables. For the most part it involves opening protocol 47 and port 1723.<br />
<br />
===PPTP Config===<br />
<br />
All (I think) configuration and running of pptpclient requires root, so first<br />
su<br />
<br />
Then<br />
cd /etc/ppp<br />
<br />
Here you should see the following files:<br />
$ls -l<br />
total 36K<br />
-rw------- 1 root root 78 2006-09-28 02:52 chap-secrets<br />
-rwxr-xr-x 1 root root 75 2006-09-28 02:52 ip-down*<br />
-rwxr-xr-x 1 root root 85 2006-09-28 02:52 ip-up*<br />
-rw-r--r-- 1 root root 14K 2006-09-28 02:52 options<br />
-rw-r--r-- 1 root root 1.7K 2006-12-25 06:06 options.pptp<br />
-rw------- 1 root root 77 2006-09-28 02:52 pap-secrets<br />
<br />
Of those files we only need to muck with '''options.pptp''' and '''chap-secrets'''<br />
<br />
My options.pptp file has these options set<br />
lock<br />
noauth<br />
refuse-eap<br />
refuse-chap<br />
refuse-mschap<br />
nobsdcomp<br />
nodeflate<br />
<br />
In chap-secrets put username, password, a name to identify the server and a * for ip addresses<br />
DOMAIN\\MyUserName TheServer MyPassWord *<br />
<br />
Note: If your pptp server does not require a domain name, leave it and the slashes out.<br />
<br />
Yes you really did just put your password in a file in plain text, so<br />
chmod 600 chap-secrets<br />
If it wasn't already that way.<br />
<br />
Now its time to define our vpn connection:<br />
<br />
First<br />
mkdir peers; cd peers<br />
<br />
Now come up with a name for your connection, I'll call it myCon.<br />
touch myCon<br />
Add the following lines with your editor of choice, making sure that the variables match what you defined in '''chap-secrets''':<br />
remotename TheServer<br />
ipparam myCon<br />
pty "pptp my.vpn.server --nolaunchpppd"<br />
name DOMAIN\\MyUserName<br />
usepeerdns<br />
require-mppe-128<br />
refuse-eap<br />
noauth<br />
file /etc/ppp/options.pptp<br />
<br />
If you don't need MPPE support, remove the require-mppe-128 line<br />
<br />
With that you should be able to execute the following command<br />
pon myCon<br />
and see something like this in /var/log/daemon.log<br />
pppd[10505]: pppd 2.4.4 started by root, uid 0<br />
pppd[10505]: Using interface ppp0<br />
pppd[10505]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[10506]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 64029).<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF<br />
pptp[10513]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!<br />
pppd[10505]: CHAP authentication succeeded<br />
pppd[10505]: MPPE 128-bit stateless compression enabled<br />
pppd[10505]: Cannot determine ethernet address for proxy ARP<br />
pppd[10505]: local IP address '''<local IP address>'''<br />
pppd[10505]: remote IP address '''<remote IP address>'''<br />
pppd[10505]: primary DNS address '''<primary DNS>'''<br />
pppd[10505]: secondary DNS address '''<secondary DNS>'''<br />
<br />
Issuing<br />
ifconfig ppp0<br />
should show you an inet addr matching '''<local IP address>''' and P-t-P matching '''<remote IP address>'''<br />
<br />
If that didn't work, see below in the Troubleshooting section<br />
<br />
===Network Config===<br />
If the vpn server is also the computer you need to connect to, then you can skip this section. However, if you're like me, the vpn server is just a gateway and what you really want access to is the computers on the other side. There are several different methods of routing traffic through the vpn tunnel, all of which can be found [http://pptpclient.sourceforge.net/routing.phtml here] at the pptpclient's website. For my purposes, I want only traffic destined for the remote network to go through the tunnel, i.e. a Client -> LAN setup.<br />
<br />
For this to work, you need to know what the remote network address start with, i.e. 192.168.10.<br />
So for every subnet (is that the right term?) on the remote network that you want to access, issue this command<br />
route add -net <subnet address>.0 netmask 255.255.255.0 dev ppp0<br />
Which in our example of remote network addresses starting with 192.168.10 means<br />
route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0<br />
<br />
Alternatively if you only have particular hosts on the other side you want to connect to (say 192.168.10.160), this ought to do the trick<br />
route add -host 192.168.10.160 dev ppp0<br />
<br />
Now that we have that set, if pptp found DNS servers for the remote network, you'll want to use/add those to /etc/resolv.conf. Conveniently it stores them in /etc/ppp/resolv.conf, so just take whats there and add it to the beginning of your existing resolv.conf<br />
mv /etc/resolv.conf /etc/resolv.conf.bak<br />
mv /etc/ppp/resolv.conf /etc/resolv.conf<br />
cat /etc/resolv.conf.bak >> /etc/resolv.conf<br />
<br />
With that you should be connected! Try route, ping, and/or traceroute to see the layout of your connections.<br />
<br />
===Connection teardown===<br />
When your done just issue<br />
poff myCon<br />
<br />
Also don't forget to restore your resolv.conf<br />
mv /etc/resolv.conf.bak /etc/resolv.conf<br />
<br />
==Troubleshooting==<br />
<br />
===Bad config files===<br />
When my server identifier in '''chap-secrets''' didn't match what ''remotename'' was in '''peers/myCon''', I got the following in '''/var/log/daemon.log''':<br />
pppd[13068]: pppd 2.4.4 started by root, uid 0<br />
pppd[13068]: Using interface ppp0<br />
pppd[13068]: Connect: ppp0 <--> /dev/pts/5<br />
pptp[13069]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 15473).<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:911]: Received Call Clear Request.<br />
pptp[13082]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed<br />
pptp[13082]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'<br />
pptp[13082]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed<br />
pptp[13082]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)<br />
pppd[13068]: Modem hangup<br />
pppd[13068]: Connection terminated.<br />
pppd[13068]: Exit.<br />
<br />
===Firewall isn't configured correctly===<br />
If this is the case you should see logs from your firewall blocking things from your ip to my.vpn.server, but in case it helps, here is what it looks like from the pppd logs.<br />
<br />
When the firewall is blocking things<br />
pppd[25387]: pppd 2.4.4 started by root, uid 0<br />
pppd[25387]: Using interface ppp0<br />
pppd[25387]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[25388]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pppd[25387]: LCP: timeout sending Config-Requests<br />
pppd[25387]: Connection terminated.<br />
pppd[25387]: Modem hangup<br />
pppd[25387]: Exit.<br />
<br />
When the firewall is rejecting things<br />
pppd[24971]: pppd 2.4.4 started by root, uid 0<br />
pppd[24971]: Using interface ppp0<br />
pppd[24971]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[24972]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[24974]: anon warn[open_inetsock:pptp_callmgr.c:326]: connect: Connection refused<br />
pptp[24974]: anon fatal[callmgr_main:pptp_callmgr.c:124]: Could not open control connection to 206.169.229.172<br />
pptp[24972]: anon fatal[open_callmgr:pptp.c:439]: Call manager exited with error 256<br />
pppd[24971]: Modem hangup<br />
pppd[24971]: Connection terminated.<br />
pppd[24971]: Exit.</div>Lirhttps://wiki.archlinux.org/index.php?title=PPTP_Client&diff=23152PPTP Client2007-04-15T19:51:24Z<p>Lir: removed options.pptp from the list of files to match variables with when defining connection details in /etc/ppp/peers/myCon</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
From the [http://pptpclient.sourceforge.net pptpclient] website:<br />
<br />
''"PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based Virtual Private Network (VPN) as used by employers and some cable and ADSL internet service providers."''<br />
<br />
While pptpclient is great and lightweight, it isn't exactly the easiest thing to get up and running by itself. There is another program called [http://quozl.linux.org.au/pptp/pptpconfig/pptpconfig.phtml pptpconfig] which does what I describe below and more. Unfortunately it's not in any of the repos and I couldn't get all the php4 stuff that it depends on to work. If/when it makes it into the repositories, use that instead of this.<br />
<br />
Lastly I got almost all of my information from [http://forum.piratpartiet.se/Topic64139-164-1.aspx this] forum post (connecting to Relakks from Arch) and from the pptpclient's pages on [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand configuring by hand] and [http://pptpclient.sourceforge.net/routing.phtml routing]. If my way doesn't work for you try those pages.<br />
<br />
==Install==<br />
The package we need is pptpclient, which is in the [community] repository (uncomment the appropriate lines in /etc/pacman.conf to get it).<br />
<br />
pacman -S pptpclient<br />
<br />
If you don't already have ppp installed, make sure pacman picks it up for you.<br />
<br />
==Configuring and Connecting==<br />
<br />
===Firewall Config===<br />
If your smart/safe you're running a firewall. If thats so, we need to make sure some things are open in order for us to be able to connect. Personally I use [http://www.simonzone.com/software/guarddog guarddog], in which case you just need to go to the Protocol Tab->Internet Zone->Networking and make sure PPTP is checked.<br />
<br />
If you use [http://www.fs-security.com/ firestarter], they supposedly have a workaround for VPNs, but it didn't work for me.<br />
<br />
Lastly if you despise all GUIness and still use iptables directly, check out the [http://forum.piratpartiet.se/Topic64139-164-1.aspx forum] post from above, it uses iptables. For the most part it involves opening protocol 47 and port 1723.<br />
<br />
===PPTP Config===<br />
<br />
All (I think) configuration and running of pptpclient requires root, so first<br />
su<br />
<br />
Then<br />
cd /etc/ppp<br />
<br />
Here you should see the following files:<br />
$ls -l<br />
total 36K<br />
-rw------- 1 root root 78 2006-09-28 02:52 chap-secrets<br />
-rwxr-xr-x 1 root root 75 2006-09-28 02:52 ip-down*<br />
-rwxr-xr-x 1 root root 85 2006-09-28 02:52 ip-up*<br />
-rw-r--r-- 1 root root 14K 2006-09-28 02:52 options<br />
-rw-r--r-- 1 root root 1.7K 2006-12-25 06:06 options.pptp<br />
-rw------- 1 root root 77 2006-09-28 02:52 pap-secrets<br />
<br />
Of those files we only need to muck with '''options.pptp''' and '''chap-secrets'''<br />
<br />
My options.pptp file has these options set<br />
lock<br />
noauth<br />
refuse-eap<br />
refuse-chap<br />
refuse-mschap<br />
nobsdcomp<br />
nodeflate<br />
<br />
In chap-secrets put username, password, a name to identify the server and a * for ip addresses<br />
DOMAIN\\MyUserName TheServer MyPassWord *<br />
<br />
Note: If your pptp server does not require a domain name, leave it and the slashes out.<br />
<br />
Yes you really did just put your password in a file in plain text, so<br />
chmod 600 chap-secrets<br />
If it wasn't already that way.<br />
<br />
Now its time to define our vpn connection:<br />
<br />
First<br />
mkdir peers; cd peers<br />
<br />
Now come up with a name for your connection, I'll call it myCon.<br />
touch myCon<br />
Add the following lines with your editor of choice, making sure that the variables match what you defined in '''chap-secrets''':<br />
remotename TheServer<br />
ipparam myCon<br />
pty "pptp my.vpn.server --nolaunchpppd"<br />
name DOMAIN\\MyUserName<br />
usepeerdns<br />
require-mppe-128<br />
refuse-eap<br />
noauth<br />
file /etc/ppp/options.pptp<br />
<br />
If you don't need MPPE support, remove the require-mppe-128 line<br />
<br />
With that you should be able to execute the following command<br />
pon myCon<br />
and see something like this in /var/log/daemon.log<br />
pppd[10505]: pppd 2.4.4 started by root, uid 0<br />
pppd[10505]: Using interface ppp0<br />
pppd[10505]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[10506]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 64029).<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF<br />
pptp[10513]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!<br />
pppd[10505]: CHAP authentication succeeded<br />
pppd[10505]: MPPE 128-bit stateless compression enabled<br />
pppd[10505]: Cannot determine ethernet address for proxy ARP<br />
pppd[10505]: local IP address '''<local IP address>'''<br />
pppd[10505]: remote IP address '''<remote IP address>'''<br />
pppd[10505]: primary DNS address '''<primary DNS>'''<br />
pppd[10505]: secondary DNS address '''<secondary DNS>'''<br />
<br />
Issuing<br />
ifconfig ppp0<br />
should show you an inet addr matching '''<local IP address>''' and P-t-P matching '''<remote IP address>'''<br />
<br />
If that didn't work, see below in the Troubleshooting section<br />
<br />
===Network Config===<br />
If the vpn server is also the computer you need to connect to, then you can skip this section. However, if you're like me, the vpn server is just a gateway and what you really want access to is the computers on the other side. There are several different methods of routing traffic through the vpn tunnel, all of which can be found [http://pptpclient.sourceforge.net/routing.phtml here] at the pptpclient's website. For my purposes, I want only traffic destined for the remote network to go through the tunnel, i.e. a Client -> LAN setup.<br />
<br />
For this to work, you need to know what the remote network address start with, i.e. 192.168.10.<br />
So for every subnet (is that the right term?) on the remote network that you want to access, issue this command<br />
route add -net <subnet address>.0 netmask 255.255.255.0 dev ppp0<br />
Which in our example of remote network addresses starting with 192.168.10 means<br />
route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0<br />
<br />
Alternatively if you only have particular hosts on the other side you want to connect to (say 192.168.10.160), this ought to do the trick<br />
route add -host 192.168.10.160 dev ppp0<br />
<br />
Now that we have that set, if pptp found DNS servers for the remote network, you'll want to use/add those to /etc/resolv.conf. Conveniently it stores them in /etc/ppp/resolv.conf, so just take whats there and add it to the beginning of your existing resolv.conf<br />
mv /etc/resolv.conf /etc/resolv.conf.bak<br />
mv /etc/ppp/resolv.conf /etc/resolv.conf<br />
cat /etc/resolv.conf.bak >> /etc/resolv.conf<br />
<br />
With that you should be connected! Try route, ping, and/or traceroute to see the layout of your connections.<br />
<br />
===Connection teardown===<br />
When your done just issue<br />
poff myCon<br />
<br />
Also don't forget to restore your resolv.conf<br />
mv /etc/resolv.conf.bak /etc/resolv.conf<br />
<br />
==Troubleshooting==<br />
<br />
===Bad config files===<br />
When my server identifier in '''chap-secrets''' didn't match what ''remotename'' was in '''peers/myCon''', I got the following in '''/var/log/daemon.log''':<br />
pppd[13068]: pppd 2.4.4 started by root, uid 0<br />
pppd[13068]: Using interface ppp0<br />
pppd[13068]: Connect: ppp0 <--> /dev/pts/5<br />
pptp[13069]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 15473).<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:911]: Received Call Clear Request.<br />
pptp[13082]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed<br />
pptp[13082]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'<br />
pptp[13082]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed<br />
pptp[13082]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)<br />
pppd[13068]: Modem hangup<br />
pppd[13068]: Connection terminated.<br />
pppd[13068]: Exit.<br />
<br />
===Firewall isn't configured correctly===<br />
If this is the case you should see logs from your firewall blocking things from your ip to my.vpn.server, but in case it helps, here is what it looks like from the pppd logs.<br />
<br />
When the firewall is blocking things<br />
pppd[25387]: pppd 2.4.4 started by root, uid 0<br />
pppd[25387]: Using interface ppp0<br />
pppd[25387]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[25388]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pppd[25387]: LCP: timeout sending Config-Requests<br />
pppd[25387]: Connection terminated.<br />
pppd[25387]: Modem hangup<br />
pppd[25387]: Exit.<br />
<br />
When the firewall is rejecting things<br />
pppd[24971]: pppd 2.4.4 started by root, uid 0<br />
pppd[24971]: Using interface ppp0<br />
pppd[24971]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[24972]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[24974]: anon warn[open_inetsock:pptp_callmgr.c:326]: connect: Connection refused<br />
pptp[24974]: anon fatal[callmgr_main:pptp_callmgr.c:124]: Could not open control connection to 206.169.229.172<br />
pptp[24972]: anon fatal[open_callmgr:pptp.c:439]: Call manager exited with error 256<br />
pppd[24971]: Modem hangup<br />
pppd[24971]: Connection terminated.<br />
pppd[24971]: Exit.</div>Lirhttps://wiki.archlinux.org/index.php?title=PPTP_Client&diff=23150PPTP Client2007-04-15T19:47:19Z<p>Lir: Added info to the troubleshooting section, add the route command for a specific host rather than net, other minor formating/editing</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
From the [http://pptpclient.sourceforge.net pptpclient] website:<br />
<br />
''"PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based Virtual Private Network (VPN) as used by employers and some cable and ADSL internet service providers."''<br />
<br />
While pptpclient is great and lightweight, it isn't exactly the easiest thing to get up and running by itself. There is another program called [http://quozl.linux.org.au/pptp/pptpconfig/pptpconfig.phtml pptpconfig] which does what I describe below and more. Unfortunately it's not in any of the repos and I couldn't get all the php4 stuff that it depends on to work. If/when it makes it into the repositories, use that instead of this.<br />
<br />
Lastly I got almost all of my information from [http://forum.piratpartiet.se/Topic64139-164-1.aspx this] forum post (connecting to Relakks from Arch) and from the pptpclient's pages on [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand configuring by hand] and [http://pptpclient.sourceforge.net/routing.phtml routing]. If my way doesn't work for you try those pages.<br />
<br />
==Install==<br />
The package we need is pptpclient, which is in the [community] repository (uncomment the appropriate lines in /etc/pacman.conf to get it).<br />
<br />
pacman -S pptpclient<br />
<br />
If you don't already have ppp installed, make sure pacman picks it up for you.<br />
<br />
==Configuring and Connecting==<br />
<br />
===Firewall Config===<br />
If your smart/safe you're running a firewall. If thats so, we need to make sure some things are open in order for us to be able to connect. Personally I use [http://www.simonzone.com/software/guarddog guarddog], in which case you just need to go to the Protocol Tab->Internet Zone->Networking and make sure PPTP is checked.<br />
<br />
If you use [http://www.fs-security.com/ firestarter], they supposedly have a workaround for VPNs, but it didn't work for me.<br />
<br />
Lastly if you despise all GUIness and still use iptables directly, check out the [http://forum.piratpartiet.se/Topic64139-164-1.aspx forum] post from above, it uses iptables. For the most part it involves opening protocol 47 and port 1723.<br />
<br />
===PPTP Config===<br />
<br />
All (I think) configuration and running of pptpclient requires root, so first<br />
su<br />
<br />
Then<br />
cd /etc/ppp<br />
<br />
Here you should see the following files:<br />
$ls -l<br />
total 36K<br />
-rw------- 1 root root 78 2006-09-28 02:52 chap-secrets<br />
-rwxr-xr-x 1 root root 75 2006-09-28 02:52 ip-down*<br />
-rwxr-xr-x 1 root root 85 2006-09-28 02:52 ip-up*<br />
-rw-r--r-- 1 root root 14K 2006-09-28 02:52 options<br />
-rw-r--r-- 1 root root 1.7K 2006-12-25 06:06 options.pptp<br />
-rw------- 1 root root 77 2006-09-28 02:52 pap-secrets<br />
<br />
Of those files we only need to muck with '''options.pptp''' and '''chap-secrets'''<br />
<br />
My options.pptp file has these options set<br />
lock<br />
noauth<br />
refuse-eap<br />
refuse-chap<br />
refuse-mschap<br />
nobsdcomp<br />
nodeflate<br />
<br />
In chap-secrets put username, password, a name to identify the server and a * for ip addresses<br />
DOMAIN\\MyUserName TheServer MyPassWord *<br />
<br />
Note: If your pptp server does not require a domain name, leave it and the slashes out.<br />
<br />
Yes you really did just put your password in a file in plain text, so<br />
chmod 600 chap-secrets<br />
If it wasn't already that way.<br />
<br />
Now its time to define our vpn connection:<br />
<br />
First<br />
mkdir peers; cd peers<br />
<br />
Now come up with a name for your connection, I'll call it myCon.<br />
touch myCon<br />
Add the following lines with your editor of choice, making sure that the variables match what you defined in '''chap-secrets''' and '''options.pptp''':<br />
remotename TheServer<br />
ipparam myCon<br />
pty "pptp my.vpn.server --nolaunchpppd"<br />
name DOMAIN\\MyUserName<br />
usepeerdns<br />
require-mppe-128<br />
refuse-eap<br />
noauth<br />
file /etc/ppp/options.pptp<br />
<br />
If you don't need MPPE support, remove the require-mppe-128 line<br />
<br />
With that you should be able to execute the following command<br />
pon myCon<br />
and see something like this in /var/log/daemon.log<br />
pppd[10505]: pppd 2.4.4 started by root, uid 0<br />
pppd[10505]: Using interface ppp0<br />
pppd[10505]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[10506]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 64029).<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF<br />
pptp[10513]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!<br />
pppd[10505]: CHAP authentication succeeded<br />
pppd[10505]: MPPE 128-bit stateless compression enabled<br />
pppd[10505]: Cannot determine ethernet address for proxy ARP<br />
pppd[10505]: local IP address '''<local IP address>'''<br />
pppd[10505]: remote IP address '''<remote IP address>'''<br />
pppd[10505]: primary DNS address '''<primary DNS>'''<br />
pppd[10505]: secondary DNS address '''<secondary DNS>'''<br />
<br />
Issuing<br />
ifconfig ppp0<br />
should show you an inet addr matching '''<local IP address>''' and P-t-P matching '''<remote IP address>'''<br />
<br />
If that didn't work, see below in the Troubleshooting section<br />
<br />
===Network Config===<br />
If the vpn server is also the computer you need to connect to, then you can skip this section. However, if you're like me, the vpn server is just a gateway and what you really want access to is the computers on the other side. There are several different methods of routing traffic through the vpn tunnel, all of which can be found [http://pptpclient.sourceforge.net/routing.phtml here] at the pptpclient's website. For my purposes, I want only traffic destined for the remote network to go through the tunnel, i.e. a Client -> LAN setup.<br />
<br />
For this to work, you need to know what the remote network address start with, i.e. 192.168.10.<br />
So for every subnet (is that the right term?) on the remote network that you want to access, issue this command<br />
route add -net <subnet address>.0 netmask 255.255.255.0 dev ppp0<br />
Which in our example of remote network addresses starting with 192.168.10 means<br />
route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0<br />
<br />
Alternatively if you only have particular hosts on the other side you want to connect to (say 192.168.10.160), this ought to do the trick<br />
route add -host 192.168.10.160 dev ppp0<br />
<br />
Now that we have that set, if pptp found DNS servers for the remote network, you'll want to use/add those to /etc/resolv.conf. Conveniently it stores them in /etc/ppp/resolv.conf, so just take whats there and add it to the beginning of your existing resolv.conf<br />
mv /etc/resolv.conf /etc/resolv.conf.bak<br />
mv /etc/ppp/resolv.conf /etc/resolv.conf<br />
cat /etc/resolv.conf.bak >> /etc/resolv.conf<br />
<br />
With that you should be connected! Try route, ping, and/or traceroute to see the layout of your connections.<br />
<br />
===Connection teardown===<br />
When your done just issue<br />
poff myCon<br />
<br />
Also don't forget to restore your resolv.conf<br />
mv /etc/resolv.conf.bak /etc/resolv.conf<br />
<br />
==Troubleshooting==<br />
<br />
===Bad config files===<br />
When my server identifier in '''chap-secrets''' didn't match what ''remotename'' was in '''peers/myCon''', I got the following in '''/var/log/daemon.log''':<br />
pppd[13068]: pppd 2.4.4 started by root, uid 0<br />
pppd[13068]: Using interface ppp0<br />
pppd[13068]: Connect: ppp0 <--> /dev/pts/5<br />
pptp[13069]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 15473).<br />
pptp[13082]: anon log[ctrlp_disp:pptp_ctrl.c:911]: Received Call Clear Request.<br />
pptp[13082]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed<br />
pptp[13082]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)<br />
pptp[13082]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'<br />
pptp[13082]: anon log[pptp_read_some:pptp_ctrl.c:543]: read returned zero, peer has closed<br />
pptp[13082]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)<br />
pppd[13068]: Modem hangup<br />
pppd[13068]: Connection terminated.<br />
pppd[13068]: Exit.<br />
<br />
===Firewall isn't configured correctly===<br />
If this is the case you should see logs from your firewall blocking things from your ip to my.vpn.server, but in case it helps, here is what it looks like from the pppd logs.<br />
<br />
When the firewall is blocking things<br />
pppd[25387]: pppd 2.4.4 started by root, uid 0<br />
pppd[25387]: Using interface ppp0<br />
pppd[25387]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[25388]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pppd[25387]: LCP: timeout sending Config-Requests<br />
pppd[25387]: Connection terminated.<br />
pppd[25387]: Modem hangup<br />
pppd[25387]: Exit.<br />
<br />
When the firewall is rejecting things<br />
pppd[24971]: pppd 2.4.4 started by root, uid 0<br />
pppd[24971]: Using interface ppp0<br />
pppd[24971]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[24972]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[24974]: anon warn[open_inetsock:pptp_callmgr.c:326]: connect: Connection refused<br />
pptp[24974]: anon fatal[callmgr_main:pptp_callmgr.c:124]: Could not open control connection to 206.169.229.172<br />
pptp[24972]: anon fatal[open_callmgr:pptp.c:439]: Call manager exited with error 256<br />
pppd[24971]: Modem hangup<br />
pppd[24971]: Connection terminated.<br />
pppd[24971]: Exit.</div>Lirhttps://wiki.archlinux.org/index.php?title=PPTP_Client&diff=23128PPTP Client2007-04-15T04:25:56Z<p>Lir: deleted keywords section, the reason search wasn't working was because vpn is a 3 letter word</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
From the [http://pptpclient.sourceforge.net pptpclient] website:<br />
<br />
''"PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based Virtual Private Network (VPN) as used by employers and some cable and ADSL internet service providers."''<br />
<br />
While pptpclient is great and lightweight, it isn't exactly the easiest thing to get up and running by itself. There is another program called [http://quozl.linux.org.au/pptp/pptpconfig/pptpconfig.phtml pptpconfig] which does what I describe below and more. Unfortunately it's not in any of the repos and I couldn't get all the php4 stuff that it depends on to work. If/when it makes it into the repositories, use that instead of this.<br />
<br />
Lastly I got almost all of my information from [http://forum.piratpartiet.se/Topic64139-164-1.aspx this] forum post (connecting to Relakks from Arch) and from the pptpclient's pages on [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand configuring by hand] and [http://pptpclient.sourceforge.net/routing.phtml routing]. If my way doesn't work for you try those pages.<br />
<br />
==Install==<br />
The package we need is pptpclient, which is in the [community] repository (uncomment the appropriate lines in /etc/pacman.conf to get it).<br />
<br />
pacman -S pptpclient<br />
<br />
If you don't already have ppp installed, make sure pacman picks it up for you.<br />
<br />
==Configuring and Connecting==<br />
<br />
===Firewall Config===<br />
If your smart/safe you're running a firewall. If thats so, we need to make sure some things are open in order for us to be able to connect. Personally I use [http://www.simonzone.com/software/guarddog guarddog], in which case you just need to go to the Protocol Tab->Internet Zone->Networking and make sure PPTP is checked.<br />
<br />
If you use [http://www.fs-security.com/ firestarter], they supposedly have a workaround for VPNs, but it didn't work for me.<br />
<br />
Lastly if you despise all GUIness and still use iptables directly, check out the [http://forum.piratpartiet.se/Topic64139-164-1.aspx forum] post from above, it uses iptables.<br />
<br />
===PPTP Config===<br />
<br />
All (I think) configuration and running of pptpclient requires root, so first<br />
su<br />
<br />
Then<br />
cd /etc/ppp<br />
<br />
Here you should see the following files:<br />
$ls -l<br />
total 36K<br />
-rw------- 1 root root 78 2006-09-28 02:52 chap-secrets<br />
-rwxr-xr-x 1 root root 75 2006-09-28 02:52 ip-down*<br />
-rwxr-xr-x 1 root root 85 2006-09-28 02:52 ip-up*<br />
-rw-r--r-- 1 root root 14K 2006-09-28 02:52 options<br />
-rw-r--r-- 1 root root 1.7K 2006-12-25 06:06 options.pptp<br />
-rw------- 1 root root 77 2006-09-28 02:52 pap-secrets<br />
<br />
Of those files we only need to muck with '''options.pptp''' and '''chap-secrets'''<br />
<br />
My options.pptp file has these options set<br />
lock<br />
noauth<br />
refuse-eap<br />
refuse-chap<br />
refuse-mschap<br />
nobsdcomp<br />
nodeflate<br />
<br />
In chap-secrets put username, password, a name to identify the server and a * for ip addresses<br />
DOMAIN\\MyUserName TheServer MyPassWord *<br />
<br />
Note: If your pptp server does not require a domain name, leave it and the slashes out.<br />
<br />
Yes you really did just put your password in a file in plain text, so<br />
chmod 600 chap-secrets<br />
If it wasn't already that way.<br />
<br />
Now its time to define our vpn connection:<br />
<br />
First<br />
mkdir peers; cd peers<br />
<br />
Now come up with a name for your connection, I'll call it myCon.<br />
touch myCon<br />
Add the following lines with your editor of choice, making sure that the variables match what you defined in '''chap-secrets''' and '''options.pptp''':<br />
remotename TheServer<br />
ipparam myCon<br />
pty "pptp my.vpn.server --nolaunchpppd"<br />
name DOMAIN\\MyUserName<br />
usepeerdns<br />
require-mppe-128<br />
refuse-eap<br />
noauth<br />
file /etc/ppp/options.pptp<br />
<br />
If you don't need MPPE support, remove the require-mppe-128 line<br />
<br />
With that you should be able to execute the following command<br />
pon myCon<br />
and see something like this in /var/log/daemon.log<br />
pppd[10505]: pppd 2.4.4 started by root, uid 0<br />
pppd[10505]: Using interface ppp0<br />
pppd[10505]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[10506]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 64029).<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF<br />
pptp[10513]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!<br />
pppd[10505]: CHAP authentication succeeded<br />
pppd[10505]: MPPE 128-bit stateless compression enabled<br />
pppd[10505]: Cannot determine ethernet address for proxy ARP<br />
pppd[10505]: local IP address <local IP address><br />
pppd[10505]: remote IP address <remote IP address><br />
pppd[10505]: primary DNS address <primary DNS><br />
pppd[10505]: secondary DNS address <secondary DNS><br />
<br />
Issuing<br />
ifconfig ppp0<br />
should show you an inet addr matching <local IP address> and P-t-P matching <remote IP address><br />
<br />
If that didn't work, see below in the Troubleshooting section<br />
<br />
===Network Config===<br />
If the vpn server is also the computer you need to connect to, then you can skip this section. However, if you're like me, the vpn server is just a gateway and what you really want access to is the computers on the other side. There are several different methods of routing traffic through the vpn tunnel, all of which can be found [http://pptpclient.sourceforge.net/routing.phtml here] at the pptpclient's website. For my purposes, I want only traffic destined for the remote network to go through the tunnel, i.e. a Client -> LAN setup.<br />
<br />
For this to work, you need to know what the remote network address start with, i.e. 192.168.10.<br />
So for every subnet (is that the right term?) on the remote network that you want to access, issue this command<br />
route add -net <subnet address>.0 netmask 255.255.255.0 dev ppp0<br />
Which in our example of remote network addresses starting with 192.168.10 means<br />
route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0<br />
<br />
Now that we have that set, you'll want to add the DNS servers that pptp found to /etc/resolv.conf. Conveniently it stores them in /etc/ppp/resolv.conf, so just take whats there<br />
and add it to the beginning of your existing resolv.conf<br />
mv /etc/resolv.conf /etc/resolv.conf.bak<br />
mv /etc/ppp/resolv.conf /etc/resolv.conf<br />
cat /etc/resolv.conf.bak >> /etc/resolv.conf<br />
<br />
With that you should be connected! Try route, ping, and/or traceroute to see the layout of your connections.<br />
<br />
===Connection teardown===<br />
When your down just issue<br />
poff myCon<br />
<br />
Also don't forget to restore your resolv.conf<br />
mv /etc/resolv.conf.bak /etc/resolv.conf<br />
==Troubleshooting==<br />
<br />
===Bad config files===</div>Lirhttps://wiki.archlinux.org/index.php?title=PPTP_Client&diff=23127PPTP Client2007-04-15T04:23:31Z<p>Lir: Added some keywords in the hopes of making search better</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
From the [http://pptpclient.sourceforge.net pptpclient] website:<br />
<br />
''"PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based Virtual Private Network (VPN) as used by employers and some cable and ADSL internet service providers."''<br />
<br />
While pptpclient is great and lightweight, it isn't exactly the easiest thing to get up and running by itself. There is another program called [http://quozl.linux.org.au/pptp/pptpconfig/pptpconfig.phtml pptpconfig] which does what I describe below and more. Unfortunately it's not in any of the repos and I couldn't get all the php4 stuff that it depends on to work. If/when it makes it into the repositories, use that instead of this.<br />
<br />
Lastly I got almost all of my information from [http://forum.piratpartiet.se/Topic64139-164-1.aspx this] forum post (connecting to Relakks from Arch) and from the pptpclient's pages on [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand configuring by hand] and [http://pptpclient.sourceforge.net/routing.phtml routing]. If my way doesn't work for you try those pages.<br />
<br />
==Install==<br />
The package we need is pptpclient, which is in the [community] repository (uncomment the appropriate lines in /etc/pacman.conf to get it).<br />
<br />
pacman -S pptpclient<br />
<br />
If you don't already have ppp installed, make sure pacman picks it up for you.<br />
<br />
==Configuring and Connecting==<br />
<br />
===Firewall Config===<br />
If your smart/safe you're running a firewall. If thats so, we need to make sure some things are open in order for us to be able to connect. Personally I use [http://www.simonzone.com/software/guarddog guarddog], in which case you just need to go to the Protocol Tab->Internet Zone->Networking and make sure PPTP is checked.<br />
<br />
If you use [http://www.fs-security.com/ firestarter], they supposedly have a workaround for VPNs, but it didn't work for me.<br />
<br />
Lastly if you despise all GUIness and still use iptables directly, check out the [http://forum.piratpartiet.se/Topic64139-164-1.aspx forum] post from above, it uses iptables.<br />
<br />
===PPTP Config===<br />
<br />
All (I think) configuration and running of pptpclient requires root, so first<br />
su<br />
<br />
Then<br />
cd /etc/ppp<br />
<br />
Here you should see the following files:<br />
$ls -l<br />
total 36K<br />
-rw------- 1 root root 78 2006-09-28 02:52 chap-secrets<br />
-rwxr-xr-x 1 root root 75 2006-09-28 02:52 ip-down*<br />
-rwxr-xr-x 1 root root 85 2006-09-28 02:52 ip-up*<br />
-rw-r--r-- 1 root root 14K 2006-09-28 02:52 options<br />
-rw-r--r-- 1 root root 1.7K 2006-12-25 06:06 options.pptp<br />
-rw------- 1 root root 77 2006-09-28 02:52 pap-secrets<br />
<br />
Of those files we only need to muck with '''options.pptp''' and '''chap-secrets'''<br />
<br />
My options.pptp file has these options set<br />
lock<br />
noauth<br />
refuse-eap<br />
refuse-chap<br />
refuse-mschap<br />
nobsdcomp<br />
nodeflate<br />
<br />
In chap-secrets put username, password, a name to identify the server and a * for ip addresses<br />
DOMAIN\\MyUserName TheServer MyPassWord *<br />
<br />
Note: If your pptp server does not require a domain name, leave it and the slashes out.<br />
<br />
Yes you really did just put your password in a file in plain text, so<br />
chmod 600 chap-secrets<br />
If it wasn't already that way.<br />
<br />
Now its time to define our vpn connection:<br />
<br />
First<br />
mkdir peers; cd peers<br />
<br />
Now come up with a name for your connection, I'll call it myCon.<br />
touch myCon<br />
Add the following lines with your editor of choice, making sure that the variables match what you defined in '''chap-secrets''' and '''options.pptp''':<br />
remotename TheServer<br />
ipparam myCon<br />
pty "pptp my.vpn.server --nolaunchpppd"<br />
name DOMAIN\\MyUserName<br />
usepeerdns<br />
require-mppe-128<br />
refuse-eap<br />
noauth<br />
file /etc/ppp/options.pptp<br />
<br />
If you don't need MPPE support, remove the require-mppe-128 line<br />
<br />
With that you should be able to execute the following command<br />
pon myCon<br />
and see something like this in /var/log/daemon.log<br />
pppd[10505]: pppd 2.4.4 started by root, uid 0<br />
pppd[10505]: Using interface ppp0<br />
pppd[10505]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[10506]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 64029).<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF<br />
pptp[10513]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!<br />
pppd[10505]: CHAP authentication succeeded<br />
pppd[10505]: MPPE 128-bit stateless compression enabled<br />
pppd[10505]: Cannot determine ethernet address for proxy ARP<br />
pppd[10505]: local IP address <local IP address><br />
pppd[10505]: remote IP address <remote IP address><br />
pppd[10505]: primary DNS address <primary DNS><br />
pppd[10505]: secondary DNS address <secondary DNS><br />
<br />
Issuing<br />
ifconfig ppp0<br />
should show you an inet addr matching <local IP address> and P-t-P matching <remote IP address><br />
<br />
If that didn't work, see below in the Troubleshooting section<br />
<br />
===Network Config===<br />
If the vpn server is also the computer you need to connect to, then you can skip this section. However, if you're like me, the vpn server is just a gateway and what you really want access to is the computers on the other side. There are several different methods of routing traffic through the vpn tunnel, all of which can be found [http://pptpclient.sourceforge.net/routing.phtml here] at the pptpclient's website. For my purposes, I want only traffic destined for the remote network to go through the tunnel, i.e. a Client -> LAN setup.<br />
<br />
For this to work, you need to know what the remote network address start with, i.e. 192.168.10.<br />
So for every subnet (is that the right term?) on the remote network that you want to access, issue this command<br />
route add -net <subnet address>.0 netmask 255.255.255.0 dev ppp0<br />
Which in our example of remote network addresses starting with 192.168.10 means<br />
route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0<br />
<br />
Now that we have that set, you'll want to add the DNS servers that pptp found to /etc/resolv.conf. Conveniently it stores them in /etc/ppp/resolv.conf, so just take whats there<br />
and add it to the beginning of your existing resolv.conf<br />
mv /etc/resolv.conf /etc/resolv.conf.bak<br />
mv /etc/ppp/resolv.conf /etc/resolv.conf<br />
cat /etc/resolv.conf.bak >> /etc/resolv.conf<br />
<br />
With that you should be connected! Try route, ping, and/or traceroute to see the layout of your connections.<br />
<br />
===Connection teardown===<br />
When your down just issue<br />
poff myCon<br />
<br />
Also don't forget to restore your resolv.conf<br />
mv /etc/resolv.conf.bak /etc/resolv.conf<br />
==Troubleshooting==<br />
<br />
===Bad config files===<br />
<br />
==Key words==<br />
A list of key words to make sure search can find this page.<br />
VPN, vpn, pptpclient, pptpconfig</div>Lirhttps://wiki.archlinux.org/index.php?title=PPTP_Client&diff=23126PPTP Client2007-04-15T04:18:53Z<p>Lir: initial upload, Troubleshooting needs to be fleshed out still</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
From the [http://pptpclient.sourceforge.net pptpclient] website:<br />
<br />
''"PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP. Allows connection to a PPTP based Virtual Private Network (VPN) as used by employers and some cable and ADSL internet service providers."''<br />
<br />
While pptpclient is great and lightweight, it isn't exactly the easiest thing to get up and running by itself. There is another program called [http://quozl.linux.org.au/pptp/pptpconfig/pptpconfig.phtml pptpconfig] which does what I describe below and more. Unfortunately it's not in any of the repos and I couldn't get all the php4 stuff that it depends on to work. If/when it makes it into the repositories, use that instead of this.<br />
<br />
Lastly I got almost all of my information from [http://forum.piratpartiet.se/Topic64139-164-1.aspx this] forum post (connecting to Relakks from Arch) and from the pptpclient's pages on [http://pptpclient.sourceforge.net/howto-debian.phtml#configure_by_hand configuring by hand] and [http://pptpclient.sourceforge.net/routing.phtml routing]. If my way doesn't work for you try those pages.<br />
<br />
==Install==<br />
The package we need is pptpclient, which is in the [community] repository (uncomment the appropriate lines in /etc/pacman.conf to get it).<br />
<br />
pacman -S pptpclient<br />
<br />
If you don't already have ppp installed, make sure pacman picks it up for you.<br />
<br />
==Configuring and Connecting==<br />
<br />
===Firewall Config===<br />
If your smart/safe you're running a firewall. If thats so, we need to make sure some things are open in order for us to be able to connect. Personally I use [http://www.simonzone.com/software/guarddog guarddog], in which case you just need to go to the Protocol Tab->Internet Zone->Networking and make sure PPTP is checked.<br />
<br />
If you use [http://www.fs-security.com/ firestarter], they supposedly have a workaround for VPNs, but it didn't work for me.<br />
<br />
Lastly if you despise all GUIness and still use iptables directly, check out the [http://forum.piratpartiet.se/Topic64139-164-1.aspx forum] post from above, it uses iptables.<br />
<br />
===PPTP Config===<br />
<br />
All (I think) configuration and running of pptpclient requires root, so first<br />
su<br />
<br />
Then<br />
cd /etc/ppp<br />
<br />
Here you should see the following files:<br />
$ls -l<br />
total 36K<br />
-rw------- 1 root root 78 2006-09-28 02:52 chap-secrets<br />
-rwxr-xr-x 1 root root 75 2006-09-28 02:52 ip-down*<br />
-rwxr-xr-x 1 root root 85 2006-09-28 02:52 ip-up*<br />
-rw-r--r-- 1 root root 14K 2006-09-28 02:52 options<br />
-rw-r--r-- 1 root root 1.7K 2006-12-25 06:06 options.pptp<br />
-rw------- 1 root root 77 2006-09-28 02:52 pap-secrets<br />
<br />
Of those files we only need to muck with '''options.pptp''' and '''chap-secrets'''<br />
<br />
My options.pptp file has these options set<br />
lock<br />
noauth<br />
refuse-eap<br />
refuse-chap<br />
refuse-mschap<br />
nobsdcomp<br />
nodeflate<br />
<br />
In chap-secrets put username, password, a name to identify the server and a * for ip addresses<br />
DOMAIN\\MyUserName TheServer MyPassWord *<br />
<br />
Note: If your pptp server does not require a domain name, leave it and the slashes out.<br />
<br />
Yes you really did just put your password in a file in plain text, so<br />
chmod 600 chap-secrets<br />
If it wasn't already that way.<br />
<br />
Now its time to define our vpn connection:<br />
<br />
First<br />
mkdir peers; cd peers<br />
<br />
Now come up with a name for your connection, I'll call it myCon.<br />
touch myCon<br />
Add the following lines with your editor of choice, making sure that the variables match what you defined in '''chap-secrets''' and '''options.pptp''':<br />
remotename TheServer<br />
ipparam myCon<br />
pty "pptp my.vpn.server --nolaunchpppd"<br />
name DOMAIN\\MyUserName<br />
usepeerdns<br />
require-mppe-128<br />
refuse-eap<br />
noauth<br />
file /etc/ppp/options.pptp<br />
<br />
If you don't need MPPE support, remove the require-mppe-128 line<br />
<br />
With that you should be able to execute the following command<br />
pon myCon<br />
and see something like this in /var/log/daemon.log<br />
pppd[10505]: pppd 2.4.4 started by root, uid 0<br />
pppd[10505]: Using interface ppp0<br />
pppd[10505]: Connect: ppp0 <--> /dev/pts/7<br />
pptp[10506]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.<br />
pptp[10513]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 64029).<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0<br />
pptp[10513]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF<br />
pptp[10513]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!<br />
pppd[10505]: CHAP authentication succeeded<br />
pppd[10505]: MPPE 128-bit stateless compression enabled<br />
pppd[10505]: Cannot determine ethernet address for proxy ARP<br />
pppd[10505]: local IP address <local IP address><br />
pppd[10505]: remote IP address <remote IP address><br />
pppd[10505]: primary DNS address <primary DNS><br />
pppd[10505]: secondary DNS address <secondary DNS><br />
<br />
Issuing<br />
ifconfig ppp0<br />
should show you an inet addr matching <local IP address> and P-t-P matching <remote IP address><br />
<br />
If that didn't work, see below in the Troubleshooting section<br />
<br />
===Network Config===<br />
If the vpn server is also the computer you need to connect to, then you can skip this section. However, if you're like me, the vpn server is just a gateway and what you really want access to is the computers on the other side. There are several different methods of routing traffic through the vpn tunnel, all of which can be found [http://pptpclient.sourceforge.net/routing.phtml here] at the pptpclient's website. For my purposes, I want only traffic destined for the remote network to go through the tunnel, i.e. a Client -> LAN setup.<br />
<br />
For this to work, you need to know what the remote network address start with, i.e. 192.168.10.<br />
So for every subnet (is that the right term?) on the remote network that you want to access, issue this command<br />
route add -net <subnet address>.0 netmask 255.255.255.0 dev ppp0<br />
Which in our example of remote network addresses starting with 192.168.10 means<br />
route add -net 192.168.10.0 netmask 255.255.255.0 dev ppp0<br />
<br />
Now that we have that set, you'll want to add the DNS servers that pptp found to /etc/resolv.conf. Conveniently it stores them in /etc/ppp/resolv.conf, so just take whats there<br />
and add it to the beginning of your existing resolv.conf<br />
mv /etc/resolv.conf /etc/resolv.conf.bak<br />
mv /etc/ppp/resolv.conf /etc/resolv.conf<br />
cat /etc/resolv.conf.bak >> /etc/resolv.conf<br />
<br />
With that you should be connected! Try route, ping, and/or traceroute to see the layout of your connections.<br />
<br />
===Connection teardown===<br />
When your down just issue<br />
poff myCon<br />
<br />
Also don't forget to restore your resolv.conf<br />
mv /etc/resolv.conf.bak /etc/resolv.conf<br />
==Troubleshooting==<br />
<br />
===Bad config files===</div>Lir