| OSPF Interface Cost | |||||
| Ref Speed | Ref BW Value | 10mbit link | 100mbit link | 1gbit link | 10gbit link |
| 100mbit | 100 | 10 | 1 | 1 | 1 |
| 1gbit | 1000 | 100 | 10 | 1 | 1 |
| 10gbit | 10000 | 1000 | 100 | 10 | 1 |
| 20gbit | 20000 | 2000 | 200 | 20 | 2 |
| 100gbit | 100000 | 10000 | 1000 | 100 | 10 |
Read more...
Wednesday, 9 December 2009
OSPF Reference Bandwidth Table
Comparison of costs that are returned for various size links when the reference bandwidth is changed.
Read more...
Read more...
Sunday, 29 November 2009
PPPoA Password Retrieval on Netgear DG834
I wanted to install a new firewall on my home DSL connection recently, nothing against the Netgear as it works great, but I had a Juniper box that I wanted to try out. The UK uses PPPoA for home DSL connections so you need a username and password to get onto the network.
The DG834 has a web interface for management, Netgear's own FAQ has help with retrieving that password if you've lost it. Once on there, you can get the basic settings which looks as follows:
The password is starred out.
It's hidden using an HTML password field, which is meant to stop someone looking over your shoulder from seeing what password you type. However that is all it aims to protect against, it's then down to the individual web application as to whether it actually strips the password from the source code...and this Netgear doesn't.
You can use your browsers "view source" option (or "this frame" -> "view source") to read the PPPoA login from the HTML code:
Read more...
The DG834 has a web interface for management, Netgear's own FAQ has help with retrieving that password if you've lost it. Once on there, you can get the basic settings which looks as follows:
The password is starred out.
It's hidden using an HTML password field, which is meant to stop someone looking over your shoulder from seeing what password you type. However that is all it aims to protect against, it's then down to the individual web application as to whether it actually strips the password from the source code...and this Netgear doesn't.
You can use your browsers "view source" option (or "this frame" -> "view source") to read the PPPoA login from the HTML code:
Read more...
Saturday, 31 October 2009
Fixing VirtualBox VRMMRO.r0 Error on Ubuntu
I'd just rebuilt my eeepc recently and decided to install Virtualbox. Unfortunately after installing it from the Ubuntu repository it didn't quite work, giving the error "Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND)".
From googling around it quickly became apparent that there's an easy fix, to uncomment a single line in a Makefile and re-compile the Virtualbox kernel modules. Unfortunately the package on Ubuntu won't recompile due to a mismatch of paths from the package installer and the actual build script.
The suggested steps for a standard install are:
You'll need some extra steps to create various paths that the build script expects on Ubuntu as follows:
You can work out which links are needed by looking at the startup file /etc/init.d/virtualbox-ose, locate the setup section:
BUILDVBOXNETDRV is a variable pointing to the actual build script, it is the install path in the config file /etc/vbox/vbox.cfg, the value ends up being: "/usr/lib/virtualbox/src/vboxdrv/build_in_tmp", which doesn't exist.
If you look in /usr/lib/virtualbox then there is no src path, so create one of those to /usr/src (or you could change the INSTALL_DIR in vbox.cfg but I'm not sure what else that breaks). Then look in /usr/src, no "vboxdrv" directory, so make a link to that. Later in the build you'll run into the same thing for vboxnetflt.
Footnote:
Virtualbox is a great piece of software from Sun, although ESX may be master of the type 1 hypervisor, Virtualbox is (in my opinion) the best type 2 hypervisor around, especially for networking labs. The ability to bind physical NICs to seperate VMs is very handy and being able to do it all from a straightforward GUI in a few minutes is great. It allows Linux and XP to run in parallel on my eeepc and still get 5+ hours battery life.
Read more...
From googling around it quickly became apparent that there's an easy fix, to uncomment a single line in a Makefile and re-compile the Virtualbox kernel modules. Unfortunately the package on Ubuntu won't recompile due to a mismatch of paths from the package installer and the actual build script.
The suggested steps for a standard install are:
Edit src/vboxdrv*/Makefile and uncomment the line: # VBOX_USE_INSERT_PAGE = 1
Then run the script /etc/init.d/vboxdrv setup
You'll need some extra steps to create various paths that the build script expects on Ubuntu as follows:
Edit /usr/src/vboxdrv*/Makefile and uncomment the line: # VBOX_USE_INSERT_PAGE = 1
cd /usr/src
ln -s vboxdrv-2.1.4 vboxdrv
ln -s vboxnetflt-2.1.4 vboxnetflt
cd /usr/lib/virtualbox
ln -s /usr/src .
Run /etc/init.d/virtualbox-ose setup
You can work out which links are needed by looking at the startup file /etc/init.d/virtualbox-ose, locate the setup section:
setup()
{
stop
[snip]
begin_msg "Recompiling VirtualBox kernel module"
if ! $BUILDVBOXDRV \
--save-module-symvers /tmp/vboxdrv-Module.symvers \
--no-print-directory install > $LOG 2>&1; then
failure "Look at $LOG to find out what went wrong"
fi
if ! $BUILDVBOXNETFLT \
--use-module-symvers /tmp/vboxdrv-Module.symvers \
--no-print-directory install >> $LOG 2>&1; then
failure "Look at $LOG to find out what went wrong"
fi
rm -f /etc/vbox/module_not_compiled
succ_msg
start
}
BUILDVBOXNETDRV is a variable pointing to the actual build script, it is the install path in the config file /etc/vbox/vbox.cfg, the value ends up being: "/usr/lib/virtualbox/src/vboxdrv/build_in_tmp", which doesn't exist.
If you look in /usr/lib/virtualbox then there is no src path, so create one of those to /usr/src (or you could change the INSTALL_DIR in vbox.cfg but I'm not sure what else that breaks). Then look in /usr/src, no "vboxdrv" directory, so make a link to that. Later in the build you'll run into the same thing for vboxnetflt.
Footnote:
Virtualbox is a great piece of software from Sun, although ESX may be master of the type 1 hypervisor, Virtualbox is (in my opinion) the best type 2 hypervisor around, especially for networking labs. The ability to bind physical NICs to seperate VMs is very handy and being able to do it all from a straightforward GUI in a few minutes is great. It allows Linux and XP to run in parallel on my eeepc and still get 5+ hours battery life.
Read more...
Friday, 23 October 2009
ASA Site-to-Site VPN Using Certificates from OpenSSL
To provide increased security over pre-shared keys you can authenticate VPN endpoints using certificates. Ideally this would be using a full PKI solution but a simpler method is available if you don't need revocation.
This guide is for the Cisco ASA. As with most things it's a doddle in the ASDM because you can take full advantage of the GUI and be prompted for each step, however I'll show the CLI commands.
I'll use OpenSSL as a CA, following on from the previous article. There is a Cisco guide for using Microsofts CA (search for "asa site-to-site vpn certificate microsoft" if the link dies), but OpenSSL works just as well. This guide pretty much mirrors the Microsoft one above except for the editing of certificates and OpenSSL commands used to sign the certs.
The ASA can run it's own CA, however it seems aimed squarely at supporting remote user VPNs, it doesn't support signing CSRs and the user certificates it outputs are passcode protected so not usable by another ASA in a site-to-site VPN. If Cisco include that functionality it'd be very useful, if they add SCEP features to allow enrollment of devices then it'll be very handy indeed.
The procedure is:
If you've followed the directions from the previous article then the public key is called cacert.pem, open this file in a text editor (wordpad rather than notepad if using Windows). On the ASA configure a CA trust point for terminal enrollment (pasting the key into the terminal), the authenticate command will then prompt you to paste the key:
That's it, the ASA will now trust keys signed by your CA.
You could just use the general keys for this but I'd make a specific key for each VPN. You then need a trustpoint where you can fine tune the certificate options. The enroll command will output the key to console.
Copy this key into a text editor. It'll need the format changed slightly, by default the ASA outputs keys like:
But you need to edit the key so it looks like this:
To sign the key, copy it onto the system you've installed OpenSSL as per the previous guide. Use the following command to sign the CSR, mine's saved in a text file as "FW1-req.txt":
To copy this certificate back to the ASA, import it for the trustpoint created earlier:
The authentication method is configured in the crypto map, this will appear as follows:
The rest of the VPN configuration is the same as pre-shared keys. Congratulations, you've got a certificate based VPN! If it's not working then try with a PSK to verify that the VPN is configured correctly, if that doesn't work then welcome to the wonderful world of debugging VPNs.
Read more...
This guide is for the Cisco ASA. As with most things it's a doddle in the ASDM because you can take full advantage of the GUI and be prompted for each step, however I'll show the CLI commands.
I'll use OpenSSL as a CA, following on from the previous article. There is a Cisco guide for using Microsofts CA (search for "asa site-to-site vpn certificate microsoft" if the link dies), but OpenSSL works just as well. This guide pretty much mirrors the Microsoft one above except for the editing of certificates and OpenSSL commands used to sign the certs.
The ASA can run it's own CA, however it seems aimed squarely at supporting remote user VPNs, it doesn't support signing CSRs and the user certificates it outputs are passcode protected so not usable by another ASA in a site-to-site VPN. If Cisco include that functionality it'd be very useful, if they add SCEP features to allow enrollment of devices then it'll be very handy indeed.
The procedure is:
- Install the CA public key onto the ASA.
- Generate a Certificate Signing Request (CSR) on the ASA.
- Sign the CSR using the CA.
- Install the signed certificate onto the ASA.
- Configure the VPN.
1. Install the CA public key onto the ASA
If you've followed the directions from the previous article then the public key is called cacert.pem, open this file in a text editor (wordpad rather than notepad if using Windows). On the ASA configure a CA trust point for terminal enrollment (pasting the key into the terminal), the authenticate command will then prompt you to paste the key:
crypto ca trustpoint Test_CA
enrollment terminal
crypto ca authenticate Test_CA
* At this point you'll be prompted to paste the CA public key (from cacert.pem) *
That's it, the ASA will now trust keys signed by your CA.
2. Generate a Certificate Signing Request (CSR) on the ASA.
You could just use the general keys for this but I'd make a specific key for each VPN. You then need a trustpoint where you can fine tune the certificate options. The enroll command will output the key to console.
!Generate the RSA key pair
crypto key generate rsa label FW1-Key modulus 1024
!Configure a trustpoint for the signed certificate
crypto ca trustpoint FW1-Key-trustpoint
enrollment terminal
fqdn 10.0.0.1
subject-name CN=10.0.0.1
keypair FW1-Key
crl configure
!output the CSR to console
crypto ca enroll FW1-Key-trustpoint
Copy this key into a text editor. It'll need the format changed slightly, by default the ASA outputs keys like:
MIIBnicE+P+jvc8JQBSbElTZUH8e7ULzXt8KWZQH6M/0U70wp6lqH6caHeCfDgKW
QIDAQABoDMwMQYJKoZIhbvHyAplT4ToJAATL7GwRhXqcmIpxL8k3xjP3XMkzorMZ
mLZdV8X4byX7Z9MlIEU44iWF+nePEJc60RQRgqTiLPqZcyO8besQxh74FVLW5H40
FE1/FceBzgz4ImgXMcC+0DxrNNToS2wZQDoYo7uL5I6hc9KBiV8Ki0drPe7ZOu4G
Pwdq+Ah9axuXtDua8xPe6G1bRQ9dGCgE4NSeQPnSz380WNqv6TZNddZhERlTNDoX
lbDQG0v+k5zJpCktRYa+f18IvJJxY9pVlpD4WKvyRHdaQydtudPejObY9prIg3rU
Gn1aJyCv0mjgF/JH4wnbhXgNbxBk0J1alpIEupq6Xo=
---End - This line not part of the certificate request---
But you need to edit the key so it looks like this:
-----BEGIN CERTIFICATE REQUEST-----
MIIBnicE+P+jvc8JQBSbElTZUH8e7ULzXt8KWZQH6M/0U70wp6lqH6caHeCfDgKW
QIDAQABoDMwMQYJKoZIhbvHyAplT4ToJAATL7GwRhXqcmIpxL8k3xjP3XMkzorMZ
mLZdV8X4byX7Z9MlIEU44iWF+nePEJc60RQRgqTiLPqZcyO8besQxh74FVLW5H40
FE1/FceBzgz4ImgXMcC+0DxrNNToS2wZQDoYo7uL5I6hc9KBiV8Ki0drPe7ZOu4G
Pwdq+Ah9axuXtDua8xPe6G1bRQ9dGCgE4NSeQPnSz380WNqv6TZNddZhERlTNDoX
lbDQG0v+k5zJpCktRYa+f18IvJJxY9pVlpD4WKvyRHdaQydtudPejObY9prIg3rU
Gn1aJyCv0mjgF/JH4wnbhXgNbxBk0J1alpIEupq6Xo=
-----END CERTIFICATE REQUEST-----
3. Sign the CSR using the CA.
To sign the key, copy it onto the system you've installed OpenSSL as per the previous guide. Use the following command to sign the CSR, mine's saved in a text file as "FW1-req.txt":
openssl ca -in FW1-req.txt -out FW1-signed.txt
4. Install the signed certificate onto the ASA.
To copy this certificate back to the ASA, import it for the trustpoint created earlier:
crypto ca import FW1-Key-trustpoint certificate
* Paste in the edited key as per above *
5. Configure the VPN.
The authentication method is configured in the crypto map, this will appear as follows:
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group2
crypto map outside_map 1 set peer 10.0.0.2
crypto map outside_map 1 set transform-set ESP-AES-128-SHA
crypto map outside_map 1 set trustpoint FW1-Key-trustpoint
crypto map outside_map interface outside
The rest of the VPN configuration is the same as pre-shared keys. Congratulations, you've got a certificate based VPN! If it's not working then try with a PSK to verify that the VPN is configured correctly, if that doesn't work then welcome to the wonderful world of debugging VPNs.
Read more...
OpenSSL CA for VPN Certificates
The aim of this article is to provide some pointers to getting a certificate authority (CA) up and running with OpenSSL and provide a few handy commands for reference. This will be used in some future articles about certificate based VPNs.
To do certificate based VPNs you need a couple of things:
I'll use the manual signing procedure which is done in several steps:
I've used the Ubuntu docs project guide to setting up a CA, that can be found here. The instructions should work for any Unix system with OpenSSL.
The only changes I've made to their configuration were the hostname/path/DN changes and to alter policy about which fields needed to be supplied in the CSRs. This is just to save filling out every field each time I want to change certificates in the lab.
With your directory structure created as per that article, config file created and appropriate environmental variables set you have a functional CA.
Generate the CA public and private keys:
Show information on a certificate:
Show information in a CSR:
Verify the signature of a CSR:
Sign a CSR:
Read more...
To do certificate based VPNs you need a couple of things:
- A Certificate Authority (CA) that your end devices trust.
- Host certificates signed by the CA.
I'll use the manual signing procedure which is done in several steps:
- Install the CA public key on the end devices.
- Create a Certificate Signing Request (CSR) on each end device.
- Use the CA to sign the CSR.
- Install the signed certificate back onto the device.
- Configure the VPN to use that certificate for authentication.
I've used the Ubuntu docs project guide to setting up a CA, that can be found here. The instructions should work for any Unix system with OpenSSL.
The only changes I've made to their configuration were the hostname/path/DN changes and to alter policy about which fields needed to be supplied in the CSRs. This is just to save filling out every field each time I want to change certificates in the lab.
[ local_ca_policy ]
commonName = supplied
stateOrProvinceName = optional
countryName = optional
emailAddress = optional
organizationName = optional
organizationalUnitName = optional
With your directory structure created as per that article, config file created and appropriate environmental variables set you have a functional CA.
Handy OpenSSL Commands
Generate the CA public and private keys:
openssl req -x509 -newkey rsa:1024 -out cacert.pem -outform PEM -days 1825
Show information on a certificate:
openssl x509 -text -in <CERT>
Show information in a CSR:
openssl req -text -noout -in <CSR>
Verify the signature of a CSR:
openssl req -text -noout -in <CSR> -verify
Sign a CSR:
openssl ca -in <CSR> -out <SIGNED-CERT>
Read more...
Monday, 19 October 2009
Checkpoint Traffic Sniffing
There are a couple of handy commands for sniffing traffic on Checkpoint.
Tcpdump and fw monitor.
The following runs a tcpdump capture on IPSO, snagging the entire packet to a file:
Without the -s1700 it'll just grab the first part of each packet and not the full contents. If you're running it on a newer platform (e.g. SPLAT) then you can probably use -s0 instead, it's to specify the size of the packets that are recorded.
The problem with tcpdump is that running it on a device designed to filter traffic means you may not be seeing exactly what you expect. So it's probably better to use "fw monitor", the Checkpoint tool that lets you specify exactly where in the stack you are sniffing packets from.
The official guide is here.
Not much more to say about it except to give a simple example for reference:
Just remember to terminate each line with a semi-colon.
Read more...
Tcpdump and fw monitor.
The following runs a tcpdump capture on IPSO, snagging the entire packet to a file:
tcpdump -s1700 -w output.cap -ni <interface> host <IP-addr>
Without the -s1700 it'll just grab the first part of each packet and not the full contents. If you're running it on a newer platform (e.g. SPLAT) then you can probably use -s0 instead, it's to specify the size of the packets that are recorded.
The problem with tcpdump is that running it on a device designed to filter traffic means you may not be seeing exactly what you expect. So it's probably better to use "fw monitor", the Checkpoint tool that lets you specify exactly where in the stack you are sniffing packets from.
The official guide is here.
Not much more to say about it except to give a simple example for reference:
fw monitor -e 'accept src=<src-ip> or dst=<dst-ip>;'
Just remember to terminate each line with a semi-colon.
Read more...
Monday, 28 September 2009
MPLS: EIGRP as CE-PE Routing Protocol
Following the OSPF sham links and OSPF as PE-CE routing protocol articles, this entry shows how to use EIGRP as the PE-CE routing protocol.
The network topology is as before.
EIGRP is fairly easy to configure in this case. The CE router is just configured as per a vanilla EIGRP network with no special entries needed, on router CE1:
On the PE router it is fairly straightforward, EIGRP is configured with an "address-family ipv4 vrf VRFNAME" command. The bit to note is the "autonomous-system X" line which tells the router what EIGRP AS is running in the VRF.
Any show commands on the PE router must include the VRF statement, e.g.:
As with OSPF (solved by sham links), there is potential for problems with EIGRP if you have backdoor links between sites. The administrative distance of EIGRP internal routes is 90 whereas the iBGP routes AD is 200. To avoid this the pre-bestpath cost BGP extended community value is used.
The Cisco article on the cost community is here. Basically it allows the BGP routing decision process to be overridden by the cost community value which is split into two parts, the first being called the POI (Point-of-Insertion) which is the position in the routing process (e.g. before the normal BGP decision hooks such as weight, local pref, route origin) and the second part being a value that is copied from the EIGRP composite metric. This allows routes to be chosen based purely on the EIGRP metric and BGP factors are ignored.
Unlike sham links this is automatically enabled, here is the route to 172.16.2.0 as seen by BGP:
The route is then received on CE1 with an advertised metric of 307200:
Read more...
The network topology is as before.
EIGRP is fairly easy to configure in this case. The CE router is just configured as per a vanilla EIGRP network with no special entries needed, on router CE1:
CE1#show ip int brief | inc up
FastEthernet0/0 10.0.255.1 YES NVRAM up up
FastEthernet0/1 172.16.1.1 YES NVRAM up up
CE1#show run | section eigrp
router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary
On the PE router it is fairly straightforward, EIGRP is configured with an "address-family ipv4 vrf VRFNAME" command. The bit to note is the "autonomous-system X" line which tells the router what EIGRP AS is running in the VRF.
PE1#show run | section eigrp
router eigrp 1
auto-summary
!
address-family ipv4 vrf VPN_ONE
redistribute bgp 65001 metric 10000 20 255 1 1500
network 10.0.255.0 0.0.0.3
no auto-summary
autonomous-system 1
Any show commands on the PE router must include the VRF statement, e.g.:
PE1#show ip eigrp vrf VPN_ONE neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.255.1 Fa0/0 11 00:06:48 6 200 0 5
As with OSPF (solved by sham links), there is potential for problems with EIGRP if you have backdoor links between sites. The administrative distance of EIGRP internal routes is 90 whereas the iBGP routes AD is 200. To avoid this the pre-bestpath cost BGP extended community value is used.
The Cisco article on the cost community is here. Basically it allows the BGP routing decision process to be overridden by the cost community value which is split into two parts, the first being called the POI (Point-of-Insertion) which is the position in the routing process (e.g. before the normal BGP decision hooks such as weight, local pref, route origin) and the second part being a value that is copied from the EIGRP composite metric. This allows routes to be chosen based purely on the EIGRP metric and BGP factors are ignored.
Unlike sham links this is automatically enabled, here is the route to 172.16.2.0 as seen by BGP:
PE1#show ip bgp vpnv4 vrf VPN_ONE 172.16.2.0
BGP routing table entry for 1:1:172.16.2.0/24, version 11
Paths: (1 available, best #1, table VPN_ONE)
Not advertised to any peer
Local
10.255.255.52 (metric 129) from 10.255.255.52 (10.255.255.52)
Origin incomplete, metric 100, localpref 100, valid, internal, best
Extended Community: RT:1:1 Cost:pre-bestpath:128:307200 0x8800:32768:0
0x8801:1:51200 0x8802:65281:256000 0x8803:65281:1500
mpls labels in/out nolabel/23
The route is then received on CE1 with an advertised metric of 307200:
CE1#show ip eigrp top 172.16.2.0 255.255.255.0
IP-EIGRP (AS 1): Topology entry for 172.16.2.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 332800
Routing Descriptor Blocks:
10.0.255.2 (FastEthernet0/0), from 10.0.255.2, Send flag is 0x0
Composite metric is (332800/307200), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 3000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Read more...
Subscribe to:
Posts (Atom)
Posts
