Create a Linux VPN for a Nokia E61 with Openswan
August 1st, 2007 by Ben Martin in
A virtual private network (VPN) allows you to send traffic across an untrusted network without exposing the content of that traffic. Conceptually, this is done by creating a pipe between two hosts where all network traffic transferred is protected by cryptography.
The example in this article is connecting a Nokia E61 device to a home network through a VPN over the Internet. The Nokia E61 is a smartphone that has Wi-Fi support as well as a VPN client. A similar procedure might work for other phone models using the same VPN client software, though the hardware was not on hand to test this. The Linux side was run on Fedora Linux 6; other distros might have slight path and package name changes.
The VPN support on the Nokia E61 uses IP security (IPSec). Openswan is an IPSec server that is configured on the Linux machine to provide the other end of the virtual network.
I should mention one caveat up front: I've been unable to configure the VPN client on the phone to connect to a server that does not have a static IP address.
To keep notation simple, I refer to the phone as e61 and the server running Openswan as vserv. The IP address of the e61 is irrelevant to the article, as you likely will be moving around to different Wi-Fi hotspots with the phone. When a VPN is set up, the e61 gets another IP address, which the e61 refers to as the virtual IP address. Once the VPN is set up, this virtual IP address is where all traffic to and from the e61 is sent. For this article, I use a 192.168.x.x IP address for this e61 VPN address. As the non-VPN IP address of the e61 is mostly irrelevant, unless I explicitly mention otherwise, the e61 IP address will be this non-Internet-routable IP address.
Unlike the other network settings on the phone, you cannot configure the VPN manually using the e61 itself. You have to create a package containing all the information about the VPN and install that package on the phone. These packages are the SIS files. A VPN SIS file also must be digitally signed before the e61 will allow you to install it. Signed SIS files normally have an sisx extension. The most difficult part of setting up the e61 to talk to Openswan is in creating the sisx file to install on the phone.
The SIS file still must be digitally signed, even if you have set the configuration parameter Software installation to All in App Mgr/Options/Settings.
The sisx package is composed of three files. Two of these are boilerplate-type package metadata (the VPN.pin and VPN.pkg files).
Getting the boilerplate files out of the way, the VPN.pin file is mostly uninteresting and is shown in Listing 1, and the VPN.pkg file is shown in Listing 2. Both files should work fine without any changes. Note that the paths shown in Listing 2 are to be interpreted relative to the phone itself and should not be changed.
The VPN.pol file shown in Listing 3 defines the meat of how to connect to the VPN and what key to use for authentication.
Some things need to be changed in VPN.pol before using it. The main changes are the static IP address of the Openswan server (192.168.0.1) and the password to use to connect. The server's IP address appears more than once in the configuration file. To avoid any confusion about virtual IP addresses mentioned above, this IP address is the one from which vserv can be reached publicly from the Internet. The password is in the last field: the KEY. The number is the string length of the key that follows after a space.
If USE_XAUTH is set to true, when establishing the VPN connection the e61 prompts you for a user name and password with which to connect. This provides an additional level of security. In the event that the e61 is stolen, the thief will have to know your user name and password in order to access your VPN.
Openswan can use either PAM or a separate config file to test the user name and password on the server (more on this later).
Three Windows executables are used to create a signed SIS file. DevCertRequest.exe is used once to create a certificate to sign the SIS file; makesis.exe and signsis.exe then are used to create the package and sign it. The last two commands are part of the S60 SDK available for free from Nokia's Web site. All of these Windows executables can be run in Wine, though you need to have MFC42.DLL and MSVCP60.dll available to run DevCertRequest.
It's best to get the certificate in order to begin; register for free at symbiansigned.com, and download the DevCertRequest executable. Registration requires your name, e-mail address, organization, address and phone number.
DevCertRequest is used only to input a few settings and generate a key and a certificate sign request (.csr file). Unfortunately, the DevCertRequest executable is actually an installer, so you have to install this application and then execute it (Figure 1). For this article, DevCertRequest_30_10_2006_v2.0.exe was used.
Figure 1. Installing the DevCertRequest Application in Wine
After all the pain of installing DevCertRequest, using it consists of five simple steps, and it isn't needed again afterward. You give the location for the new csr file (monkeyiq.csr); the location for your new private key (monkeyiq-private-key.key) and a password for it; your country, state and company; the IMEI of your phone (as DevCertRequest tells you, keying *#06# on the phone will show it) and which capabilities you want for your certificate; and a confirmation that the information is correct.
To create the certificate itself, you have to return to symbiansigned.com and upload the csr file. First log in, and then select the My Symbian Signed tab. In the side panel, the Developer Certificates option has the Request sub-option. At the bottom of this page, you can upload the csr file (Figure 2). The next page allows you to download your certificate (Figure 3).
Figure 2. Uploading the Certificate Request
Figure 3. Download the Certificate Needed to Sign SIS Files
The makesis.exe and signsis.exe files can be extracted from the “S60 Platform for Symbian OS” SDK, as shown in Listing 4.
With the certificate (monkeyiq.csr) file, you now can roll the sisx file with the code shown in Listing 5. Make sure the three files that make up the package use the carriage return plus new line combination to terminate each line instead of the standard Linux new line only; see unix2dos(1). These three files are the pol, pkg and pin files shown in Listings 3, 2 and 1, respectively.
Any method can be used to transfer the sisx file to the e61. I've used Bluetooth push, in which case it can be installed on the e61 directly from the incoming messages list. As this sisx file contains a password, it is better to transfer it to the phone using a wired method.
Using a mini-SD card in the e61 and plugging in the USB connection cable to the phone and a Linux machine likely will bring up a file browser for the mounted SD card on the e61. Copy the file to a convenient location, such as Documents/vpn on the e61, and eject or unmount the SD card to force a disk sync before removing the cable (Figure 4).
Figure 4. Copy the VPN file to a subdirectory of Documents on the memory card.
Once the sisx file is copied to the e61 memory card, the Menu/Office/File Manager on the e61 lets you navigate to the VPN directory on your memory card. When you click the joystick on the VPN sisx file, the phone asks if you want to install it. Right after clicking on the sisx file, you should see something like that shown in Figure 5. After inspecting some metadata, you'll see the ominous-looking screen shown in Figure 6. As you have just created the package from a bunch of text files and you've looked over them for nasties, this security warning shouldn't really be much of a problem to ignore.
Figure 5. Starting the VPN Policy sisx Install
Figure 6. As we made the package, we trust that this is not really a security issue.
The VPN sisx file can be prepared for use by going to Menu→Tools→Settings→Connection→VPN. Select VPN access points and Options→New access point. Set the connection name to something memorable, and set the policy name and access point. A convenient access point is EasyWLAN. You also might want to set the proxy server address and port. It's nice to be able to surf the Internet and get to Intranet servers over the VPN. Directing all Web traffic to the VPN has the added bonus that the Wi-Fi hotspot you are using isn't able to record the Web sites you visit. The final stage is shown in Figure 7.
If you are already using WEP to connect locally and want to continue to do so and be able to test the VPN locally, define another VPN access point, setting its Internet access point to your WEP access point. Having the second VPN config means you won't be prompted for the WEP key when connecting locally. There is little gain in doing VPN over WEP except for not having to loosen the security on your wireless access point.
Figure 7. The final setup—give a name and Wi-Fi access point to the policy, and maybe set a proxy server too.
Packages are shown at rpmseek.com for Fedora, Mandriva and SUSE Linux. Debian.org also lists an Openswan package. On a Fedora Linux machine, Openswan can be installed simply by using yum install openswan. As mentioned previously, I used a Fedora Linux machine for this article; other distributions may have subtle differences.
The two main areas for configuring Openswan are the /etc/ipsec.conf file and a handful of files in /etc/ipsec.d. The main config file can be left as it stands. A few settings that might be of interest are forwardcontrol=yes to turn packet forwarding on and off when Openswan is started and stopped. The other interesting option is the interfaces setting, allowing you to control which IPSec interface is bound to which network interface—for example, interfaces="%defaultroute ipsec2=eth1 ipsec3=ppp1". If no interfaces parameter is specified, Openswan works on the network interface that has the default route. For Internet VPN connections, this is fine.
Another parameter that might come in handy in the ipsec.conf file is setting plutodebug=all, and reading your syslog files if you can't connect.
To describe a connection to Openswan for the e61, create a config file /etc/ipsec.d/e61.conf, as shown in Listing 6. The pfs setting is for perfect forward security. Unfortunately, I've had no luck using this option and connecting from the e61. As shown in the VPN config for the e61, I've listed the left value as %defaultroute, so Openswan will substitute the IP address of the network interface to which the default route points. As the default route is to the Internet, this works well. I've also used the DNS name of the vserv as leftid; this should be optional. You need to substitute your DNS name for monkeyiq.example.org in the config file. The rightsourceip is the virtual IP address that the e61 will use when talking over the VPN. For the firewall rules (shown later), I have assigned the hostname for the e61 to 192.168.6.252 in /etc/hosts.
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.
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.
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.
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.
One more complication exists for using some of the publicly available Wi-Fi hotspots. Depending on where on the globe you are, many of these hotspots follow the pattern that when you try to open a Web site, they redirect you to their Wi-Fi login page, you authenticate to them, and then you can use the Internet. If you simply open up a VPN access point on the e61 that is set to use the EasyWLAN as its Internet access point, things will not work. The e61 will start the Wi-Fi connection and immediately try to send data to set up a VPN connection. As you have to authenticate with the Wi-Fi hotspot before this, it will let traffic through, but then things will come crashing down.
A way to get around this is to open the Web browser and directly connect just using EasyWLAN without any VPN whatsoever. Once you have authenticated to the hotspot, leave the browser running and use the menu key to get back to the main menu, and then open the e-mail client. For the access point this time, use the VPN that has EasyWLAN set as its Internet access point. The existing Wi-Fi connection is reused, and the VPN is layered on top. To get secure Web browsing, you can then leave the e-mail program by holding the menu key and going back to the browser. Exit the browser, and the still-running e-mail program holds the VPN open. Start the browser again, and select the VPN as your access point.
Of course, if the Wi-Fi network you are connecting to allows connections without this preamble, opening any application that wants a data connection should allow you to select the new VPN as your access point. Also, if the Wi-Fi hotspot remembers your MAC address and allows reconnection without explicitly having to log in each time, you can start the VPN directly on subsequent connections.
Once the VPN has connected to vserv, the e61 prompts you for the user name and password to use for XAUTH verification (Figure 8).
After XAUTH verification, you should be able to use the VPN without noticing it. In this case, I can browse the Internet using my LANs proxy server to fetch the data (Figure 9).
Figure 8. Once the VPN is set up, XAUTH user name and password verification starts.
Figure 9. Success! We can read Linux Journal through the VPN link.
Being able to use a DNS name in the e61 VPN policy would be wonderful for folks who don't have cheap access to static IP addresses. I'm still investigating how to connect using public key cryptography instead of the preshared key as shown in this article. For connecting a single e61 to the network, using a large enough preshared key should still be quite secure.
The information in the article comes with no guarantee of being correct, secure or suitable for anything; use it at your own risk and discretion.
Special Magazine Offer -- Free Gift with Subscription
Receive a free digital copy of Linux Journal's System Administration Special Edition as well as instant online access to current and past issues. CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Delicious
Digg
StumbleUpon
Reddit
Facebook
Post to TwitterSubscribe now!
The Latest
Newsletter
Tech Tip Videos
Recently Popular
From the Magazine
December 2009, #188
If last month's Infrastrucuture issue was too "big" for you then try on this month's Embedded issue. Find out how to use Player for programming mobile robots, build a humidity controller for your root cellar, find out how to reduce the boot time of your embedded system, and if you're new to embedded systems find out the basics that go into one. You can also read about the Beagle Board, the Mesh Potato and a spate of other interestingly named items. And along with our regular columns don't miss our new monthly column: Economy Size Geek.
To complicated, I have installed SymVPN instead.
On February 28th, 2009 Anonymous (not verified) says:
To complicated.
That is why I am using SymVPN.
It is not IPSec, and it is not Openswan, as it is PPTP based VPN. However it is worth it - 5 parameters to enter and it works in 30 sec.
No headache with policy file.
No headache with signing.
Yes, it is probably less secure then Openswan and IPSec, but at least it is working, but Nokia Mobile VPN it is the dead end road for 98% of all Nokia phone users. Sounds promising in the theory, but nothing works in practice.
Unfortunately on FP2 S60v3
On April 6th, 2009 morphix (not verified) says:
Unfortunately on FP2 S60v3 devices, SymVPN doesn't work properly, pretty much not at all due to the "Destinations" access point settings available in FP2 only devices, that counts my Nokia N96 out :(
Thanks for really good
On February 17th, 2009 Anonymous (not verified) says:
Thanks for really good article!
Now days everything can be made more simple way with appearance of SymVPN from www.telexy.com
SymVPN is PPTP VPN client for Series 60 3rd phones.
Installation instruction in German WIKI / Update
On July 21st, 2008 FreshSmith (not verified) says:
== '''NOKIA VPN Client mit Open Source strongSWAN''' ==
'''Voraussetzungen:'''
# StrongSwan mit öffentlicher IP Adresse
# Symbian makesis.exe zum Serstellen von SIS Installationspaketen
# Konfigurationsfiles für SIS VPN Paket
'''Konfiguration:'''
'''''StrongSWAN'''''
StrongSwan ipsec.conf anpassen und NAT Traversat (NAT-T) aktivieren. Dies ist wichtig, da viele Mobilfunkprovider intern noch einmal natten. Die zugeteilte IP Adresse am Telefon entspricht nicht der IP Adresse, die bei einem Verbingsaufbau beim StrongSWAN ankommt.
''
config setup
interfaces="ipsec0=eth0"
klipsdebug=all
plutodebug=none
nat_traversal=yes
include /etc/ipsec.d/ipsec-conn-e61-mrobichon.fas
include /etc/ipsec.d/ipsec-conn-e61-njaixen.fas
''
Danach müssen in der ipsec.secerts der PSK Key hinterlegt werden:
'': PSK "xxxxxxxxxxxxxxxxxxxx"''
Falls XATH benutzt werden soll, hier wird bei der Initialisierung der Verbindung Username und Passwort abgefragt, dann sollte hier auch noch der entsprechende Eintrag mit Credentials hionterlagt werden:
'': XAUTH User "password"''
Nun kommen wir zu den Verbindungen. Hier wird es interessant. Im oberen Beispiel werden zwei Verbindungen in der ipsec.conf includiert. Die Konfiguration könnte so aussehen:
''
conn e61-mrobichon
# Key exchange
ike=aes256-sha1-modp1536
# Data exchange
esp=aes256-sha1
# Authentication method PSK
authby=secret
#authby=xauthpsk
auto=start
keyingtries=3
# Modeconfig setting
modeconfig=pull
pfs=no
rekey=no
# LEFT: serverseite
#leftid=0.0.0.0/0
left=%defaultroute
#Internes Netz, falls alles geroutet werden soll dann 0.0.0.0
leftsubnet=172.16.25.0/24
#leftsubnet=0.0.0.0/0
leftrsasigkey=none
# leftmodecfgserver=yes
#Falls XAUTH verwendet werden soll, dann diesen Eintrag aktivieren
# leftxauthserver=yes
xauth=server
# RIGHT: clientseite
rightrsasigkey=none
right=%any
# Right ID ist absolut wichtig, wenn meherere Verbindungen von
# unterschidlichen Clients aufgebaut werden sollen = FQDN (binär)
rightid=@#4d6f62696c6547726f7570
# rightxauthclient=yes
# rightmodecfgclient=yes
# virtuelle IP Adresse des IPSEC Tunnels pro Client und Connection
rightsourceip=192.168.44.1
rightsubnet=192.168.44.1/32
''
Parameter, die editiert werden müssen:
* leftsubnet=172.16.25.0/24 -- internes Netz
* rightid=@#4d6f62696c6547726f7570 -- in der Nokia pol (später) representiert die ID die FQDN und wird hier binär ausgedrückt. Am besten man lässt das Feld offen und probiert erst mal aus, welche ID übermittelt wird. Die kann man sehen, wenn man eine Verbindung aufbaut und in die messages reinschaut:
"e61-njaixen"[6] 92.116.229.249 #9: Peer ID is ID_KEY_ID: '0x4d6f62696c6547726f7570'
das 0x wird durch @# ersetzt
* rightsourceip=192.168.44.1 -- virtuelle IP Adresse, die dem Client zugeordnet wird dasselbe mit dem rightsubnet (virtuelle Client IP + Subnetz localhost = 32)
'''''NOKIA'''''
'''Konfigurationsdateien:'''
Die Konfiguration besteht aus drei Dateien: pin, pkg, pol. Die Dateien müssen denselben Dateinamen haben. pin und pkg brauchen nicht editiert zu werden.
Als Beipiel hier die Konfigurationen:
VPN-policy-preshared-Cisco.pin
''
[POLICYNAME]
VPN-Policy
[POLICYDESCRIPTION]
VPN-Policy for Nokia Mobile VPN Client v3.0.
[POLICYVERSION]
1.1
[ISSUERNAME]
Do not edit
[CONTACTINFO]
Do not edit
''
VPN-policy-preshared-Cisco.pkg
''
;
; A VPN POLICY PACKAGE
;
; LANGUAGES
; - None (English only by default)
; INSTALLATION HEADER
; - Only one component name is needed to support English only
; - UID is the UID of the VPN Policy Installer application
#{"VPN-Policy"},(0x1000597E), 1, 0, 0, TYPE=SA
;Localised Vendor name
%{"pip-EN"}
;Unique Vendor name
:"pip"
; LIST OF FILES
; Policy file
"VPN-policy-preshared-Cisco.pol"-"C:\System\Data\Security\Install\VPN-policy-preshared-Cisco.pol"
; Policy-information file
; - NOTE: The policy-information file MUST be the last file in this list!
; - FM (FILEMIME) passes the file to the respective MIME handler
; (in this case, the VPN Policy Installer application).
"VPN-policy-preshared-Cisco.pin"-"C:\System\Data\Security\Install\VPN-policy- preshared-Cisco.pin",
FM, "application/x-ipsec-policy-info"
; REQUIRED FILES
; - The VPN Policy Installer application
(0x1000597E), 1, 0, 0, {"VPN Policy Installer"}
; - S60 3rd Edition ID
[0x101F7961], 0, 0, 0, {"S60ProductID"}
''
VPN-policy-preshared-Cisco.pol
''
SECURITY_FILE_VERSION: 3
[INFO]
VPN
[POLICY]
sa ipsec_1 = {
esp
encrypt_alg 12
max_encrypt_bits 256
auth_alg 3
identity_remote 172.16.25.0/24 #internes Netz
src_specific
hard_lifetime_bytes 0
hard_lifetime_addtime 3600
hard_lifetime_usetime 3600
soft_lifetime_bytes 0
soft_lifetime_addtime 3600
soft_lifetime_usetime 3600
}
remote 172.16.25.0 255.255.255.0 = { ipsec_1(xxx.xxx.xxx.xxx) } #internes Netz {StrongSWAN IP}
inbound = { }
outbound = { }
[IKE]
ADDR: xxx.xxx.xxx.xxx 255.255.255.255 #StrongSWAN IP
MODE: MAIN
SEND_NOTIFICATION: TRUE
ID_TYPE: 11
FQDN: MobileGrou2 #rightid (binär) in StrongSWAN Konfiguration
GROUP_DESCRIPTION_II: MODP_1536
USE_COMMIT: FALSE
IPSEC_EXPIRE: FALSE
SEND_CERT: FALSE
INITIAL_CONTACT: FALSE
RESPONDER_LIFETIME: TRUE
REPLAY_STATUS: TRUE
USE_INTERNAL_ADDR: FALSE
USE_NAT_PROBE: FALSE
ESP_UDP_PORT: 0
NAT_KEEPALIVE: 60
USE_XAUTH: FALSE #Falls XAUTH benutzt werden soll
USE_MODE_CFG: TRUE
REKEYING_THRESHOLD: 90
PROPOSALS: 1
ENC_ALG: AES256-CBC
AUTH_METHOD: PRE-SHARED
HASH_ALG: SHA1
GROUP_DESCRIPTION: MODP_1536
GROUP_TYPE: DEFAULT
LIFETIME_KBYTES: 0
LIFETIME_SECONDS: 28800
PRF: NONE
PRESHARED_KEYS:
FORMAT: STRING_FORMAT
KEY: 20 xxxxxxxxxxxxxxxxxxxx #Secret in ipsec.secrets
''
'''Installtion'''
Erstellung der SIS Datei mit "makesis VPN-policy-preshared-Cisco.pkg" die SIS Datei wird erstellt. Danach einloggen auf [[https://www.symbiansigned.com/app/page]]
Hier auf den Link "Open Signed Online". Auf dieser Seite muss nun die IMEI des Mobiltelefons eingegeben werden, auf dem die Policy geladen werden soll *#06#. Mailadresse, an die der Link zur Apllikation gesendet wird und natürlich upload der SIS Datei, welche signiert werden soll. Man erhält eine Verifizierungsmail und kurz danach den Link zum Download der signierten Applikation.
Die Aplikation installiert man dann via PC Suite oder ähnliches direkt auf dem Mobiltelefon. Sollten IMEI nicht zusammen passen, dann muss das ganze nochmal erstellt werden. Nun geht man nach
System --> Einstellungen --> Verbindung --> VPN --> VPN Zugangspunkt
Verbindungsname frei wählbar
VPN-Richtline die gerade geladene Richtlinie (VPN-policy)
Internetzugangspunkt Providereinwahl
alle anderen Punkte so lassen.
Fertig.
Folgende Webseiten waren sehr hilfreich:
#[[http://www.thorsten-knabe.de/linux/e61.jsp]]
#[[http://pipip.de/other.php?sub=nokia_vpn]]
#[[http://cratoo.de/2007/10/09/howto-wie-verbindung-mit-dem-nokia-e61i-per-vpn-aufbauen]]
#[[http://www.linuxjournal.com/article/9646]]
Post new comment