Posts tagged ‘Cisco’

To get secure access to internal networks, one usually employs one of the many variants of a VPN. When connecting from a normal computer, you can install basically whatever variant you wish. When using devices such as smartphones however, the number of supported VPN technologies is usually limited. Especially on non-open platforms such as the iDevices by Apple, you can not add VPN software yourself, contrary to the Android platform.

In this post, I’ll explain how to set up an IPsec (without L2TP) tunnel endpoint on an Ubuntu server, capable of handling an iPhone/iPad/iPod/iWhatever. The users will be authenticated against an LDAP directory.

Continue reading ‘iPhone compatible IPsec VPN on an Ubuntu server, with LDAP authentication’ »

I tried to set up a very simple MPLS-cloud with Cisco routers (actually dynamips emulated routers), just as an exercise. For those interested, here is the ZIP-file with the dynagen-net file with router configurations. It includes overlapping IP-space, multiple routing protocols and redistribution.

It is perfectly possible to configure a linux server (or workstation if you wish) to talk IPsec. The Linux Advanced Routing & Traffic Control site has a page describing it. Since IPsec is a standard protocol, I wanted to get a tunnel up and running between a linux host and a Cisco router: with success! Here are the config files that I used in this test:

Continue reading ‘IPsec under Linux’ »

IPsec is becomming the Internet standard for securing IP packets. Instead of manually configuring all the encryption parameters, the keys are usually negatiated between the peers using an ISAKMP (Internet Security Association and Key Management Protocol)/Oakley protocol: IKE (Internet Key Exchange). This post goes into its details.

Continue reading ‘IPsec/ISAKMP negotiation opened up’ »

When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:

  • Security: You don’t want the carrier-network to see your data
  • IP conflicts and/or routing issues: You want to carry private IP addresses (eg 10.0.0.0/8 in IPv4) across a public segment (eg the Internet)
  • Workarounds: for whatever reason you whised that there was a connection between A and B

Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.

Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.

Continue reading ‘Ethernet over IP (L2TP) on Cisco’ »

Everyone that has used the Cisco IOS command line knows this problem. When you mistype a command, the router tries to resolve the “hostname” and you have to wait for 24 very long seconds:

Router#conft
Translating "conft"...domain server (255.255.255.255)
 (255.255.255.255)
Translating "conft"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
Router#

Until recently I used the “no ip domain-lookup” configuration entry to counter this. This disables DNS-lookups altogether, which might not always be what you want. I recently found the proper solution to fix this:

Continue reading ‘Avoiding the typo penalty in Cisco IOS’ »

I was bored of constantly looking for updates on a website. A little googling turned up this nice site. It turns (a part of) a webpage into an RSS feed. Here are the ones I created:

Cisco switches are very verbose in their layer 1 error reporting as shown in the output below:

FastEthernet0/1 is down, line protocol is down
  Hardware is Fast Ethernet, address is 0030.94bd.4041 (bia 0030.94bd.4041)
  MTU 1500 bytes, BW 0 Kbit, DLY 100 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set, keepalive not set
  Duplex setting unknown, Unknown Speed, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:35:31, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1 packets input, 64 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 watchdog, 0 multicast
     0 input packets with dribble condition detected
     3 packets output, 444 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

On this page on the Cisco website, there is a table listing all error counters and their meaning for Ethernet interfaces.

Recently I had to configure a router serving as an IPsec-GRE endpoint. So far, nothing special. The interesting part is that the terminating router is behind a NAT-device which changes the outer IP-header of the IPsec tunnel. Of course, the GRE-header is NOT affected by the NAT (since it is encrypted).

To summarize, the device needs to:

  • terminate an IPsec tunnel between 172.16.2.2 <-> 10.0.0.4 (its own IP); but authenticate as 172.16.2.4
  • terminate a GRE tunnel between 172.16.1.1 <-> 172.16.2.4 (a public IP that is NATed towards it)

The diagram is shown below:

172.16.x.x addresses are “public”; 10.x.x.x are private.

Continue reading ‘Terminating an IPsec-GRE tunnel behind NAT’ »

When studying for my Cisco ISCW exam, I wanted to get somewhat more in-depth information on the different DSL-techniques.

First of all, there are different DSL techniques, ranging from IDSL (providing 144/144kbps) over the popular ADSL (somewhere around 1/10Mbps up/down) up to the newer VDSL variants (around 50Mbps). Within each technique, there are different modulation schemes.

I decided to explore what my Alcatel SpeedTouch modem (now Thomson) had to tell me; here is the report.

Continue reading ‘ADSL technology in Belgium’ »