This page carries on from MetaNetInstallation, and indirectly from MetaNet. You might want to read those first.

zebra and bgpd

WanDaemon, at low level, provides you with 192.168 addresses. What you want is 10.x.x.x connectivity - so you need to run zebra.

Configuration information is in ZebraConfig. Note: this page may have a slight Debian tint!

Read MetaNetBGPNotes for information describing BGP on the !MetaNet.

At this point you should be able to ping, Hydrogen's !MetaNet address.


Add to your boot scripts somewhere (/etc/network/interfaces is a good place for Debian. Can you tell we love Debian here?):

 route add -net netmask reject
 route add -net netmask metric 1000 reject

This will give you "Destination host unreachable errors", without sending random packets out your default gateway.


After you have zebra working correctly, and you can ping, then you may want to setup DNS (Debian: apt-get install bind). In your name server, you need to make sure you don't have any forwarders1?, and that you have blocks that look much like this:

 zone "" {
  type stub;
  masters {; };
  file "/var/cache/bind/stubs/10.x";

 zone "tla" {
  type stub;
  masters {; };
  file "/var/cache/bind/stubs/tla";

For future use, and resolving metanet routers, also add

 zone "" {
   type stub;
   masters {; };
   file "/var/cache/bind/stubs/192.168.x";

 zone "metaix.tla" {
   type stub;
   masters {; };
   file "/var/cache/bind/stubs/metaix.tla";

as well.

Note: You may wish to change the paths based on your distribution. Debian Woody prefers "/var/cache/bind/stubs", but doesn't create it by default. Make sure the directory you have named in the config file exists on the filesystem!

Note 2: FedoraCore users see FedoraNotes too. You don't need an absolute path for the 'file' part, just the filename will be enough.

You should then be able to restart named(8) (debian: /etc/init.d/bind restart, or reload if it's already running) and then ping "www.tla".

You are now properly on the !MetaNet. You should now be able to visit http://www.tla/

Other clients on your network

Make sure any clients on your network that you want to resolve !MetaNet addresses have the address of your nameserver as the first nameserver in /etc/resolv.conf, or their native DNS configuration. You can put your ISP's nameserver after it as a precaution, if you like.


See FirewallNotes and PerrysFirewallingScript. Although you should be able to mostly trust other people on the metanet, you should at the very least do some basic firewalling.

For example, samba/nmbd does broadcasts that will go across the metanet. You can either block traffic to and from the metanet on ports 137, 138 and 139 (both TCP and UDP) or you can add the following in smb.conf's global section:

  bind interfaces only = yes
  interfaces = 10.x.y.0/24

Note: The following is geared towards a system where the MetaNet router doesn't supply services to the MetaNet, and isn't your desktop, for example. But it can still be used and applied, with (relatively heavy) modification.

The only traffic required on the range for your MetaNet router is BGP. So you can safely firewall off everything except port 179 tcp/udp incoming. You will need to leave outgoing open, and ports >=1024 incoming with stateful acceptance (RELATED,ESTABLISHED) since your MetaNet router will use the IP on the wan0 interface for its communication onto the MetaNet. You'll also need to allow traffic to pass back and forth between and 10.x.y.z/24, but that's in your FORWARD chain.

An example of this is:

  iptables -A INPUT -p udp --dport 179 -s -i wan0 -d 192.168.x.y -j ACCEPT
  iptables -A INPUT -p tcp --dport 179 -s -i wan0 -d 192.168.x.y -j ACCEPT
      <Add extra allowances here, if your MetaNet router is serving services (like DNS, etc)...>
      <you may also want to allow things in from your lan here (ssh!), since the following 4 rules will block them.>
  iptables -A INPUT -p tcp --dport 1:1023 -j REJECT
  iptables -A INPUT -p udp --dport 1:1023 -j REJECT
  iptables -A INPUT -p tcp --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A INPUT -p udp --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A INPUT -p imcp -j ACCEPT
  iptables -A OUTPUT -d -o wan0 -s 192.168.x.y -j ACCEPT
  iptables -A OUTPUT -d -o wan0 -s 192.168.x.y -j ACCEPT
  iptables -A OUTPUT -p imcp -j ACCEPT

The following allows pretty much open slather access from anything on the MetaNet into your 10.x.y.z/24 segment. (change ethX to the NIC with your 10.x.y.z/24 on it):

  iptables -A FORWARD -d -o wan0 -s 10.x.y.z/24 -i ethX -j ACCEPT
  iptables -A FORWARD -d 10.x.y.z/24 -o ethX -s -i wan0 -j ACCEPT
  iptables -A FORWARD -d -o wan0 -s 10.x.y.z/24 -i ethX -j ACCEPT
  iptables -A FORWARD -d 10.x.y.z/24 -o ethX -s -i wan0 -j ACCEPT
  iptables -A FORWARD -p imcp -j ACCEPT

You'll need more than the above in your FORWARD chain if you also run something like NAT for your internet connection on your MetaNet router.

Root CA

The !MetaNet has a CertificateAuthority? that it uses for signing SSL websites and potentially other cool stuff. To add this "root CA" to your browser, visit

Now, go to MetaNetResources to see what you can do with your new internetwork.

[1] The reason is that if you use a forwarder, then all queries for anything other than master/slave zones get forwarded to the other server and you won't be able to resolve metanet names and addresses.