It's almost one year since Julian Assange was granted asylum by the republic of Ecuador. Newspapers often incorrectly report that he sought political asylum to avoid those disturbing rape allegations (they are not charges). The real basis of his claim to asylum, which is the foundation that asylum law is based on, is that Mr Assange is not safe from political persecution in his own country. Let's not talk about rape It's often difficult for men to talk about this subject without putting their foot in their mouth. In this case, it may be easier to understand by trying to put it in context.
Just last week, our Government announced plans to expand their program of dumping poor coloured people into random countries around the Asia-Pacific region. On Monday they broke every rule in the UN's book of human rights by using the Internet to distribute gut wrenching youtube videos of a woman suffering at the hands of our immigration officers. They hope this degradation will scare away other migrants who do not meet the right economic criteria. It makes me wonder, if Mr Assange is genuinely guilty of rape despite his alleged victim boasting about her experience on Twitter, what has happened to this other woman in the care of Kevin Rudd's scorched-Earth immigration policy? Maybe because she's not a Swedish blonde, nobody cares. More racist videos from the immigration department fail to correctly inform migrants of their right to seek asylum under international law - is it possible that this offensive and misleading propaganda violates Youtube's terms of service? Crimes so bad that whistle-blowers are inevitable Former employees of the Manus Island concentration camp have stepped forward and revealed what the Government naturally doesn't want us to know. According to one former security manager, vulnerable migrants had suffered virtually every form of physical abuse, including rapes, and under orders from management in Australia, the victims were simply locked up with their abusers and no formal complaints were documented. All of a sudden, those pictures of the woman crying in the degrading video made by immigration officials take on a new meaning: she is next in line for the same destination, PNG. I somewhat suspect she would enjoy greater dignity and safety confined to Ecuador's London embassy with the so-called rapist that everybody has been distracted with. Can anybody imagine the widely discussed expression on her face improving after 20 months enforced confinement with rapists under the protection of Australia's refugee program?

It's not every day that a student messing around with keystroke loggers comes to fame through slashdot. Nonetheless, systematically rigging an election and getting sentenced to 12 months in a dorm with bars has helped raise 22 year old Matthew Weaver's profile well above that of the average script kiddie. Now let's stop and reflect on poor Weaver's future. You may be thinking that with an exchange program like this on his academic record he won't be so popular with employers. Given that he was busted by campus security rather than the FBI he won't even attract the interest of those companies who hire ex-hackers. So where could he go? How is it done in Australia? Not too long ago, when I was a student myself, one of our prominent universities was subjected to a very similar scam. Four members of the Tin Tin for NUS ticket at La Trobe University were implicated in stuffing the ballot the old fashioned way. The incidents even share the characteristics of chronic stupidity: just as Weaver had been caught voting for himself 259 times from the same IP address in a campus computer lab, team Tin Tin had tried to hand their bag of manipulated postal votes directly to the deputy returning officer rather than discretely posting them through the internal mail. According to an official report by the Deputy Returning Officer, Karsten Haley, all four candidates were charged with Dishonest Conduct and Interfering with Ballot Papers. Unfortunately, the report notes that

La Trobe University SRC Electoral Regulations do not empower the Returning Officer or Deputy to enforce charges or disciplinary procedures and the charges were never faced by the accused.

Given the seriousness of the matter, Haley did not give up his attempts to hold them to account. He escalated it to the Dean of the college and then to the University Secretary. He reports that "their disinterest was extraordinary" and that nobody would involve the police. Young Labor suspended Just over a year later, in 1997, the ALP's youth division for the state of Victoria, Young Labor, was suspended after attempts to rig the ballot to elect the Young Labor leadership team. The guilty parties were never publicly named. Nobody was formally suspended or expelled and this simply left them with more time on their hands to invest their energy in other elections. The suspension of Victorian Young Labor remained in effect for a number of years. The specific allegations about the Young Labor ballot suggest that those people particularly keen to win had printed fake student cards and given them to stooges who would impersonate other Young Labor members who had not attended to vote in person. Where are they now? It is no co-incidence that these students were (and still are) members of Labor Unity, a powerful faction within Australia's ruling Labor Party, the ALP. Most political organisations would presumably express concern about these allegations. The ALP does things differently. One of the students who withdrew his nomination in La Trobe, Mr Larocca, subsequently became Mayor in the City of Moreland, one of the ALP's strongholds. Even more remarkably from an outsider's viewpoint, another of these figures, Stephen Donnelly, is currently employed as the Assistant State Secretary of the ALP in Victoria. Communications like this newsletter reveal that he is one of the key figures in the party's pre-selection process. He has recently been appointed to direct the ALP's 2013 federal election campaign for the state of Victoria. Another co-incidence On the same weekend that Weaver was in the news for his antics, Donnelly's latest employer, the ALP's Victorian branch, was conducting pre-selection ballots to choose candidates for the upcoming federal election. So it's no surprise that Monday's newspaper headlines report fresh allegations of voting irregularities. Sadly, I've seen some of Labor Unity's bad behavior first hand. About 10 years ago I was living in South Melbourne, which is in the federal electoral district of Melbourne Ports. A young female friend of mine, a member of the local Elwood branch of the ALP, had spent election day handing out brochures for an ALP candidate in a marginal seat rather than assisting the controversial local ALP candidate, Michael Danby. A few days later I was witness to an incident where Danby aggressively confronted this young woman and demanded to know why he hadn't seen her handing out his own leaflets on polling day. He stood within centimeters of her and was literally looking down on her as he demanded some kind of apology to sooth his bruised ego. She looked terrified and barely responded. Within moments one of his handlers approached and physically moved Danby away from this young woman, I dare to think where things would have gone otherwise. Eye for talent Remarkably, at the same time, the infamous Stephen Donnelly had started shadowing Danby in his movements about the district. Fresh out of university, his talents had been recognised by Danby and he was employed in Danby's office, enabling him to continue honing his skills on a full-time basis with a tax-payer funded salary. What a remarkable contrast to the story of Weaver. Can anybody imagine a US congressman collecting Weaver from the prison gates and deploying him to an office on Capitol Hill? The biggest bankruptcy in student history Around the same time, Donnelly's Student Unity, the student arm of Labor Unity were successful in taking over the student union of my own campus, the University of Melbourne. Not long after I graduated I heard that they had been accused of skimming off $1 million from catering providers and a high-risk $46 million property transaction that put the organisation into liquidation. Unlike Mr Weaver, who's scheme at Cal State barely got off the ground, none of those involved in the Melbourne University incident has faced criminal proceedings. One ALP figure, Andrew Landeryou, spent several months in Costa Rica while wanted for questioning in the Supreme Court. His wife has just been endorsed for a seat in the Senate with support from various Labor Unity figures including Danby. The Gillard questions In 1996, around the same time that Donnelly & Co. were romping around student unions learning the tricks of the political trade, a lawyer quietly departed from the firm Slater and Gorden after an internal investigation into a property transaction linked to a union slush fund. Like Donnelly, this lawyer's next move was to take employment in the office of a Labor Party MP. More recently she was backed by Labor Unity to become Prime Minister. The union slush fund remains under investigation, frustrated by the disappearance of documents. The $60 million heist Recently I blogged about Gillard and Abbott, leaders of the two main political parties in Australia, agreeing to take $60 million of taxpayer money to fund their parties' campaigns in the upcoming federal election, giving themselves an obscenely unfair unadvantage over all other contestants. Where would that money end up? In the case of the ALP, does it appear likely that figures like the Victorian ALP's federal campaign director, Mr Donnelly, would be involved in the expenditure? National shame With this background, it becomes easier to understand the quality (or lack of it) in Australia's national leadership. When you consider that the generation responsible for the La Trobe incident, the Young Labor suspension and the MUSU bankruptcy are now growing into positions of greater responsibility in the ALP it leaves me feeling the quality of leadership is only going to get a lot worse before it starts getting better. For example, the recent incident where coloured people were fed to the sharks has nothing to do with the worldwide refugee crisis and everything to do with maintaining the dumbed-down level of political discourse that Labor Unity thugs and their followers can cope with. Real issues like climate change and energy policy, for example, appear to be beyond the pay grade of Australia's political class It is startling that up to her own recent demise, Gillard herself had repeatedly begged the public to stop asking questions about her own past and remember that Labor politicians are innocent until proven guilty - yet she had a pregnant coloured woman thrown into a concentration camp on unfounded fears about "national security". No evidence has ever been presented that poor Ranjini committed a crime, but the houses bought with money from trade unions, transactions handled through Gillard's own office, seem to be as solid as bricks and mortar. If only poor Matthew Weaver had been an Australian, how much further would his star have risen? Update: please sign the petition at change.org asking La Trobe university to re-examine the report and refer it formally to the police. If you are concerned about the plight of poor Ranjini and other people subject to Australia's domestic rendition program, please take a moment to see Letters for Ranjini

There is intense interest in communications privacy at the moment thanks to the Snowden scandal. Open source software has offered credible solutions for privacy and encryption for many years. Sadly, making these solutions work together is not always plug-and-play. In fact, secure networking, like VoIP, has been plagued by problems with interoperability and firewall/filtering issues although now the solutions are starting to become apparent. Here I will look at some of them, such as the use of firewall zones to simplify management or the use of ECDSA certificates to avoid UDP fragmentation problems. I've drawn together a lot of essential tips from different documents and mailing list discussions to demonstrate how to solve a real-world networking problem. A typical network scenario and requirements Here is a diagram of the network that will be used to help us examine the capabilities of these open source solutions. Some comments about the diagram:

• The names in square brackets are the zones for Shorewall, they are explained later.
• The dotted lines are IPsec tunnels over the untrusted Internet.
• The road-warrior users (mobiles and laptops) get virtual IP addresses from the VPN gateway. The branch offices/home routers do not use virtual IPs.
• The mobile phones are largely untrusted: easily lost or stolen, many apps have malware, they can only tunnel to the central VPN and only access a very limited range of services.
• The laptops are managed devices so they are trusted with access to more services. For efficiency they can connect directly to branch office/home VPNs as well as the central server.
• Smart-phone user browsing habits are systematically monitored by mobile companies with insidious links into mass-media and advertising. Road-warriors sometimes plug-in at client sites or hotels where IT staff may monitor their browsing. Therefore, all these users want to tunnel all their browsing through the VPN.
• The central VPN gateway/firewall is running strongSwan VPN and Shorewall firewall on Linux. It could be Debian, Fedora or Ubuntu. Other open source platforms such as OpenBSD are also very well respected for building firewall and VPN solutions, but Shorewall, which is one of the key ingredients in this recipe, only works on Linux at present.
• The branch office/home network could be another strongSwan/Shorewall server or it could also be an OpenWRT router
• The default configuration for most wifi routers creates a bridge joining wifi users with wired LAN users. Not here, it has been deliberately configured as an independent network. Road-warriors who attach to the wifi must use VPN tunnelling to access the local wired network. In OpenWRT, it is relatively easy to make the Wifi network an independent subnet. This is an essential security precaution because wifi passwords should not be considered secure: they are often transmitted to third parties, for example, by the cloud backup service in many newer smart phones.

Package mayhem The major components are packaged on all the major Linux distributions. Nonetheless, in every case, I found that it is necessary to re-compile fresh strongSwan packages from sources. It is not so hard to do but it is necessary and worth the effort. Here are related blog entries where I provide the details about how to re-build fresh versions of the official packages with all necessary features enabled:

• For Debian users, compile strongSwan 5.0 for wheezy using official packaging artifacts from the Debian maintainers. Wheezy currently only contains v4.5.x, which doesn't have several compelling features.
• For Fedora users, use rpmbuild to re-compile strongSwan 5.0 to get Elliptic Curve (ECDSA) support which works better than RSA for NAT users.
• For OpenWRT, re-compile strongSwan 5.0 to get Elliptic Curve (ECDSA) support which works better than RSA for NAT users.

Using X.509 certificates as a standard feature of the VPN For convenience, many people building a point-to-point VPN start with passwords (sometimes referred to as pre-shared keys (PSK)) as a security mechanism. As the VPN grows, passwords become unmanageable. In this solution, we only look at how to build a VPN secured by X.509 certificates. The certificate concept is not hard. In this scenario, there are a few things that make it particularly easy to work with certificates:

• strongSwan comes with a convenient command line tool, ipsec pki. Many of it's functions are equivalent to things you can do with OpenSSL or GnuTLS. However, the ipsec pki syntax is much more lightweight and simply provides a convenient way to do the things you need to do when maintaining a VPN.
• Many of the routine activities involved in certificate maintainence can be scripted. My recent blog about using Android clients with strongSwan gives a sample script demonstrating how ipsec pki commands can be used to prepare a PKCS#12 (.p12) file that can be easily loaded into an Android device using the SD-card.
• For building a VPN, there is no need to use a public certificate authority such as Verisign. Consequently, there is no need to fill in all their forms or make any payments for each device/certificate. Some larger organisations do choose to outsource their certificate management to such firms. For smaller organisations, an effective and sometimes better solution can be achieved by maintaining the process in-house with a private root CA.

UDP fragmentation during IPsec IKEv2 key exchange and ECDSA A common problem for IPsec VPNs using X.509 certificates is the fragmentation of key exchange datagrams during session setup. Sometimes it works, sometimes it doesn't. Various workarounds exist, such as keeping copies of all certificates from potential peers on every host. As the network grows, this becomes inconvenient to maintain and to some extent it eliminates the benefits of using PKI. Fortunately, there is a solution: Elliptic Curve Cryptography (ECC). Many people currently use RSA key-pairs. Best practice suggests using RSA keys of at least 2048 bits and often 4096 bits. Using ECC with a smaller 384-bit key is considered to be equivalent to a 7680 bit RSA key pair. Consequently, ECDSA certificates are much smaller than RSA certificates. Furthermore, at these key sizes, the key exchange packets are almost always smaller than the typical 1500 byte MTU. A further demand for ECDSA is arising due to the use of ECC within smart cards. Many smartcards don't support any RSA key larger than 2048 bits. The highly secure 384-bit ECC key is implemented in quite a few common smart cards. Smart card vendors have shown a preference for the ECC keys due to the US Government's preference for ECC and the lower computational overheads make them more suitable for constrained execution environments. Anyone who wants to use smart cards as part of their VPN or general IT security now, or in the future, needs to consider ECC/ECDSA. Making the network simple with Shorewall zones For this example, we are not just taking some easy point-to-point example. We have a real-world, multi-site, multi-device network with road warriors. Simplifying this architecture is important to help us understand and secure it. The solution? Each of these is abstracted to a "zone" in Shorewall. In the diagram above, the zone names are in square brackets. The purpose of each zone is described below:

Zone name	Description
loc	This is the private LAN and contains servers like databases, private source code respositories and NFS file servers
dmz	This is the DMZ and contains web servers that are accessible from the public internet. Some of these servers talk to databases or message queues in the LAN network loc
vpn_a	These are road warriors that are not very trustworthy, such as mobile devices. They are occasionally stolen and usually full of spyware (referred to by users as "apps"). They have limited access to ports on some DMZ servers, e.g. for sending and receiving mail using SMTP and IMAP (those ports are not exposed to the public Internet at large). They use the VPN tunnel for general internet access/browsing, to avoid surveillance by their mobile carrier.
vpn_b	These are managed laptops that have a low probability of malware infection. They may well be using smart cards for access control. Consequently, they are more trusted than the vpn_a users and have access to some extra intranet pages and file servers. Like the smart-phone users, they use the VPN tunnel for general internet access/browsing, to avoid surveillance by third-party wifi hotspot operators.
vpn_c	This firewall zone represents remote sites with managed hardware, such as branch offices or home networks with IPsec routers running OpenWRT.
cust	These are servers hosted for third-parties or collaborative testing/development purposes. They have their own firewall arrangements if necessary.
net	This zone represents traffic from the public Internet.

A practical Shorewall configuration Shorewall is chosen to manage the iptables and ip6tables firewall rules. Shorewall provides a level of abstraction that makes netfilter much more manageable than manual iptables scripting. The Shorewall concept of zones is very similar to the zones implemented in OpenWRT and this is an extremely useful paradigm for firewall management. Practical configuration of Shorewall is very well explained in the Shorewall quick start. The one thing that is not immediately obvious is a strategy for planning the contents of the /etc/shorewall/policy and /etc/shorewall/rules files. The exact details for making it work effectively with a modern IPsec VPN are not explained in a single document, so I've gathered those details below as well. An effective way to plan the Shorewall zone configuration is with a table like this:

		Destination zone
		loc	dmz	vpn_a	vpn_b	vpn_c	cust	net
Source zone	loc	\
	dmz	?	\	X	X	X
	vpn_a	?	?	\	X	X
	vpn_b	?	?	X	\	X
	vpn_c	X				\
	cust	X	?	X	X	X	\
	net	X	?	X	X	X		\

The symbols in the table are defined:

Symbol	Meaning
	ACCEPT in policy file
X	REJECT or DROP in policy file
?	REJECT or DROP in policy file, but ACCEPT some specific ports in the rules file

Naturally, this modelling technique is valid for both IPv4 and IPv6 firewalling (with Shorewall6) Looking at the diagram in two dimensions, it is easy to spot patterns. Each pattern can be condensed into a single entry in the rules file. For example, it is clear from the first row that the loc zone can access all other zones. That can be expressed very concisely with a single line in the policy file:

loc all ACCEPT

Specific Shorewall tips for use with IPsec VPNs and strongSwan Shorewall has several web pages dedicated to VPNs, including the IPsec specific documentation.. Personally, I found that I had to gather a few details from several of these pages to make an optimal solution. Here are those tips:

• Ignore everything about the /etc/shorewall/tunnels file. It is not needed and not used any more
• Name the VPN zones (we call them vpn_a, vpn_b and vpn_c) in the zones file but there is no need to put them in the /etc/shorewall/interfaces file.
• The /etc/shorewall/hosts file is not just for hosts and can be used to specify network ranges, such as those associated with the VPN virtual IP addresses. The ranges you put in this file should match the rightsourceip pool assignments in strongSwan's /etc/ipsec.conf
• One of the examples suggests using mss=1400 in the /etc/shorewall/zones file. I found that is too big and leads to packets being dropped in some situations. To start with, try a small value such as 1024 and then try larger values later after you prove everything works. Setting mss for IPsec appears to be essential.
• Do not use the routefilter feature in the /etc/shorewall/interfaces file as it is not compatible with IPsec

Otherwise, just follow the typical examples from the Shorewall quick start guide and configure it to work the way you want. Here is an example /etc/shorewall/zones file:

fw firewall
net ipv4
dmz ipv4
loc ipv4
cust ipv4
vpn_a ipsec mode=tunnel mss=1024
vpn_b ipsec mode=tunnel mss=1024
vpn_c ipsec mode=tunnel mss=1024

Here is an example /etc/shorewall/hosts file describing the VPN ranges from the diagram:

vpn_a eth0:10.1.100.0/24 ipsec
vpn_b eth0:10.1.200.0/24 ipsec
vpn_c eth0:192.168.1.0/24 ipsec

Here is an example /etc/shorewall/policy file based on the table above:

loc all ACCEPT
vpn_c all ACCEPT
cust net ACCEPT
net cust ACCEPT
all all REJECT

Here is an example /etc/shorewall/rules file based on the network:

SECTION ALL
# allow connections to the firewall itself to start VPNs:
# Rule  source    dest    protocol/port details
ACCEPT   all       fw                ah
ACCEPT   all       fw                esp
ACCEPT   all       fw                udp 500
ACCEPT   all       fw                udp 4500
# allow access to HTTP servers in DMZ:
ACCEPT   all       dmz               tcp 80
# allow connections from HTTP servers to MySQL database in private LAN:
ACCEPT   dmz       loc:10.2.0.43     tcp 3306
# allow connections from all VPN users to IMAPS server in private LAN:
ACCEPT vpn_a,vpn_b,vpn_c loc:10.2.0.58 tcp 993
# allow VPN users (but not the smartphones in vpn_a) to the
# PostgresQL database for PostBooks accounting system:
ACCEPT vpn_b,vpn_c loc:10.2.0.48      tcp 5432
SECTION ESTABLISHED
ACCEPT   all       all
SECTION RELATED
ACCEPT   all       all

Once the files are created, Shorewall can be easily activated with:

# shorewall compile && shorewall restart

strongSwan IPsec VPN setup Like Shorewall, strongSwan is also very well documented and I'm just going to focus on those specific areas that are relevant to this type of VPN project.

• Allow the road-warriors to send all browsing traffic over the VPN means including leftsubnet=0.0.0.0/0 in the VPN server's /etc/ipsec.conf file. Be wary though: sometimes the road-warriors start sending the DHCP renewal over the tunnel instead of to their local DHCP server.
• As we are using Shorewall zones for firewalling, you must set the options leftfirewall=no and lefthostaccess=no in ipsec.conf. Shorewall already knows about the remote networks as they are defined in the /etc/shorewall/hosts file and so firewall rules don't need to be manipulated each time a tunnel goes up or down.
• As discussed above, X.509 certificates are used for peer authentication. In the certificate Distinguished Name (DN), store the zone name in the Organizational Unit (OU) component, for example, OU=vpn_c, CN=gw.branch1.example.org
• In the ipsec.conf file, match the users to connections using wildcard specifications such as rightid="OU=vpn_a, CN=*"
• Put a subjectAltName with hostname in every certificate. The --san option to the ipsec pki commands adds the subjectAltName.
• Keep the certificate distinguished names (DN) short, this makes the certificate smaller and reduces the risk of fragmented authentication packets. Many examples show a long and verbose DN such as C=GB, O=Acme World Wide Widget Corporation, OU=Engineering, CN=laptop1.eng.acme.example.org. On a private VPN, it is rarely necessary to have all that in the DN, just include OU for the zone name and CN for the host name.
• As discussed above, use the ECDSA scheme for keypairs (not RSA) to ensure that the key exchange datagrams don't suffer from fragmentation problems. For example, generate a keypair with the command ipsec pki --gen --type ecdsa --size 384 > user1Key.der
• Road warriors should have leftid=%fromcert in their ipsec.conf file. This forces them to use the Distinguished Name and not the subjectAltName (SAN) to identify themselves.
• For road warriors who require virtual tunnel IPs, configure them to request both IPv4 and IPv6 addresses (dual stack) with leftsourceip=%config4,%config6 and on the VPN gateway, configure the ranges as arguments to rightsourceip
• To ensure that roadwarriors query the LAN DNS, add the DNS settings to strongswan.conf and make sure road warriors are using a more recent strongSwan version that can dynamically update /etc/resolv.conf. Protecting DNS traffic is important for privacy reasons. It also makes sure that the road-warriors can discover servers that are not advertised in public DNS records.

Central firewall/VPN gateway configuration Although they are not present in the diagram, IPv6 networks are also configured in these strongSwan examples. It is very easy to combine IPv4 and IPv6 into a single /etc/ipsec.conf file. As long as the road-warriors have leftsourceip=%config4,%config6 in their own configurations, they will operate dual-stack IPv4/IPv6 whenver they connect to the VPN. Here is an example /etc/ipsec.conf for the central VPN gateway:

config setup
        charonstart=yes
        charondebug=all
        plutostart=no
conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
conn branch1
        left=198.51.100.1
        leftsubnet=203.0.113.0/24,10.0.0.0/8,2001:DB8:12:80:/64
        leftcert=fw1Cert.der
        leftid=@fw1.example.org
        leftfirewall=no
        lefthostaccess=no
        right=%any
        rightid=@branch1-fw.example.org
        rightsubnet=192.168.1.0/24
        auto=add
conn rw_vpn_a
        left=198.51.100.1
        leftsubnet=0.0.0.0/0,::0/0
        leftcert=fw1Cert.der
        leftid=@fw1.example.org
        leftfirewall=no
        lefthostaccess=no
        right=%any
        rightid="OU=vpn_a, CN=*"
        rightsourceip=10.1.100.0/24,2001:DB8:1000:100::/64
        auto=add
conn rw_vpn_b
        left=198.51.100.1
        leftsubnet=0.0.0.0/0,::0/0
        leftcert=fw1Cert.der
        leftid=@fw1.example.org
        leftfirewall=no
        lefthostaccess=no
        right=%any
        rightid="OU=vpn_b, CN=*"
        rightsourceip=10.1.200.0/24,2001:DB8:1000:200::/64
        auto=add

Sample branch office or home router VPN configuration Here is an example /etc/ipsec.conf for the Linux server or OpenWRT VPN at the branch office or home:

conn head_office
        left=%defaultroute
        leftid=@branch1-fw.example.org
        leftcert=branch1-fwCert.der
        leftsubnet=192.168.1.0/24,2001:DB8:12:80:/64
        leftfirewall=no
        lefthostaccess=no
        right=fw1.example.org
        rightid=@fw1.example.org
        rightsubnet=203.0.113.0/24,10.0.0.0/8,2001:DB8:1000::/52
        auto=start
# notice we only allow vpn_b users, not vpn_a
# these users are given virtual IPs from our own
# 192.168.1.0 subnet
conn rw_vpn_b
        left=branch1-fw.example.org
        leftsubnet=192.168.1.0/24,2001:DB8:12:80:/64
        leftcert=branch1-fwCert.der
        leftid=@branch1-fw.example.org
        leftfirewall=no
        lefthostaccess=no
        right=%any
        rightid="OU=vpn_b, CN=*"
        rightsourceip=192.168.1.160/27,2001:DB8:12:80::8000/116
        auto=add

Further topics Shorewall and Shorewall6 don't currently support a unified configuration. This can make it slightly tedious to duplicate rules between the two IP variations. However, the syntax for IPv4 and IPv6 configuration is virtually identical. Shorewall only currently supports Linux netfilter rules. In theory it could be extended to support other types of firewall API, such as pf used by OpenBSD and the related BSD family of systems. A more advanced architecture would split the single firewall into multiple firewall hosts, like the inner and outer walls of a large castle. The VPN gateway would also become a standalone host in the DMZ. This would require more complex routing table entries. Smart cards with PIN numbers provide an effective form of two-factor authentication that can protect certificates for remote users. Smart cards are documented well by strongSwan already so I haven't repeated any of that material in this article. Managing a private X.509 certificate authority in practice may require slightly more effort than I've described, especially when an organisation grows. Small networks and home users don't need to worry about these details too much, but for most deployments it is necessary to consider things like certificate revocation lists and special schemes to protect the root certificate's private key. EJBCA is one open source project that might help. Some users may want to consider ways to prevent the road-warriors from accidentally browsing the Internet when the IPsec tunnel is not active. Such policies could be implemented with some basic iptables firewalls rules in the road-warrior devices. Summary Using these strategies and configuration tips, planning and building a VPN will hopefully be much simpler. Please feel free to ask questions on the mailing lists for any of the projects discussed in this blog.

• strongSwan users mailing list
• shorewall-users mailing list

I previously discussed the ease of deploying IPv6 for Linux servers. Whether it is Debian, Fedora or another distribution the IPv6 stack should "just work" these days. However, for maintaining a production network with minimum risk of interruption, there are a few extra things to be aware of during IPv6 deployment. Here I present a rough set of steps that can be followed, usually with minimal or no downtime, to deploy IPv6. The steps are in the order that they should be used in practice Plenty of other web sites already explain the theory of IPv6 networks or practical configuration detail (like how to set a static IPv6 address in Debian). This page ignores all of that detail and looks at the overall project strategy. Borrow the last decimal octet (or host bits) of IPv4 addresses As mentioned in my earlier blog:

• Of the 128 bits in IPv6 addresses, most sites now use a fixed 64 bit netmask for all their subnets. This is the practice encouraged by RFC 4291.
• Therefore, there are always more bits in the 64-bit "host" portion of the address than in the host portion of any 32-bit IPv4 address.
• Consequently, it is possible to just borrow the host portion (typically the last octet for a class-C network) and use it as the host portion of an IPv6 address

IPv4 address	Host portion of address	IPv6 address
192.168.1.5/24	5	2001:1234:567::5

Gotcha: remember that the IPv4 addresses are usually written in decimal while IPv6 addresses, including the example above, are hex. This doesn't really matter in practice unless the addresses are being manipulated by code that is sensitive to the host bits. For all other intents and purposes, it just makes it easy to read the addresses and associate them with IPv4. A completely valid alternative is to use the full IPv4 address as the host portion of the IPv6 address. For example, if the IPv4 address = 192.168.1.5, the IPv6 address may be 2001:1234:567::192.168.1.5. This approach is slighly more verbose and is completely valid. Which approach you use is at your discretion. Create reverse mappings (PTR records) in DNS Just as IPv4 has the in-addr.arpa zone and telephone numbers have the e164.arpa zone (for ENUM), IPv6 addresses have a reverse mapping zone too: ip6.arpa The recommended way to proceed is to create reverse mappings for all hosts that have IPv4 reverse mappings. Some services may be using reverse lookups for authentication (e.g. MySQL will check this for any user who has a "Host" restriction defined). This is why it is recommended to create all the reverse mappings very early in the IPv6 program, before any hosts start making connections over IPv6. Create extra A records in DNS It's possible that some applications will be more stubborn about IPv6 adoption than others. For example, if you have a host called wolf.example.org and it hosts a mail server, web server, DNS server and XMPP server all using the name wolf then all those server processes will have to support IPv6 connectivity from the moment you add an AAAA record. A good practice is to create independent DNS A records (such as ns1.example.org and mail.example.org) for each application (not just CNAME records). Existing CNAME records can be converted to A records and converted back to CNAME records after the IPv6 deployment is 100% complete. Duplicate firewall entries Duplicate all IPv4 firewall entries to create an IPv6 firewall For many types of network, this is a trivial (although possibly tedious) task. There are some small gotchas:

• There is no NAT. Any firewall entries for NAT need to be reviewed: for source NAT, it is necessary to use a mechanism like connection tracking to protect workstations that previously had asymmetrical access to the public Internet. For destination NAT, see the TPROXY feature in ip6tables
• IPsec works slightly differently. Rules for AH and ESP packets can't simply be duplicated for IPv6, they need further tweaks or warnings will be generated.
• IPv6 makes some ICMP packages mandatory. If IPv4 ICMP is completely blocked, you still need to enable the IPv6 ICMP (or at least the subset of ICMP packets that are mandatory).

For more comments about firewalling IPv6, please see my earlier blog on the subject Put the IPv6 addresses on the hosts Add the necessary records to the appropriate place, for example, the /etc/network/interfaces files on Debian/Ubuntu style systems. For hosts that have multiple addresses on a single interface, it is often desirable to ensure that outbound connections always appear to come from just one of the addresses. This can be achieved using the preferred_lft option when configuring the non-default addresses. For example, if configuring three addresses on eth0:

ip addr add dev eth0 preferred_lft 0 2001:1234:567::10/64
ip addr add dev eth0  2001:1234:567::11/64
ip addr add dev eth0 preferred_lft 0 2001:1234:567::12/64

In the example above, all outgoing IPv6 connections will appear to come from 2001:1234:567::11/64 Important: this is only a very shallow discussion of the issues around source addresses. If it doesn't provide a valid solution for you, there are many dedicated articles about this specific topic, madduck's blog looks at it for firewalls and tunnels but the concepts are valid for any type of multi-homed host Review listening processes with netstat Now that hosts have IPv6 addresses, it is worthwhile looking through the output of

netstat -nlp

to see which processes have bound to both IPv4 and IPv6 addresses and which processes remain stuck on IPv4 only. For processes that are only listening on IPv4 or only bound to a specific address (rather than 0.0.0.0), it is a good idea to investigate the way they are configured and find out if they will support IPv6. Review the monitoring infrastructure (Nagios, Ganglia, etc) Now is a good time to review the monitoring infrastructure. Make sure that tools like Nagios are testing the services using their dedicated DNS names and not the host names. For example, if the host wolf.example.org runs an LDAP server accessible as ldap1.example.org, make sure Nagios is configured to poll ldap1.example.org. Look at the check_v46 wrapper for Nagios and similar solutions to make sure that Nagios is testing both the IPv4 and IPv6 version of each service. Just as developers use unit testing as part of test-driven development workflows, administrators deploying IPv6 can use the monitoring framework to validate the progress of their IPv6 program. Check for ACLs Do any server processes use IP-based ACLs to control access? For example, an Apache web server may be using an IP ACL to restrict access to some pages. MySQL or Postgres databases may have IP ACLs defined for some users or databases. When hosts start using IPv6 to connect to services, their IPv6 source addresses won't pass the ACL and services may be inaccessible. Therefore, it is worthwhile checking for such ACLs early on. Prepare DNS servers first Preparing the DNS servers first is a good step. The DNS servers should be configured to accept queries over IPv6. Once the DNS servers are listening on IPv6 addresses, go ahead and do some of the following:

• Insert IPv6 AAAA records for the name servers in their own zone files. As mentioned in the previous tip, the name server records should have their own independent A records already with names such as ns1.example.org. Consequently, no other application should notice when the AAAA record is created.
• Create IPv6 glue records for any name servers that have IPv4 glue records

Configure secondary name servers to poll over IPv6 Configure the secondary nameservers to poll the primary nameserver using it's new IPv6 address. Update resolv.conf on all hosts Now that DNS servers are listening on IPv6, it is possible to put IPv6 nameserver addresses in /etc/resolv.conf on all the other hosts. Configure and test other low-level services Although services such as LDAP and MySQL may not be exposed to public Internet users, they are an essential foundation for many other applications to run. Make sure all these low level services are accessible over IPv6. Test them. After testing each of these services, it is OK to go ahead and create the AAAA records for the service. Configure and test other services Continue testing each service is accessible over it's IPv6 address and then add the necessary AAAA record. This includes all the high level services now, such as mail and web servers. Configure and test hostnames Finally, start adding AAAA records associated with hostnames to the DNS zone. Now it should be possible to ssh or ping6 the hostnames using IPv6. You may also want to add the IPv6 address of each host into it's own /etc/hosts file at this stage.

In my earlier blog post about VPNs, I looked at a range of VPN options. The strongSwan wiki documentation is generally quite good but it doesn't describe the exact procedure for an Android user anywhere. This blog aims to fill that gap. Here I am sharing some working examples of how to configure and use RSA certificate authentication between a Linux box and an Android phone using strongSwan. There are several commands to execute for each step, but they can be easily scripted. Here are the versions in play:

• Debian 7 (wheezy) has strongSwan 4.5.2.
• EPEL6 also has v4.6.4
• Fedora 17, 18 and 19 have v5.0.x

Certificate creation: private certificate authority "example.org CA root" For production, I would highly recommend creating your own root CA on a smart card and managing it from a clean machine without any network connection. To start quickly for testing, just create a CA using the steps from the strongSwan wiki, in particular:

umask 0177
ipsec pki --gen > caKey.der
ipsec pki --self --in caKey.der \
   --dn "C=CH, O=Acme Ltd, CN=example.org CA root" \
   --ca > caCert.der

Certificate creation: VPN gateway machine vpn.example.org Now you need to create a key for the server. The key thing to observe here is the use of the "--san" argument: the Android client expects a subjectAltName in the certificate from the server. The VPN gateway has the hostname vpn.example.org:

ipsec pki --gen > vpnKey.der
ipsec pki --pub --in vpnKey.der   \
   ipsec pki --issue --cacert caCert.der --cakey caKey.der \
  --dn 'CN=vpn.example.org' \
  --san vpn.example.org > vpnCert.der 
cp vpnKey.der /etc/ipsec.d/private/
cp vpnCert.der /etc/ipsec.d/certs/

Certificate creation: mobile user For the Android client, it is necessary to create a private key and certificate and then embed them together with a copy of the root certificate in a PKCS#12 file. We will need OpenSSL or GnuTLS for some of these steps. The pkcs12 command will prompt for a password: make up a long, obscure password, you will only use it once when importing the certificate into the phone. Here is a script you can use for each client certificate you want to create:

#!/bin/bash -e
umask 0177
TARGET_HOST=$1
DOMAIN=example.org
IPSEC=/usr/sbin/ipsec
KEY_FILE="$ TARGET_HOST Key.der"
CRT_FILE="$ TARGET_HOST Cert.der"
if [ -f $ KEY_FILE  ];
then
  echo "$KEY_FILE exists"
  exit 1
fi
$ IPSEC  pki --gen > $ KEY_FILE  
$ IPSEC  pki --pub --in  $ KEY_FILE    \
  $ IPSEC  pki --issue \
  --cacert caCert.der --cakey caKey.der \
  --dn "CN=$ TARGET_HOST .$ DOMAIN " > $ CRT_FILE 
[ -f caCert.pem ]   \
   openssl x509 -in caCert.der -inform der -out caCert.pem -outform pem
openssl rsa \
   -in $ KEY_FILE  -out $ TARGET_HOST Key.pem -inform der
openssl x509 \
   -in $ CRT_FILE  -inform der \
   -out $ TARGET_HOST Cert.pem -outform pem
openssl pkcs12 \
   -export \
   -in $ TARGET_HOST Cert.pem \
   -inkey $ TARGET_HOST Key.pem \
   -certfile caCert.pem \
   -out $ TARGET_HOST .p12
# delete the key files, leaving only the key in the p12 file:
rm $ KEY_FILE  $ TARGET_HOST Key.pem

Assuming you call that script make-client-creds, you would run it once for each Android device:

$ ./make-client-creds phone1
$ ./make-client-creds phone2
...

Loading the PKCS#12 file into the phone Copy the cert bundle (the p12 file only) to the SD card in the phone. You can mount the phone over USB or using ADB, e.g.

$ adb push phone1.p12 /sdcard/

Now go to the Android settings, select Security and Install from SD card. Follow the prompts. Setting up the VPN gateway Add the following line to /etc/ipsec.secrets

: RSA vpnKey.der

and add a stanza like the following to /etc/ipsec.conf

conn private-droid
	left=vpn.example.org
	leftsubnet=insert gateway IP here/32
	leftcert=vpnCert.der
	leftid=@vpn.example.org
	leftfirewall=no
	lefthostaccess=no
	right=%any
	rightsourceip=192.168.10.0/24
	auto=add

Finally, restart ipsec and you should be ready.

# service ipsec restart

Install the app on the phone Finally, install the app on the phone. This bit should be quite easy. Once installed, press the option ADD VPN, put in the DNS name of the VPN gateway (must match the name in the certificate, e.g. vpn.example.org from the example above) and tell it to use IKEv2 Certificate as the authentication type. Press to select a certificate and highlight the certificate that you installed earlier. Checking for problems You should see a message on the phone telling you it is connected to the VPN. If it fails, it will let you see the log messages. If you see the error Constraint check failed it often means that the subjectAltName was not included in the VPN gateway's certificate (see the steps above) or the DNS name doesn't match the name in the certificate. On the server side, this command shows who is connected:

# ipsec status

Making it secure with iptables Once the packets are decrypted by strongSwan on the VPN gateway, the kernel will route them appropriately just like any other packet. Use standard Linux netfilter/iptables rules to ensure that routing is restricted appropriately so that the clients can access the services they need and nothing else. Support and discussion Please feel free to post comments below or discuss on the strongSwan Users mailing list

"The blood, sweat and tears that has gone into the Ultranet and the work teachers put in it's soul destroying. I have to face parents who took me on face value when I said: 'This is the best thing since sliced bread every school is going to be using it in the future."

Those are the words of a school principal at Alkira Secondary College in Victoria, Australia. His school is receiving a real-life lesson in the the risks of cloud computing. Ultranet, the state-wide private cloud project for schools is at risk of being cancelled in 10 days due to budget cuts. It is not clear whether the vendor, NEC, is obliged to release data back to the users if the original four year contract is not extended. Commercial, confidential discussions It appears that the possibility of ending the contract was not supposed to be public knowledge. If the finance department had kept their intentions secret then it is possible that users would not even have had the opportunity to try and manually extract some of their data, as they are rushing to do now. Instead of getting on with the business of education itself, teachers and students are having to waste time trying to individually download student projects, photos, feedback and other meta data from the system in an ad-hoc manner. An opportunity for free and open source software This debacle may well be a huge opportunity for the free and open source software community to remind people that the value of retaining control over user data can not be forgotten when evaluating outsourced, private cloud solutions that claim to be "free" or offer low costs to get started. There were apparently 18 schools who initially trialed the program and many more have gradually joined up. This would be the perfect opportunity for advocates of genuinely free software solutions to contact them and let them know they are not alone and that many of us have anticipated these problems for years. While central government administrators tend to be hooked on the idea of administering big contracts with trusted' vendors, these local school administrators and the communities around them are probably more receptive to the free software message than at any other time. List of schools using Ultranet Many of the schools using Ultranet can be found with Google, as it appears to be integrated in their web sites. Click here for a Google search that finds many of the schools and related technical pages, support documents and other material A message to schools everywhere For schools facing this crisis or considering adopting such services in other countries, I would share this very simple advice: if you are offered a solution that doesn't give you complete control to conveniently extract all of your data in bulk whenever you want and use it in your own software on any computer, then it is not a good foundation to build on. The free software community has been actively working to provide truly free solutions for schools and I would strongly encourage schools to look at projects like Skolelinux/Debian-Edu and k12Linux that have been built by educators who also have a deep understanding of software and data freedom issues.

Normally Skype isn't mentioned by name on this blog, but today I'm making an exception. When a new scandal broke out in the Australian Army today, one of the first questions asked was how does it compare to the Skype Scandal which had everybody talking (and blushing) in 2011. A concise military reply direct from the General: "I'd say it's worse than the Skype matter" (the original Skype Scandal cadets are going on trial in six weeks) Jedi Council brings cultural change in the Army: from Skype to email Since the original scandal, there have been plenty of PR-orchestrated headlines about cultural change in the Army. Sadly, it seems that several ranking officers believed that was a cue to simply start using email instead of live feeds Operating under the operational code name Jedi Council, they've apparently been swapping annotated images of female colleagues and members of the public service. A more detailed account summarises it: "They were calling themselves the Jedi Council but they were doing the exact opposite of what Jedis are supposed to do" While the Skype scandal involved cadets behaving much like college kids elsewhere, this latest scandal involves the officer corp, the most senior officer implicated is allegedly a Lieutenant Colonel. Senior ranking officers like this have given many years of dedicated service to the country. They are widely respected and the vast majority of officers in these positions are unlikely to ever be implicated in such a scandal. Officers are in leadership roles, it should be no surprise if they have top secret security clearances. After the revelation that Australia has a direct and high-volume data sharing arrangement with the US Government (and in turn Facebook, Google, etc), there are all kinds of questions about whether a couple of rogue officers have access to pursue their private Jedi Council project using tools like PRISM and Boundless Informant. It's already been confirmed that they were keeping their own Jedi database of their victim's names, phone numbers, home addresses and various clothing measurements and if they are already emailing these photos about on Defence computers, does it seem improbable that they would be using PRISM or other sources to cross-reference their data? Behavior described as systematic and predatory It can't be ruled out that some defence computer systems may have direct access to NSA copies of images from those invasive airport body scanners - like these pictures that were not supposed to exist. Just like the British undercover cops stealing the identities of dead children and fully engaging with impressionable young women from environment campaign groups, there are a long list of possible abuses when the security state is over-empowered. While this latest Army example involves private pursuits, it is not hard to imagine many other permutations: perhaps a couple of rogue Government employees making unauthorised use of PRISM data for a commercial objective and gaining the upper hand on private sector competitors who have no such data feed. 100% trust? In every organisation there will always be a few people bending the rules. It's human nature, if it wasn't that way, we'd all be robots (or drones). The Army and the Catholic Church tend to be hammered a lot more in the public eye when these transgressions are discovered although statistically their crime rates are no higher than average. The bottom line is that no organisation is perfect and people have to take some responisbility to object to the excessive growth of the security state and keep our data to ourselves as you just never know who you can trust.

In a blog attempting to join the dots between Australia's intelligence services and the US PRISM program, I speculated that Australia has had extensive access to data harvested by PRISM. My hunch has just been exposed rather dramatically today: Top secret data center under construction to house all our secrets. "There has been no discussion of the project in Senate estimates committee hearings, and the public reports of Parliament's joint committee on intelligence and security make no reference to it." The news story also suggests that the relationship is bi-directional, with data harvested from Australian ISPs cross referenced against US databases from Facebook and Google. From a human rights perspective, the implications of this data sharing are much more dramatic than the NSA just snooping on US citizens within the US. While Australia often tries to portray the image that it is a safe and happy country, it has a dark side. Police are kept busy investigating politicians and Government officials: Prime Minister and her associates connected to a union slush fund, the central bank's banknote printing agency's chief executive and 8 colleagues on conspiracy charges and even a senator on good old fashioned shoplifting and assault charges Exporting PRISM data to a human rights backwater As an Australian, my own rights and those of my family are more heavily protected and respected living in Europe than if I lived in my country of birth. Australia does not have a bill of rights like the US (where PRISM data is harvested) or the European Convention of Human Rights. Once US data is exported to Australia, it can be used to support sinister programs like the indefinite detention of coloured people in sinister desert camps. Just this week, the Government left over 50 bodies of poor refugees for the sharks to eat. For someone with such a lack of a conscience, can you imagine them thinking twice about using PRISM data for unscrupulous purposes? Is US PRISM data at greater risk? Despite the stench of corruption and lip service to human rights, is there any hard evidence that PRISM data will be at greater risk if allowed into the hands of Australians? Death by SMS One former Australian official (having dual-citizenship with Sri Lanka) is accused of facilitating war crimes in the Sri Lankan civil war. At present he is Sri Lanka's ambassador at the UN, giving him the benefit of diplomatic immunity. When he was working for Australia, how much data did he have access to? Isn't it ludicrous that in the name of stopping terrorism, data may have been collected and handed to war criminals on a silver platter? Behind enemy lines Like James Bond in reverse, an Australian official was exposed unofficially engaging in a relationship with a Vietnamese spy colonel. In addition to the $20 million in bribery to win a bank note printing contract, is data being used as a tool to leverage trade negotiations, officially or otherwise? If an Australian official with top-secret clearance ends up under the control of a foreign agent, what is the risk that they would be exploited to obtain PRISM data? Defence minister resignation in Chinese spy scandal In 2009 Australia's defence minister was identified having close links to a Chinese-Australian business woman including all the usual little luxuries: first class flights, apartment rental and joint business deals with family members. He subsequently resigned. Little details were made public. How much PRISM data was directly available to political officials like the defence minister? Disappearing Prime Ministers The disappearance of a serving Prime Minister, Harold Holt, during the cold war remains an unsolved mystery to this day. People continue to ask was he swept out to sea or voluntarily whisked away in a Chinese or Soviet nuclear submarine. While Australia has traditionally had strong ties to Britain and the US, there have been exceptions to the rule. Fortunately this all happened before PRISM and Harold Holt red submarine rumours are no more well-founded than the UFO theories of his abduction. Where did all the data go? As the music industry has found out the hard way, digital data can be copied at will with the originator having no control. The revelations that Britain and Australia are in on the PRISM shenanigans only confirms that this data is seen as a new form of currency for exchange in geo-political posturing. While used weapons take decades to work their way down the chain, data can spread at the speed of light.