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 email@example.com 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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide