Create a Linux VPN for a Nokia E61 with Openswan
Listing 6. The Openswan Configuration File to Allow the e61 to Connect
conn e61 # Key exchange ike=aes256-sha1-modp1536 # Data exchange esp=aes256-sha1 # Authentication method PSK authby=secret auto=add keyingtries=3 # Modeconfig setting modecfgpull=yes pfs=no rekey=no firstname.lastname@example.org left=%defaultroute leftsubnet=192.168.0.1/0 leftrsasigkey=none leftmodecfgserver=yes leftxauthserver=yes rightrsasigkey=none right=%any rightxauthclient=yes rightmodecfgclient=yes rightsourceip=192.168.6.252 rightsubnet=192.168.6.252/32
The same private key that was specified in the KEY field of the VPN policy above should be placed into the /etc/ipsec.d/e61.secrets file, shown in Listing 7.
Listing 7. Private Key for the VPN
: PSK "foo"
Finally, the USE_XAUTH option in the VPN policy needs Openswan to have a user name and password lookup for this connection. The Openswan README.XAUTH file recommends against using PAM for this. The password file can be created using htpasswd from the Apache package, as shown in Listing 8. A sample of the passwd file is shown in Listing 9.
Listing 8. Making the initial passwd file with htpasswd. The -c option creates the passwd file if it doesn't exist or replaces it if it does. Use the -c only once. Make sure your umask is set first, as some distributions have lax defaults.
umask 0027 htpasswd -b -c passwd ben your-password-here htpasswd -b passwd chidori her-password-here
Listing 9. The XAUTH user name and password lookup file—the password itself is linuxjournal.
Trying to debug packet logs on the machine that is running as the IPSec server can be a little difficult. Packets that arrive encrypted are decrypted and put onto the network interface to appear as though they have arrived without any encryption. Part of a packet log is shown in Listing 10, showing a packet that appears to have come from the e61's IP address without any encryption. The log is further complicated because the WEP setup gives the e61 the same IP address as the VPN does. For traffic from the Internet, the top two packets will have a random IP address instead of the e61. To get a clearer picture of the packet data, connecting the e61 through a laptop to vserv allows proper packet snooping on the laptop. The imaps packet in Listing 10 will not be seen by the laptop—only a bidirectional stream of ESP packets.
Listing 10. Partial Traffic Log for eth0 on the IPSec Server
15:58:07.n IP ipsecserv > e61: ESP(spi=...), len... 15:58:07.n IP e61 > ipsecserv: ESP(spi=...), len... 15:58:07.n IP e61.57397 > ipsecserv.imaps: . ack...
The iptables commands shown in Listing 11 provide a base to allow the e61 to connect to the IPSec server from the Internet.
The packet filtering rules are quite simple. Allow Internet Security Association and Key Management Protocol (ISAKMP) packets to enter and exit the server and allow any Encapsulating Security Payload (ESP) traffic, assuming that the IPSec server will be responsible for sorting out fraudulent packets. VPN traffic itself is sent through the ESP packets; the ISAKMP is used at the VPN session startup, and those packets also are logged, so that the syslog monitor can alert you of strange connection attempts or door knocking.
Because the non-encrypted traffic is placed on the network interface when Openswan is done with it, the rules have to allow e-mail and squid connections from the e61 IP address. I need to have these rules here because normally no connections can be initiated on the network interface connected to the Internet. If you filter outward traffic too, you have to allow packets from these services to the e61 to be sent to the Internet network interface (to be encrypted by Openswan before being sent to the proper Internet address).
The firewall rules are designed to be used with a default policy of drop. The logging commands can be added or removed to help debugging by searching for the relevant log prefix in /var/log/messages to see which packets are moving around before the firewall may drop them. The script shown in Listing 12 undoes what was done by Listing 11 to disable remote access again.
You also might want to consider using a Single Packet Authorization (SPA) client on the e61 and setting up the server to open the firewall ISAKMP port only after a successful SPA. See Michael Rash's “Single Packet Authorization” article in the April 2007 issue of Linux Journal for more information on SPA.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development