In this lab two local networks, each separated and protected by a firewall will be put into communication through an IPSec VPN. Verify by a sniffer placed on intermediate links, the traffic between two LAN is encrypted and therefore incomprehensible to the direct opposite of what other hosts as PC3. The occasion is also good to check the interoperability of IPSec between devices of different brands.
IPSec is the standard de facto used for VPNs. Guarantees confidentiality (data is encrypted in a serious way) integrity (the data can not be changed during transport) and authentication (end points are authenticated). Uses an asymmetric key mechanism to negotiate a symmetric key with which the data is actually encrypted in transit. The asymmetric key gives the opportunity to create an encrypted connection on an insecure channel, and then allow the subsequent exchange of a symmetric key. The latter is most effective encryption continues, and the key is renegotiated every few seconds of operation (or tot data travels through the tunnel), thus avoiding the possibility that someone, analyzing traffic, try to calculate the key time.
Firewalls are used for lab equipment recovery, but still very valid especially for educational purposes. The first is a glorious Cisco Pix 515E, rackmount, with 3 physical interfaces. The other consists of a rather old motherboard micro ATX, dual ethernet port on which you installed m0n0wall, open source firewall based on FreeBSD. The small motherboard used was not possible to do much: the CPU to 400MHz it severely restricted the possibility of using traditional operating systems. Instead, for m0n0wall was excellent, works well and runs without slowing down.
Firstly, the devices are configured to obtain an operating basis, the attached form, then set the IP interfaces, NAT, the default-route. To configure the PIX can act as a command line or through SDM, graphical Java application made available by the same firewall via web browser, unfortunately this is not without flaws, it locks up and forces you to restart your browser or even the pc, and then requires a specific version of Java sw, but for the creation of VPN is a handy wizard that greatly simplifies the configuration for those not very familiar with the CLI. Use the command line is still more practical, at least for the basics.
M0n0wall instead for the web interface is very effective and does not use Java, as well as function properly. At this link: http://doc.m0n0.ch/handbook/ipsec-tunnels.html is an online guide for configuring vpn on m0n0wall.
After checking the basic settings are valid, and have also configured the interfaces of the Cisco 1720 router, switch to the VPN. Parameters are chosen peers use to negotiate the tunnel and that will be identical for both firewall riepiloghiamoli below:
Peer address: 10.0.0.1 (side m0n0wall) - 10.0.0.2 (side Pix)
Remote LAN: 192.168.1.0/24 (side m0n0wall) - 172.16.1.0/24 (side Pix)
PSK: abcde
Mode: Tunnel - ESP
IKE policy: 3DES - MD5 - Group 2
Transform set: 3DES - MD5
Certainly this is an exercise and the parameters used are examples: in practice is greater with AES encryption and SHA hashing algorithm is better than MD5. Also use parameters more “driven” means require more computing power at cpu and then lower the overall performance of the firewall. The Pre-Shared Key (PSK) is used, together with the IP address for authentication of peers (and not for encryption).
Once the data set, to establish the tunnel between the firewall you need to create traffic between a LAN and the other: just a “ping-t” from PC1 to PC2 and firewalls automatically negotiate to the vpn. If the configuration is correct, in addition to response to ping the Pix configuration menu shows “Ipsec Tunnels 1″ while on the m0n0wall web interface, under “Diagnostics -> IPsec are visible active SA, a for each flow between firewalls.
Now that is standing vpn connect the PC with Wireshark on board on a switch port, which we appropriately set for the monitoring of ports that are certified interfaces wan firewalls, and we start the sniffer. As you can easily verify there is a continuous traffic of ESP packets between a firewall and the other is the traffic of our ping-t that is encrypted and encapsulated in the ESP protocol, and of course, is incomprehensible. If we analyze an ESP packet will notice that the only clear part is the header, which contains ip source ip and destination, everything else is encrypted.
If now we open a Telnet session from PC1 to Pc3 we will see, on the sniffer packets in transit clear: it can not traffic between the two lan firewall and therefore is not encrypted. Analyzing one of these packages we can clearly see the contents of the payload and recognize the configuration of a router, because Pc3 is actually another Cisco 1720 and Telnet command sent was a show running-config (the details are known password to log in. vty way).
