snow: Advanced Configuration Sometimes you want to change the defaults.

Address Pool

The default snow address pool is currently 172.16.0.0/12. In the configuration file (/etc/snow/snow.conf) that would look like this:

NATPOOL_NETWORK=172.16.0.0  
NATPOOL_NETMASK_BITS=12

If those addresses conflict with some you are already using you can choose another range, e.g. for 10.144.0.0/12:

NATPOOL_NETWORK=10.144.0.0  
NATPOOL_NETMASK_BITS=12

There is no need to use the same addresses as anyone else using snow. If you change the default it is recommended that you use at least a /16.

Key Aliases

You can set aliases for keys using DNS CNAME records. Doing this locally is easy and should be reasonably secure. For example to make "alice" an alias for "baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key" you only have to add this line to /etc/sdns/local.names (and restart sdnsd):

CNAME alice baaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key

You can also add CNAME records to the public DNS servers or your organization's local DNS servers. However, be aware that you are then effectively using DNS for key distribution.

DNS servers

sdns is a small DNS server daemon. Generally you run sdns and set your DNS server to localhost (127.0.0.1). sdns is a recursive resolver so you don't have to set a DNS server but doing so will (usually) improve performance. You can put your upstream DNS server in /etc/sdns/forwarders/@. For example to use the Google public DNS servers:

# echo 8.8.4.4 8.8.8.8 > /etc/sdns/forwarders/@

You can also set forwarders for specific domains. This is often useful for corporate VPNs. For example to forward queries for example.com and all subdomains to 10.100.0.5:

# echo 10.100.0.5 > /etc/sdns/forwarders/@example.com

Running sdns with other DNS resolvers

In some cases it may be useful to run sdns on the same machine as some other DNS resolver, e.g.:

By default sdns only binds to the localhost addresses (127.0.0.1 and ::1). If the purpose of the other DNS resolver is to provide service to remote clients then the simple solution is to configure the other resolver to only bind the machine's non-localhost IP addresses. Then you can even forward sdns to the other resolver by setting one of those addresses as its forwarder.

If for some reason you have to have both DNS resolvers on the localhost addresses (for example you want to run a local DNSSEC validating resolver and then forward sdns to it) then you can use the same trick NetworkManager uses for dnsmasq. The entire 127.0.0.0/8 block is (preposterously) allocated to localhost. So you can set some other "localhost" IP address in /etc/sdns/sdns.conf:

BIND4_ADDRS=127.0.1.1
BIND6_ADDRS=

Then set your machine's DNS server to 127.0.1.1 instead of 127.0.0.1 and forward sdns to the other resolver running on 127.0.0.1.

Running sdns with NetworkManager and dnsmasq

Some distributions (like Ubuntu Desktop) have dnsmasq managed by NetworkManager and we don't want to interfere with it. The eventual solution may be to allow sdns to be used with NetworkManager like dnsmasq. The immediate solution is to have sdns sneak in front of dnsmasq. Set dnsmasq to use a different port, set sdns to forward to dnsmasq on that port, and set sdns to listen on the address and port where dnsmasq was:

# echo port=54 >> /etc/NetworkManager/dnsmasq.d/local
# echo 127.0.1.1#54 > /etc/sdns/forwarders/@
# echo BIND4_ADDRS=127.0.1.1 >> /etc/sdns/sdns.conf
# restart network-manager
# killall sdnsd; sdnsd -d

Note that you must do this instead of configuring 127.0.0.1 (or 127.0.1.1) as your DNS server in NetworkManager. Doing this should allow NetworkManager to configure DNS as if sdns isn't even there.

Port Forwarding

snow tries very hard to make NAT traversal work efficiently without requiring any configuration and most of the time it does. But some of the methods that work are not very pretty and there are some simple things you can do to rescue thousands of adorable kittens from mortal danger.

The single easiest thing is to make sure your internet gateway supports NAT-PMP or Port Control Protocol. If it doesn't you should replace it with one that does. If it doesn't but it supports UPnP you should apply heat in a controlled environment until the metallic elements undergo a phase transition, and then replace it with one that does.

The second best thing (if you can't upgrade your gateway) is to manually forward a UDP port. On first run snow chooses a random port and sets it as DTLS_BIND_PORT in /etc/snow/snow.conf. You can leave it or change it to whatever you like. Then forward that port from your gateway to your machine. Also note that NAT traversal works best when each machine is using a different port, so if you have multiple machines or VMs behind the same NAT try to make sure they each use different ports.

It is important to understand that even if the defaults appear to work out of the box that doesn't mean you shouldn't enable NAT-PMP if you can. People with simple networks rarely have any trouble connecting to other people with simple networks. What port forwarding helps is to get you connected with someone whose network is an absurd labyrinthe of double NAT, asymmetric routes and middleboxes created by the Confused Deputies Commission for Standards Contravention.

[snow] [How it works] [How to use it] [How to install it] [Advanced Configuration] [App Development] [Read the FAQ]