IPv6 « Page 3 « b20c:c011:5:b109::/64

Category Archives: IPv6

Apache SSL Server

Posted on December 15, 2012 by cbroccoli

Got a basic web server with ssl running on Apache under Ubuntu 12.04 LTS with a self signed certificate. Here are the steps I followed:

Installed Apache2:

$  sudo apt-get install apache2

Generated the certificate with openssl:

$ openssl genrsa -out ssltest.key 1024
$ openssl req -new -key ssltest.key -out ssltest.csr
$ openssl x509 -req -days 365 -in ssltest.csr -signkey ssltest.key 
  -out ssltest.cert

Moved the certificates to a dedicated directory:

$ sudo mkdir /etc/apache2/ssl
$ sudo mv /home/cbroccoli/*.cert /etc/apache2/ssl
$ sudo mv /home/cbroccoli/*.key /etc/apache2/ssl
$ sudo chmod 400 /etc/apache2/ssl/*.key (make key read-only)

Created an ssl configuration file for the new site by copying the default file in /etc/apache2/sites-available:

sudo cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/sslsite.ssl

Updated sslsite.ssl with the following lines:

     ServerName sslsite.com 
     ServerAlias *.sslsite.com
     ...
     SSLCertificateFile    /etc/apache2/ssl/ssltest.cert
     SSLCertificateKeyFile /etc/apache2/ssl/ssltest.key

Started the ssl module:

$ sudo a2enmod ssl

Enabled the site:

$ sudo a2ensite sslsite.ssl

Restarted apache:

$ sudo service apache2 reload

I then accessed the site with the IP address and got the error message that the certificate is not secure as expected.

Access via IPv6 required an additional minor configuration for both http and https access to the page. In the file/etc/apache2/ports.conf, the following lines were added after the respective “Listen” lines which were already included.

Listen [fdc1:b20c:c011:1:20c:29ff:fe27:ec05]:80
...
Listen [fdc1:b20c:c011:1:20c:29ff:fe27:ec05]:443

By default, Apache see the wildcards (*) as only IPv4 addresses, so it needs these extra lines in addition to the lines with the wildcard.

Testing Windows 8 with veripy

Posted on December 7, 2012 by cbroccoli

No Comments

This is the third in a series of posts about assessing the readiness of an enterprise’s ICT environment for IPv6.

The testing did not go a smoothly as planned, since veripy does exhaustive testing of the node under test (aka the NUT). This means that if you let it run through everything, it will take a number of hours (I never made it due to a lack of patience) and has a number of points where you need to enter “y” or “n” or input an IP address for it to ping. It also requests that you rest the NUT’s interface a number of times to see that it responds correctly under different conditions to SLAAC address delivery. So after a couple of trial runs, I commented out all of the “host” testes in the veripy configuration file, veripy.cfg, except for the BasicI IPV6 Compliance test. Even this took about 30-45 minutes. I also updated the configuration file with the information about the network and the Windows 8 client as follows:

[test-network]
link-layer: Ethernet

links: 1, 2, 3
link-1-v4: 10.0.0.0/24
link-1-v6: 2012:7665:7269:7079::/64
link-2-v4: 192.168.239.0/24
link-2-v6: fdc1:b20c:c011:1::/64
link-3-v4: 10.2.0.0/24
link-3-v6: 2012:6d77:7269::/64

nodes: tn1, tn2, tn3, tn4
tn1-ifaces: 1
tn1-if0-address: de:ad:be:ef:01:02
tn1-if0-ips: fdc1:b20c:c011:1::ef:102, fe80::7a2b:cbff:feef:102,
 fe80::7a2b:cbff:feca:ad05
tn2-ifaces: 1
tn2-if0-address: de:ad:be:ef:01:03
tn2-if0-ips: 2012:7665:7269:7079::ef:103, fe80::7a2b:cbff:feef:103
tn3-ifaces: 1
tn3-if0-address: de:ad:be:ef:01:04
tn3-if0-ips: 2012:7665:7269:7079::ef:104, fe80::7a2b:cbff:feef:104
tn4-ifaces: 1
tn4-if0-address: de:ad:be:ef:01:05
tn4-if0-ips: 2012:6d77:7269::ef:105, fe80::7a2b:cbff:feef:105

routers: tr1, tr2, tr3
tr1-ifaces: 2
tr1-if0-address: be:ef:ca:fe:01:01
tr1-if0-ips: 2012:6970:7636::fe:101, fe80::7a2b:cbff:fefe:101
tr1-if1-address: be:ef:ca:fe:01:02
tr1-if1-ips: fdc1:b20c:c011:1::fe:102, fe80::7a2b:cbff:fefe:102
tr2-ifaces: 2
tr2-if0-address: be:ef:ca:fe:01:03
tr2-if0-ips: 2012:7665:7269:7079::fe:102, fe80::7a2b:cbff:fefe:102
tr2-if1-address: be:ef:ca:fe:01:04
tr2-if1-ips: fdc1:b20c:c011:1::fe:103, fe80::7a2b:cbff:fefe:103
tr3-ifaces: 2
tr3-if0-address: be:ef:ca:fe:01:05
tr3-if0-ips: 2012:7665:7269:7079::fe:103, fe80::7a2b:cbff:fefe:103
tr3-if1-address: be:ef:ca:fe:01:06
tr3-if1-ips: fdc1:b20c:c011:1::fe:104, fe80::7a2b:cbff:fefe:104

taps: tp1, tp2
tp1-dev: eth1
tp1-address: 00:0c:29:8e:de:a1 
tp2-dev: eth0
tp2-address: 01:02:03:04:05:07

Before running any tests, I started the GNS3 based Cisco router and the Windows 8 PC. While the tests were running, the network configuration of the Windows 8 PC looked like this:

C:\Windows\system32>ipconfig /all
Windows IP Configuration
   Host Name . . . . . . . . . . . . : Window8PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : localdomain

Ethernet adapter Ethernet 2:
   Connection-specific DNS Suffix  . : localdomain
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network 
                                       Connection #2
   Physical Address. . . . . . . . . : 00-0C-29-35-A0-FB
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fdc1:b20c:c011:1:9927:f9dc:7bf9
                                       :f834(Preferred)
   Temporary IPv6 Address. . . . . . : fdc1:b20c:c011:1:589b:17bd:9e48
                                       :40e6(Preferred)
   Link-local IPv6 Address . . . . . : fe80::9927:f9dc:7bf9:f834%22
                                       (Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.239.132(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, December4,2012 11:51PM
   Lease Expires . . . . . . . . . . : Wednesday, December5,2012 1:51AM
   Default Gateway . . . . . . . . . : fe80::7a2b:cbff:fefe:102%22
                                       fe80::7a2b:cbff:fefe:103%22
                                       fe80::7a2b:cbff:fefe:104%22
                                       fe80::ce00:27ff:fe1c:0%22
   DHCP Server . . . . . . . . . . . : 192.168.239.254
   DNS Servers . . . . . . . . . . . : 192.168.239.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

The test was started using the following command:

$ sudo ./bin/veri.py \
 -c veripy.cfg \
 -f T /home/cbroccoli/Desktop/win8_test.txt \
 -f H /home/cbroccoli/Desktop/win8_test.html \
 -t 1 fdc1:b20c:c011:1:9927:f9dc:7bf9:f834 \
 fe80::9927:f9dc:7bf9:f834 \
 192.168.239.132 \
 00:0c:29:35:a0:fb \
 host

This placed the results into a html file named win8_test once the tests were completed. Some cool features of veripy are that along with the html report, it captures all packets on the network into a pcap file which can be viewed with Etherreal. The files can be opened via a link on the report page next to each individual test. Below is a screen shot of the report page:

All in all I accomplished what I was set out to do. The results for the Windows 8 client are not necessarily correct since the client was running on VMWare Player which may have filtered out some of the malformed packets. veripy recommends using a crossover cable to do the tests so in a lab environment, this would probably also make a lot of sense. Also I am using a pre-release version of Windows 8, so the released version may be better at handling the error conditions. Nevertheless a very interesting exercise!

veripy Lab Setup

Posted on December 6, 2012 by cbroccoli

No Comments

The lab I planned on using for this project centered around a Ubuntu desktop client installed as a VM under VMWare player. In order to provide IPv6 connectivity, I used GNS3 with a virtual Cisco router running IOS 12.4(21). I used a evaluation version of Windows8 as the system to run the tests against. Windows8, even though it is an evaluation version which I got as a beta version seems to keep itself up to date, so I figure it should pass with flying colors. To monitor much of the testing I planned on using Etherreal which is installed natively on my Wondows7 host workstation. The following diagram should make everything clear:

Installing veripy took longer than expected due to my lack of knowledge about Python. Python is an interpreted programming language which is supported by default under Ubuntu. I have never installed or used a Python based application and so learned a lot about how Python works during this installation, mostly because I have trouble following directions. veripy required a couple of other Python based applications to make it work, the most important of which is Scapy, the program used to generate the IPv6 packets (especially the bad ones, wrong version number, etc.). Most Python modules are installed like normal applications using the “appget” command. Modules are installed under the Python directory.

I started by downloading the veripy-1.0.1.tar.gz archive and unpacking into a subdirectory called Apps (/home/cbroccoli/Apps). Since veripy does not install as a standard Python module (see how Scapy was installed below to see that), I had to add the location of the base veripy files to the PYTHONPATH environment variable. This was done by adding the following line to the /etc/environment file:

PYTHONPATH="/home/cbroccoli/Apps/veripy"

Adding the variable to the /etc/environment file ensures that the environment variable is persistent across terminal windows, reboots, etc. To confirm that the change worked run the following command:

$ printenv PYTHONPATH

With this done, I installed the applications which are required for scapy:

$ sudo apt-get install tcpdump graphviz imagemagick python-gnuplot 
python-crypto python-pyx

Finally, I downloaded and installed Scapy:

$ cd /home/cbroccoli/Downloads
 $ wget scapy.net
 $ unzip scapy-latest.zip
 $ cd scapy-2.*
 $ sudo python setup.py install

Now I was ready to run the tests.