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.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Many Paths to a Solution
- Nativ Disc
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
- Identity: Our Last Stand
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