Posts tagged ‘router’

Since none of the dd-wrt releases include ip6tables support, I added it myself. The standard kernel does support module loading, so you can simply add additional kernel features without reflashing the device. You do need some writable storage. I use the remaining 4MB of flash using JFFS, but using an external storage (USB, network, …) is also possible.

Since you can’t run a complete build environment on the router itself, you’ll have to set up a cross-compiling environment on your own machine. As I found out, this isn’t always very easy to do…
Continue reading ‘Compiling custom dd-wrt kernel modules’ »

I bought myself a new WiFi router. When in the shop, I specifically searched for a router that is supported by dd-wrt, and has (at least) 8MB of flash. I settled for the Linksys WRT320N: it has a dual band (switchable between 2.4GHz and 5GHz, not simultaneous) 802.11a/b/g/n radio, a 4 port GbE switch, and a WAN port. It houses a Broadcom BC4717 processor running at 354MHz, 8MB of flash and 32MB of RAM.

The default Linksys firmware is actually not bad, but dd-wrt just offers a ton more features: Multiple SSIDs, IPv6 support (including Sixxs tunneling), WAN volume monitoring, custom firewalling, traffic shaping, … So I decided to void my warranty and put my router on steroids! Mandatory note: this may very well turn your router in to a very expensive brick.

Continue reading ‘Converting a WRT320N to dd-wrt’ »

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’ »

When doing some research on the different tables in iptables, I was trying to figure out in what order what tables are traversed. Obviously PREROUTING happens before POSTROUTING, but it becomes more difficult to figure out if mangle happens before are after nat.

I found a post which links to this overview:

packetflow

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’ »

IPv6 is, big surprise, the new version of IP. The current internet runs on IPv4, which has some drawbacks. Practically both versions are the same: they allow connections from one host to another host. Technically however, there are some major differences, most notably the enlarged address space. For the moment, most hosts will run a dual-stack configuration.

I decided that it was time to implement IPv6 on my home network and get a IPv6 connection to the IPv6-Internet.

Continue reading ‘IPv6 in the home network’ »

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.