44Net Wiki - User contributions [en]

IPIP Mesh/Quick Start

2026-03-20T13:10:41Z

Cross: Link to setting up a gateway on OpenBSD

{{DISPLAYTITLE:IPIP Mesh Quick Start (Stub)}}

== What this page is ==
This is an orientation stub for joining the shared IPIP Mesh model on 44Net.
A full quick start procedure is not published yet.

== What you can do today ==
* Confirm that a shared mesh model fits your goals in [[Provisioning Methods|Provisioning Methods]].
* Complete account and verification prerequisites in [[GetStarted|Getting started]] and [[Portal/Sign Up|Portal Sign Up]].
* Identify local or regional peers and gateway expectations via [[Community|Community and mailing lists]].
* Review routing responsibilities in [[Routing|Routing and connectivity]].

== What this page will cover ==
* Prerequisites for mesh participation and peering.
* Endpoint setup expectations and addressing model.
* Shared gateway behavior and traffic flow patterns.
* Operational coordination with regional maintainers.
* Validation and troubleshooting checklist.

== Related pages ==
* [[Provisioning Methods|Provisioning Methods]]
* [[GetStarted|Getting started]]
* [[Routing|Routing and connectivity]]
* [[Community|Community and mailing lists]]
* [[Portal/Request Address Space|Request Address Space]]
* [[Contributing|Contributing]]
* [[Decentralization|How Connect, IPIP Mesh, and BGP fit together]]

== Contribute / next steps ==
If you already operate in the mesh, contribute a minimal reproducible setup path with topology notes and failure modes. Submit through [[Contributing]] so this stub can become a complete Quick Start.

== Older docs and notes ==
Earlier pages that may still be useful:
* [[Gateway]]
* [[Registering Your Gateway]]
* [[Encap.txt]]
* [[Encap.txt/get-encap]]
* [[Rip44d]]
* [[RIP44.lua]]
* [[Amprgw]]
* [[Ampr-ripd]]
* [[Setting up a gateway on Linux]]
* [[Setting up a gateway on OpenBSD]]
* See [[Archive]] for more.
[[Category:Participation Methods]]
[[Category:IPIP Mesh]]
[[Category:Getting Started]]

DNS

2024-06-02T12:37:23Z

Cross:

= DNS: The Domain Name System =

The Domain Name System is the primary mechanism by which symbolic host names, such as ''kz2x.ampr.org'' are translated into numeric host IP addresses, such as 44.44.48.2. It is implemented as a network protocol, with clients sending ''queries'' to servers, that uses the network itself to perform translations. The DNS protocol is an Internet standard that is defined by a set of "Request for Comment" documents, or RFCs; the current revision of the DNS specification is in [https://datatracker.ietf.org/doc/html/rfc1035 RFC1035]. It is used heavily on AMPRNet.

== Historical Background ==

Before DNS, individual sites on the Internet maintained a local mapping of host names to IP addresses in the form of a "hosts" file; this was often a text file resident on each Internet-connected computer. However, this quickly became untenable as the network grew: not only did the file itself become so large as to be unwieldy and slow to search, keeping it up to date required significant effort. Furthermore, coordinating updates from many different organizations, and avoiding name collisions as new hosts were added, added even more complexity.

A clever insight was that the problem could be addressed using the network itself, by providing a network service that could translate between host names and IP addresses. Early work around this idea ultimately lead to the design of the DNS.

== Concepts ==

The DNS uses the client/server model, in which ''client'' machines send name related ''queries'' to DNS ''servers'' scattered around the Internet, which in turn, provide answers. The process of answering a query is called "resolution." Resolved queries may be "cached" by servers for some period of time, called the "time to live" or TTL, given by the source server. The DNS allows clients to make queries for a fixed set of types of information for a particular ''domain name''. For example, one might request make an "address" (or "A") query for a name. For each name, a set of "records" corresponding to these information types name are input by an administrator and held in some DNS server; these are called "resource records" or "RRs".

=== Domains, Zones, and Authority ===

Names are hierarchical, and organized into ''domains'': Starting from ".", the "root", and descending through a "top-level" domain (TLD) such ".org", then through an organizational domain such as "ampr". Each such level forms a "domain", so that ".org" and "ampr.org" are separate domains. This organization provides resilience against collisions, since names need only be unique within a domain, and facilitates separation of administrative concerns.

Collections of domains that fall under a single administrative entity form "zones". A zone is said to be ''authoritative'' for the domains under its control, but not otherwise; non-authoritative data typically comes out of caches established in response to earlier queries. Authoritative responses to queries always override cached data.

Just as domain names are hierarchical, DNS servers are also arranged into a logical hierarchy, where different servers are responsible for providing information about names at different levels of the domain hierarchy; this is done by means of ''NS'' resource records, which point to the name servers for a given domain. At the root are a set of "root servers," the IP addresses of which are well-known: these provide information about top-level domains like ".org", and specifically include NS RRs for the name servers that are known to be authoritative for those domains. Subsequent levels are organized similarly: each server at some level provides information about servers at the next level, and so on.

=== Servers, Resolvers, and Stub Resolvers ===

As mentioned, clients resolve requests for information about domain names by sending queries to servers, but different kinds of servers play different roles:

* Non-Recursive, Authoritative Servers, or just Authoritative Servers, are the ultimate sources of authority for domains under a zone. They only accept queries for the domains in the zones they are authoritative for and answer them either with resolved data or with an error, such as when a query is issued for name that does not exist.
* Resolvers, or Recursive Servers, are intermediaries; they accept "recursive" queries and forward these to other servers until they receive a definitive reply. They then usually cache the results so that subsequent requests for the same query can be answered quickly. The cached data expires once its TTL is exceeded.
* Stub resolvers are small bits of software embedded in client programs that make DNS queries: these program fragments send queries to remote servers and interpret the results, providing them to the rest of the program.

Usually, any program that wants to make use of the DNS will do so via a stub resolver, which will forward the query to some recursive server. The stub resolver learns what recursive server to send its queries to via some administrative mechanism; for example, a DHCP server might supply the IP address of the server to use, or the stub might look in a file on the local system. The name servers the stub sends requests to must be given by IP address; doing otherwise would create a chicken and egg problem, since the whole point is that the DNS is way we translate names into addresses.

= Setting Up a Recursive Resolver on OpenBSD =

[https://www.openbsd.org OpenBSD] is a variant of Unix known for security and a focus on code correctness. It also comes bundled with a high performance caching, validating, recursive DNS resolver package called [https://www.nlnetlabs.nl/projects/unbound/about/ Unbound]. Unbound is easily configured, we will give an example of doing so here.

== Configuring the unbound server ==

The first step is to configure the server by editing its configuration file, <code>/var/unbound/etc/unbound.conf</code>. The format and allowable settings in this file are given in the man page, [https://man.openbsd.org/unbound.conf ''unbound.conf''(5)], but at a high level it contains several sections:

* A <code>server:</code> section allows us to set settings for the server itself.
* A <code>remote-control:</code> section lets setup access for a control client.
* An arbitrary number of optional zone-specific sections that allow us to configure options for those zones. This gives us the ability to forward to specific authoritative servers for a zone and so on.

Here's an example of what a configuration file might look like:

<nowiki>server:
interface: 0.0.0.0
interface: ::0

access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse

access-control: 127.0.0.0/8 allow
access-control: ::1 allow

access-control: 44.0.0.0/9 allow
access-control: 44.128.0.0/10 allow

hide-identity: yes
hide-version: yes

# Perform DNSSEC validation.
auto-trust-anchor-file: "/var/unbound/db/root.key"
val-log-level: 2

# Synthesize NXDOMAINs from DNSSEC NSEC chains.
# https://tools.ietf.org/html/rfc8198
#
aggressive-nsec: yes

# Use TCP for "forward-zone" requests. Useful if you are making
# DNS requests over an SSH port forwarding.
#tcp-upstream: yes

# CA Certificates used for forward-tls-upstream (RFC7858) hostname
# verification. Since it's outside the chroot it is only loaded at
# startup and thus cannot be changed via a reload.
#tls-cert-bundle: "/etc/ssl/cert.pem"

remote-control:
control-enable: yes
control-interface: /var/run/unbound.sock

stub-zone:
name: "ampr.org."
stub-addr: 44.1.1.44
stub-host: ns2.us.ardc.org
stub-host: ns.ardc.org
stub-host: ns1.de.ardc.org
stub-host: a.gw4.uk

stub-zone:
name: "44.in-addr.arpa."
stub-addr: 44.1.1.44
stub-host: ns2.us.ardc.org
stub-host: ns.ardc.org
stub-host: ns1.de.ardc.org
stub-host: a.gw4.uk
stub-first: yes

stub-zone:
name: "128.44.in-addr.arpa."
stub-addr: 44.1.1.44
stub-host: ns2.us.ardc.org
stub-host: ns.ardc.org
stub-host: ns1.de.ardc.org
stub-host: a.gw4.uk
stub-first: yes
</nowiki>

This configuration sets some non-default options in the <code>server:</code> section, such as what interface to listen on for incoming connections, and options for what machines are allowed to send us queries. Here, we listen on all addresses on all interfaces for both IPv4 and IPv6 and we allow any AMPRNet host to send us queries.

The <code>remote-control:</code> section enables and configures a Unix domain socket that allows us to control the unbound daemon with the client control program, <code>unbound-control</code>; this way, we can ask it for performance and usage statistics, force it to flush its cache, etc, without stopping and restarting it.

The most interesting parts are the <code>stub-zone:</code> sections. These allow us to tell unbound about servers that are authoritative for particular zones, bypassing querying through the root for domains under those zones. In the three sections given here, we tell it to query the ARDC-administered non-recursive authoritative servers for the ''ampr.org'', ''44.in-addr.arpa'' and ''128.44.in-addr.arpa'' zones; that is, for anything related to AMPRNet, we forward directly to the authoritative servers.

Note the <code>stub-first: yes</code> lines for the two reverse domains: some reverse domains are ''delegated'' to other services. This line says to try the ARDC servers first, and if those return an error, to perform the standard query from the root.

Once the server is configured, we can enable it by adding a line to <code>/etc/rc.conf.local</code>:

<nowiki>unbound_flags=""</nowiki>

Now, if we reboot, we will find the unbound daemon running the next time we login. We should be able to direct DNS queries to the local server now, and we can edit the <code>/etc/resolv.conf</code> file to include a reference to our unbound instance. For example, our resolv.conf file might look something like:

<nowiki>lookup file bind
domain your-call.ampr.org
search your-call.ampr.org ampr.org
nameserver 127.0.0.1
</nowiki>

Of course, one likely wants to query one's own callsign based subdomain, not "your-call".

Now, other machines can be configured to connect to your unbound instance. Here is an example from a machine at KZ2X:

<nowiki>lookup file bind
domain kz2x.ampr.org
search kz2x.ampr.org ampr.org
nameserver 44.44.48.29
nameserver 8.8.8.8
nameserver 1.1.1.1
</nowiki>

Note that <code>44.44.48.29</code> is the machine that runs unbound.

Congratulations! You have set up a caching, validating, recursive resolver that can serve DNS to any machine on AMPRNet.

DNS

2024-06-02T01:37:28Z

Cross: Add OpenBSD example

= DNS: The Domain Name System =

The Domain Name System is the primary mechanism by which symbolic host names, such as ''kz2x.ampr.org'' are translated into numeric host IP addresses, such as 44.44.48.2. It is implemented as a network protocol, with clients sending ''queries'' to servers, that uses the network itself to perform translations. The DNS protocol is an Internet standard that is defined by a set of "Request for Comment" documents, or RFCs; the current revision of the DNS specification is in [https://datatracker.ietf.org/doc/html/rfc1035 RFC1035]. It is used heavily on AMPRNet.

== Historical Background ==

Before DNS, individual sites on the Internet maintained a local mapping of host names to IP addresses in the form of a "hosts" file; this was often a text file resident on each Internet-connected computer. However, this quickly became untenable as the network grew: not only did the file itself become so large as to be unwieldy and slow to search, keeping it up to date required significant effort. Furthermore, coordinating updates from many different organizations, and avoiding name collisions as new hosts were added, added even more complexity.

A clever insight was that the problem could be addressed using the network itself, by providing a network service that could translate between host names and IP addresses. Early work around this idea ultimately lead to the design of the DNS.

== Concepts ==

The DNS uses the client/server model, in which ''client'' machines send name related ''queries'' to DNS ''servers'' scattered around the Internet, which in turn, provide answers. The process of answering a query is called "resolution." Resolved queries may be "cached" by servers for some period of time, called the "time to live" or TTL, given by the source server. The DNS allows clients to make queries for a fixed set of types of information for a particular ''domain name''. For example, one might request make an "address" (or "A") query for a name. For each name, a set of "records" corresponding to these information types name are input by an administrator and held in some DNS server; these are called "resource records" or "RRs".

=== Domains, Zones, and Authority ===

Names are hierarchical, and organized into ''domains'': Starting from ".", the "root", and descending through a "top-level" domain (TLD) such ".org", then through an organizational domain such as "ampr". Each such level forms a "domain", so that ".org" and "ampr.org" are separate domains. This organization provides resilience against collisions, since names need only be unique within a domain, and facilitates separation of administrative concerns.

Collections of domains that fall under a single administrative entity form "zones". A zone is said to be ''authoritative'' for the domains under its control, but not otherwise; non-authoritative data typically comes out of caches established in response to earlier queries. Authoritative responses to queries always override cached data.

Just as domain names are hierarchical, DNS servers are also arranged into a logical hierarchy, where different servers are responsible for providing information about names at different levels of the domain hierarchy; this is done by means of ''NS'' resource records, which point to the name servers for a given domain. At the root are a set of "root servers," the IP addresses of which are well-known: these provide information about top-level domains like ".org", and specifically include NS RRs for the name servers that are known to be authoritative for those domains. Subsequent levels are organized similarly: each server at some level provides information about servers at the next level, and so on.

=== Servers, Resolvers, and Stub Resolvers ===

As mentioned, clients resolve requests for information about domain names by sending queries to servers, but different kinds of servers play different roles:

* Non-Recursive, Authoritative Servers, or just Authoritative Servers, are the ultimate sources of authority for domains under a zone. They only accept queries for the domains in the zones they are authoritative for and answer them either with resolved data or with an error, such as when a query is issued for name that does not exist.
* Resolvers, or Recursive Servers, are intermediaries; they accept "recursive" queries and forward these to other servers until they receive a definitive reply. They then usually cache the results so that subsequent requests for the same query can be answered quickly. The cached data expires once its TTL is exceeded.
* Stub resolvers are small bits of software embedded in client programs that make DNS queries: these program fragments send queries to remote servers and interpret the results, providing them to the rest of the program.

Usually, any program that wants to make use of the DNS will do so via a stub resolver, which will forward the query to some recursive server. The stub resolver learns what recursive server to send its queries to via some administrative mechanism; for example, a DHCP server might supply the IP address of the server to use, or the stub might look in a file on the local system. The name servers the stub sends requests to must be given by IP address; doing otherwise would create a chicken and egg problem, since the whole point is that the DNS is way we translate names into addresses.

= Setting Up a Recursive Resolver on OpenBSD =

[https://www.openbsd.org OpenBSD] is a variant of Unix known for security and a focus on code correctness. It also comes bundled with a high performance caching, validating, recursive DNS resolver package called [https://www.nlnetlabs.nl/projects/unbound/about/ Unbound]. Unbound is easily configured, we will give an example of doing so here.

== Configuring the unbound server ==

The first step is to configure the server by editing its configuration file, <code>/var/unbound/etc/unbound.conf</code>. The format and allowable settings in this file are given in the man page, [https://man.openbsd.org/unbound.conf ''unbound.conf''(5)], but at a high level it contains several sections:

* A <code>server:</code> section allows us to set settings for the server itself.
* A <code>remote-control:</code> section lets setup access for a control client.
* An arbitrary number of optional zone-specific sections that allow us to configure options for those zones. This gives us the ability to forward to specific authoritative servers for a zone and so on.

Here's an example of what a configuration file might look like:

<nowiki>server:
interface: 0.0.0.0
interface: ::0

access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse

access-control: 127.0.0.0/8 allow
access-control: ::1 allow

access-control: 44.0.0.0/9 allow
access-control: 44.128.0.0/10 allow

hide-identity: yes
hide-version: yes

# Perform DNSSEC validation.
auto-trust-anchor-file: "/var/unbound/db/root.key"
val-log-level: 2

# Synthesize NXDOMAINs from DNSSEC NSEC chains.
# https://tools.ietf.org/html/rfc8198
#
aggressive-nsec: yes

# Use TCP for "forward-zone" requests. Useful if you are making
# DNS requests over an SSH port forwarding.
#tcp-upstream: yes

# CA Certificates used for forward-tls-upstream (RFC7858) hostname
# verification. Since it's outside the chroot it is only loaded at
# startup and thus cannot be changed via a reload.
#tls-cert-bundle: "/etc/ssl/cert.pem"

remote-control:
control-enable: yes
control-interface: /var/run/unbound.sock

stub-zone:
name: "ampr.org."
stub-addr: 44.1.1.44
stub-host: ns2.us.ardc.org
stub-host: ns.ardc.org
stub-host: ns1.de.ardc.org
stub-host: a.gw4.uk

stub-zone:
name: "44.in-addr.arpa."
stub-addr: 44.1.1.44
stub-host: ns2.us.ardc.org
stub-host: ns.ardc.org
stub-host: ns1.de.ardc.org
stub-host: a.gw4.uk
stub-first: yes

stub-zone:
name: "128.44.in-addr.arpa."
stub-addr: 44.1.1.44
stub-host: ns2.us.ardc.org
stub-host: ns.ardc.org
stub-host: ns1.de.ardc.org
stub-host: a.gw4.uk
stub-first: yes
</nowiki>

This configuration sets some non-default options in the <code>server:</code> section, such as what interface to listen on for incoming connections, and options for what machines are allowed to send us queries. Here, we listen on all addresses on all interfaces for both IPv4 and IPv6 and we allow any AMPRNet host to send us queries.

The <code>remote-control:</code> section enables and configures a Unix domain socket that allows us to control the unbound daemon with the client control program, <code>unbound-control</code>; this way, we can ask it for performance and usage statistics, force it to flush its cache, etc, without stopping and restarting it.

The most interesting parts are the <code>stub-zone:</code> sections. These allow us to tell unbound about servers that are authoritative for particular zones, bypassing querying through the root for domains under those zones. In the three sections given here, we tell it to query the ARDC-administered non-recursive authoritative servers for the ''ampr.org'', ''44.in-addr.arpa'' and ''128.44.in-addr.arpa'' zones; that is, for anything related to AMPRNet, we forward directly to the authoritative servers.

Note the <code>stub-first: yes</code> lines for the two reverse domains: some reverse domains are ''delegated'' to other services. This line says to try the ARDC servers first, and if those return an error, to perform the standard query from the root.

Once the server is configured, we can enable it by adding a line to <code>/etc/rc.conf.local</code>:

<nowiki>unbound_flags=""</nowiki>

Now, if we reboot, we will find the unbound daemon running the next time we login. We should be able to direct DNS queries to the local server now, and we can edit the <code>/etc/resolv.conf</code> file to include a reference to our unbound instance. For example, our resolv.conf file might look something like:

<nowiki>lookup file bind
domain your-call.ampr.org
search your-call.ampr.org ampr.org
nameserver 127.0.0.1
</nowiki>

Of course, one likely wants to query one's own callsign based subdomain, not "your-call". Other machines can be configured to connect to your unbound instance; here is an example from a machine at KZ2X:

<nowiki>lookup file bind
domain kz2x.ampr.org
search kz2x.ampr.org ampr.org
family inet6 inet4
nameserver 44.44.48.29
nameserver 8.8.8.8
nameserver 1.1.1.1
</nowiki>

Here, <code>44.44.48.29</code> is the machine that runs unbound.

Services

2024-05-23T18:03:04Z

Cross: Wording consistency.

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| AMPR ||[[Portal]] || https://portal.ampr.org || HTTPS || Used to request allocations, manage user profile information, [[Gateway]] entries, [[Encap.txt]] preferences and ampr.org DNS entries|| NONE
|-
| AMPR ||Website || https://www.ampr.org || HTTPS || AMPRNet Main Page|| NONE
|-
| AMPR ||Wiki || https://wiki.ampr.org || HTTPS || This Wiki|| NONE
|-
| AMPR ||44Net discussion group || https://ardc.groups.io/g/44net || HTTPS || AMPR discussion group|| NONE
|-
| AMPR ||ARDC announcements || https://ardc.groups.io/g/main || HTTPS || ARDC announcements|| NONE
|-
| AMPR ||AMPRNet Gateway [[Amprgw|(AMPRGW)]] || amprgw.ucsd.edu/169.228.34.84 || IP and IPENCAP [[Tunnel]]|| Routes traffic between the public internet and AMPRNet hosts connected via the IPIP mesh and originates [[RIP]] packets || Gateways use IP Protocol 4 (IPENCAP) to receive traffic via AMPRGW. Allocation must be registered in the [[Portal]] with a ampr.org DNS entry, and gateways must run an AMPRNet routing protocol (i.e. [[RIP]]44 or [[munge script]])
|-
| AMPR ||[[RIP]]44 || provided via [https://en.wikipedia.org/wiki/Broadcasting_%28networking%29 broadcast] from 44.0.0.1 to all [[gateway]]s registered in the [[portal]] || Routing Information (modified RIPv2 protocol) || distributed by main AMPRNet Router to multicast address 224.0.0.9|| 1.) an enabled IPENCAP tunnel, and 2.) [[ampr-ripd]] or [[rip44d]] must be running and properly configured on your registered gateway
|-
| AMPR ||[[Encap.txt]] || N/A || Routing Information (EMAIL/FTP/HTTP)|| routing information for download|| file must be must be parsed by a self-developed [[munge script]]
|-
| Various Operators||[[Ampr.org]] DNS and Reverse DNS (44.in-addr.arpa) ||
ns.ardc.net 
a.gw4.uk 
ns2.us.ardc.net 
ns1.de.ardc.net 
(These hosts are authoritative for AMPR.ORG and most of the '[0-191].44.in-addr.arpa' reverse zones. 
 
44.0.0.0/9 thru 44.128.0.0/10 hosts may use dns-mdc.ampr.org (44.60.44.3) as a recursive DNS server. It also has a copy of HAMWAN.ORG 
srv.kz2x.ampr.org (44.44.48.29) is a recursive resolver available to 44.0.0.0/9 and 44.128.0.0/10 
|| DNS || name resolution services||
|-
| Various Operators||Network Tools||
http://whatismyip.ampr.org 
http://yo2tm.ampr.org/nettools.php 
http://kb3vwg-010.ampr.org/tools 
http://speedtest.ampr.org 
|| HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| '''kb3vwg-010.ampr.org''' only available from hosts with an AMPRNet IP address
|-
| Various Operators ||Network Time Protocol || ntp.vk2hff.ampr.org (Stratum 1, AU) time.kz2x.ampr.org (Stratum 1, US) kb3vwg-001.ampr.org (Stratum 2, US) gw-44-137.pi9noz.ampr.org (Stratum 2)|| NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican|| '''kb3vwg-001.ampr.org''' only available from hosts with an AMPRNet IP address '''time.kz2x.ampr.org''' only available from hosts with an AMPRNet IP address
|-
| N1URO ||AMPRNet/RF faxing || http://wiki.ampr.org/wiki/axMail-FAX || Facsimile || Online IP based Facsimile service. You have the ability to send emergency communications from packet via Fax. || [http://axmail.sourceforge.net axMail-FAX] Sofware is here.
|-
| [http://allstarlink.org AllStar Link] || AllStar || http://allstarlink.org || Linking of repeaters || AllStar Link core network services are provided via redundant datacenters using 44net IP space. || [https://wiki.allstarlink.org/wiki/Main_Page ASL wiki]
|-
| N2NOV and G1FEF || Hub_NA and Hub_EU for WWconvers Chat System || 44.68.41.2:3600 convers.g1fef.co.uk:3600 || Telnet || Only connections from other 44Net addresses allowed using port 3600. Stations like JNOS with a built-in local chat server can link to it. Individuals without a local chat portal can use an IRC client to a public IP address that must be arranged with the owner. || None
|-
| N2NOV || AMPRNet NE US Regional Portal || http://n2nov.ampr.org/hamgate.html || HTTP || AMPRNet NE US Regional Portal || None
|-
| [https://flscg.org/ FSG]|| HamWAN Remote || https://flscg.org/2022/04/hamwan-remote/ || VPN/BGP || We provide a VPN based remote site connection to [https://flscg.org/hamwan/ HamWAN Tampa] and can announce your IP space. Performance of over 1gbit/s is possible and we provide an local connection point for amateurs in the South Eastern United States. || https://wiki.w9cr.net/index.php/HamWAN_Remote_Site
|-
| [https://hamwan.org HamWAN]||HamWAN Open Peering||https://hamwan.org/Labs/Open%20Peering%20Policy.html||BGP/IPSec(AH)||We provide IPsec VPN w/ BGP peering + Internet announcing.||
|-}

Services previously available on AMPRNet but no longer actively supported can be viewed on the [[Services/Historic|Historic Services]] page.

Services

2024-05-23T18:01:46Z

Cross: time.kz2x.ampr.org is available.

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| AMPR ||[[Portal]] || https://portal.ampr.org || HTTPS || Used to request allocations, manage user profile information, [[Gateway]] entries, [[Encap.txt]] preferences and ampr.org DNS entries|| NONE
|-
| AMPR ||Website || https://www.ampr.org || HTTPS || AMPRNet Main Page|| NONE
|-
| AMPR ||Wiki || https://wiki.ampr.org || HTTPS || This Wiki|| NONE
|-
| AMPR ||44Net discussion group || https://ardc.groups.io/g/44net || HTTPS || AMPR discussion group|| NONE
|-
| AMPR ||ARDC announcements || https://ardc.groups.io/g/main || HTTPS || ARDC announcements|| NONE
|-
| AMPR ||AMPRNet Gateway [[Amprgw|(AMPRGW)]] || amprgw.ucsd.edu/169.228.34.84 || IP and IPENCAP [[Tunnel]]|| Routes traffic between the public internet and AMPRNet hosts connected via the IPIP mesh and originates [[RIP]] packets || Gateways use IP Protocol 4 (IPENCAP) to receive traffic via AMPRGW. Allocation must be registered in the [[Portal]] with a ampr.org DNS entry, and gateways must run an AMPRNet routing protocol (i.e. [[RIP]]44 or [[munge script]])
|-
| AMPR ||[[RIP]]44 || provided via [https://en.wikipedia.org/wiki/Broadcasting_%28networking%29 broadcast] from 44.0.0.1 to all [[gateway]]s registered in the [[portal]] || Routing Information (modified RIPv2 protocol) || distributed by main AMPRNet Router to multicast address 224.0.0.9|| 1.) an enabled IPENCAP tunnel, and 2.) [[ampr-ripd]] or [[rip44d]] must be running and properly configured on your registered gateway
|-
| AMPR ||[[Encap.txt]] || N/A || Routing Information (EMAIL/FTP/HTTP)|| routing information for download|| file must be must be parsed by a self-developed [[munge script]]
|-
| Various Operators||[[Ampr.org]] DNS and Reverse DNS (44.in-addr.arpa) ||
ns.ardc.net 
a.gw4.uk 
ns2.us.ardc.net 
ns1.de.ardc.net 
(These hosts are authoritative for AMPR.ORG and most of the '[0-191].44.in-addr.arpa' reverse zones. 
 
44.0.0.0/9 thru 44.128.0.0/10 hosts may use dns-mdc.ampr.org (44.60.44.3) as a recursive DNS server. It also has a copy of HAMWAN.ORG 
srv.kz2x.ampr.org (44.44.48.29) is a recursive resolver available to 44.0.0.0/9 and 44.128.0.0/10 
|| DNS || name resolution services||
|-
| Various Operators||Network Tools||
http://whatismyip.ampr.org 
http://yo2tm.ampr.org/nettools.php 
http://kb3vwg-010.ampr.org/tools 
http://speedtest.ampr.org 
|| HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| '''kb3vwg-010.ampr.org''' only available from hosts with an AMPRNet IP address
|-
| Various Operators ||Network Time Protocol || ntp.vk2hff.ampr.org (Stratum 1, AU) time.kz2x.ampr.org (Stratum 1, US) kb3vwg-001.ampr.org (Stratum 2, US) gw-44-137.pi9noz.ampr.org (Stratum 2)|| NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican|| '''kb3vwg-001.ampr.org''' only available from hosts with an AMPRNet IP address '''time.kz2x.ampr.org''' only available to AMPRNet hosts
|-
| N1URO ||AMPRNet/RF faxing || http://wiki.ampr.org/wiki/axMail-FAX || Facsimile || Online IP based Facsimile service. You have the ability to send emergency communications from packet via Fax. || [http://axmail.sourceforge.net axMail-FAX] Sofware is here.
|-
| [http://allstarlink.org AllStar Link] || AllStar || http://allstarlink.org || Linking of repeaters || AllStar Link core network services are provided via redundant datacenters using 44net IP space. || [https://wiki.allstarlink.org/wiki/Main_Page ASL wiki]
|-
| N2NOV and G1FEF || Hub_NA and Hub_EU for WWconvers Chat System || 44.68.41.2:3600 convers.g1fef.co.uk:3600 || Telnet || Only connections from other 44Net addresses allowed using port 3600. Stations like JNOS with a built-in local chat server can link to it. Individuals without a local chat portal can use an IRC client to a public IP address that must be arranged with the owner. || None
|-
| N2NOV || AMPRNet NE US Regional Portal || http://n2nov.ampr.org/hamgate.html || HTTP || AMPRNet NE US Regional Portal || None
|-
| [https://flscg.org/ FSG]|| HamWAN Remote || https://flscg.org/2022/04/hamwan-remote/ || VPN/BGP || We provide a VPN based remote site connection to [https://flscg.org/hamwan/ HamWAN Tampa] and can announce your IP space. Performance of over 1gbit/s is possible and we provide an local connection point for amateurs in the South Eastern United States. || https://wiki.w9cr.net/index.php/HamWAN_Remote_Site
|-
| [https://hamwan.org HamWAN]||HamWAN Open Peering||https://hamwan.org/Labs/Open%20Peering%20Policy.html||BGP/IPSec(AH)||We provide IPsec VPN w/ BGP peering + Internet announcing.||
|-}

Services previously available on AMPRNet but no longer actively supported can be viewed on the [[Services/Historic|Historic Services]] page.

Services/Historic

2024-05-23T18:00:20Z

Cross: time.kz2x.ampr.org works, but was blocked by a firewall rule

Below is a list of historic services that were previously offered by ampr users but are not currently available.

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| N1URO ||Network Tools|| http://n1uro.ampr.org/do.shtml || HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| DNS entry no longer exists
|-
| Various Operators ||Network Time Protocol Server || ns.ardc.net (Stratum 2, UK) server.yo2loj.ampr.org (Stratum 2) f4gve.ampr.org (Stratum 3) ntp1.on3rvh.ampr.org || NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican|| No NTP server configured on host
|-
| OH7LZB ||[[AMPRNet_VPN]] || http://wiki.ampr.org/wiki/AMPRNet_VPN || VPN|| [http://en.wikipedia.org/wiki/OpenVPN OpenVPN]-based || '''Unavailable as of May 2024''' You must have a X.509 certificate issued by [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]. ARRL membership is not required.
|-}

DNS

2024-05-17T12:25:02Z

Cross:

User:Cross

2024-05-17T12:09:11Z

Cross: Cross user page

My name is Dan Cross, call sign KZ2X 
I am an engineer at Oxide Computer Company. 
I have a radio page at https://kz2x.radio 
See also my QRZ biography page at https://qrz.com/db/KZ2X 
You can find out more about me on my personal web page: https://pub.gajendra.net/

Services

2024-05-17T01:05:41Z

Cross: Add KZ2X services

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| AMPR ||[[Portal]] || https://portal.ampr.org || HTTPS || manage [[Gateway]], [[Encap.txt]] preferences and ampr.org domain entries (domain entry functionality still under development)|| NONE
|-
| AMPR ||Website || https://www.ampr.org || HTTPS || AMPRNet Main Page|| NONE
|-
| AMPR ||Wiki || https://wiki.ampr.org || HTTPS || This Wiki|| NONE
|-
| AMPR ||44Net discussion group || https://ardc.groups.io/g/44net || HTTPS || AMPR discussion group|| NONE
|-
| AMPR ||ARDC announcements || https://ardc.groups.io/g/main || HTTPS || ARDC announcements|| NONE
|-
| AMPR ||AMPRNet [[Gateway]] (AMPRGW) || 169.228.34.84 || IP and IPENCAP [[Tunnel]]|| main AMPRNet Router|| Gateways use IP Protocol 4 (IPENCAP) to receive traffic via AMPRGW. Allocation must be registered in the [[Portal]] and gateways must run an AMPRNet routing protocol (i.e. [[RIP]]44 or [[munge script]]).
|-
| AMPR ||[[RIP]]44 || provided via [https://en.wikipedia.org/wiki/Broadcasting_%28networking%29 broadcast] from 44.0.0.1 to all [[gateway]]s registered in the [[portal]] || Routing Information (modified RIPv2 protocol) || distributed by main AMPRNet Router to multicast address 224.0.0.9|| 1.) an enabled IPENCAP tunnel, and 2.) [[ampr-ripd]] or [[rip44d]] must be running and properly configured on your registered gateway
|-
| AMPR ||[[Encap.txt]] || N/A || Routing Information (EMAIL/FTP/HTTP)|| routing information for download|| file must be must be parsed by a self-developed [[munge script]]
|-
| Various Operators||[[Ampr.org]] DNS and Reverse DNS (44.in-addr.arpa) ||
ns.ardc.net 
a.gw4.uk 
ns2.us.ardc.net 
ns1.de.ardc.net 
(These hosts are authoritative for AMPR.ORG and most of the '[0-191].44.in-addr.arpa' reverse zones. 
 
44.0.0.0/9 thru 44.128.0.0/10 hosts may use dns-mdc.ampr.org (44.60.44.3) as a recursive DNS server. It also has a copy of HAMWAN.ORG 
srv.kz2x.ampr.org (44.44.48.29) is a recursive resolver available to 44.0.0.0/9 and 44.128.0.0/10 
|| DNS || name resolution services||
|-
| Various Operators||Network Tools||
http://whatismyip.ampr.org 
http://yo2tm.ampr.org/nettools.php 
http://kb3vwg-010.ampr.org/tools 
http://speedtest.ampr.org 
http://n1uro.ampr.org/do.shtml 
|| HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| NONE
|-
| Various Operators ||Network Time Protocol Server || ns.ardc.net (Stratum 2, UK) ntp.vk2hff.ampr.org (Stratum 1, AU) time.kz2x.ampr.org (Stratum 1, US) kb3vwg-001.ampr.org (Stratum 2, US) gw-44-137.pi9noz.ampr.org (Stratum 2) server.yo2loj.ampr.org (Stratum 2) f4gve.ampr.org (Stratum 3) ntp1.on3rvh.ampr.org || NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican|| AMPRNet hosts have OPEN ACCESS to these time servers
|-
| OH7LZB ||[[AMPRNet_VPN]] || http://wiki.ampr.org/wiki/AMPRNet_VPN || VPN|| [http://en.wikipedia.org/wiki/OpenVPN OpenVPN]-based || You must have a X.509 certificate issued by [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]. ARRL membership is not required.
|-
| N1URO ||AMPRNet/RF faxing || http://wiki.ampr.org/wiki/axMail-FAX || Facsimile || Online IP based Facsimile service. You have the ability to send emergency communications from packet via Fax. || [http://axmail.sourceforge.net axMail-FAX] Sofware is here.
|-
| [http://allstarlink.org AllStar Link] || AllStar || http://allstarlink.org || Linking of repeaters || AllStar Link core network services are provided via redundant datacenters using 44net IP space. || [https://wiki.allstarlink.org/wiki/Main_Page ASL wiki]
|-
| N2NOV and G1FEF || Hub_NA and Hub_EU for WWconvers Chat System || 44.68.41.2:3600 convers.g1fef.co.uk:3600 || Telnet || Only connections from other 44Net addresses allowed using port 3600. Stations like JNOS with a built-in local chat server can link to it. Individuals without a local chat portal can use an IRC client to a public IP address that must be arranged with the owner. || None
|-
| N2NOV || AMPRNet NE US Regional Portal || http://n2nov.ampr.org/hamgate.html || HTTP || AMPRNet NE US Regional Portal || None
|-
| [https://flscg.org/ FSG]|| HamWAN Remote || https://flscg.org/2022/04/hamwan-remote/ || VPN/BGP || We provide a VPN based remote site connection to [https://flscg.org/hamwan/ HamWAN Tampa] and can announce your IP space. Performance of over 1gbit/s is possible and we provide an local connection point for amateurs in the South East || https://wiki.w9cr.net/index.php/HamWAN_Remote_Site
|-
| [https://hamwan.org HamWAN]||[https://hamwan.org/Labs/Open%20Peering%20Policy.html OPP Website]||Open Peering ||BGP feed||We provide IPsec VPN w/ BGP peering + Internet announcing.||
|-}

DNS

2024-05-16T19:52:31Z

Cross: Skeletal DNS page

= DNS: The Domain Name System =

The Domain Name System is the mechanism by which symbolic host names, such as ''kz2x.ampr.org'' are translated into numeric host IP addresses, such as 44.44.48.2. It is heavily used on AMPRNet. Cleverly

DNS is an Internet standard that is defined by a set of "Request for Comment" documents, or RFCs. The current revision of the DNS specification is in [https://datatracker.ietf.org/doc/html/rfc1035 RFC1035].

== Historical Background ==

Before DNS, individual sites on the Internet maintained a local mapping of host names to IP addresses in the form of a "hosts" file; this was often a text file resident on each Internet-connected computer. However, as the network grew, this quickly became untenable: not only did the file itself become so large as to be unwieldy and slow to search, keeping it up to date required significant effort. Furthermore, coordinating updates from many different organizations, and avoiding name collisions as new hosts were added, added even more complexity.

A clever insight was that the problem could be addressed using the network itself, by providing a network service that could translate between host names and IP addresses. Early work around this idea ultimately lead to DNS.

== Concepts ==

The DNS on the client/server model, in which ''client'' machines send name service queries to DNS ''servers'' scattered around the Internet, which in turn, provide answers. The process of answering a query related to a host name is called "resolution." Resolved queries may be "cached" by servers for some period of time, called the "time to live" or TTL, given by the source server.

=== Domains, Zones, and Authority ===

Names are hierarchical, and organized into ''domains'': Starting from ".", the "root", and descending through a "top-level" domain (TLD) such ".org", then through an organizational domain such as "ampr". Each such level forms a "domain", so that ".org" and "ampr.org" are separate domains. This organization provides resilience against collisions, since names need only be unique within a domain, and and facilitating separation of administrative concerns.

Collections of domains that fall under a single administrative entity form "zones". A zone is said to be authoritative for the domains under its control, but not otherwise; non-authoritative data typically comes out of caches established in response to earlier queries. Authoritative responses to queries always override cached data.

=== Servers, Resolvers, and Stub Resolvers ===

As mentioned, clients resolve queries about domain names by sending those queries to servers, but different kinds of servers play different roles:

* Servers, or Authoritative Servers, are the ultimate sources of authority for domains under some zone. They accept queries answer them, either with resolved data or with an error, such as when a query is issued for name that does not exist.
* Resolvers, or Recursive Servers, are intermediaries; they accept "recursive" queries and forward these to other servers until they receive a definitive reply. They then usually cache the results so that subsequent requests for the same query can be answered quickly. The cached data expires once its TTL is exceeded.
* Stub resolvers are small bits of software embedded in client programs that make DNS queries: these program fragments send queries to remote servers and interpret the results, providing them the rest of the program.

Usually, any program that wants to make use of the DNS will do so via a stub resolver, which will forward the query to some recursive server. The stub resolver learns about what recursive server to send its queries to via some administrative mechanism; for example, a DHCP server might supply the IP address of the server to use.

Firewalls

2024-05-04T12:12:02Z

Cross: Mention OpenBSD and PF

Welcome to the Firewall Wiki.

This page is intended to be edited by the community to add use practices, command syntax, etc. regarding firewalling and security on AMPRNet nodes. While each operator is ultimately responsible for the administration of their node, it is highly suggested amongst the [[44Net mailing list]] Community that nodes be firewalled.

== Cisco ==

== DD-WRT ==

DD-WRT uses an iptables-based firewall (see iptables below). Custom rules can be entered at '''Administration > Commands > "Save Firewall"''' on the web GUI.

See:

* https://www.dd-wrt.com/wiki/index.php/Iptables
* https://www.dd-wrt.com/wiki/index.php/Firewall

== D-Link ==

On some D-Link devices, the port forwarding feature allows for the options: TCP, UDP and Other. The "Other" option on these models are capable of Destination NAT of IPENCAP packets.

To enable input of IPENCAP (IP Protocol Number 4) '''Note: this rule is required for other AMPR nodes to initiate inbound traffic to your node.'''

In Port Forwarding on the web GUI:

* Create a new Port Forward
* Enter the LAN IP of your AMPR node
* Select "Other"
* Type the number '''4''' into the field

== iptables ==

'''NOTE:'''

* On an iptables-based firewall, you must enable connection tracking on the tunl0 interface in order to enable Stateful Packet Inspection (i.e. a stateful firewall).
* Since the IPENCAP Linux Kernel Module IPIP is in the kernel, '''you must set the default forwarding policy to DROP or REJECT.'''
* ''If you set your default routing policy to ACCEPT, all packets that have not been explicitly DROPped or REJECTed elsewhere, will route, regardless of firewall policies.''
* '''For most embedded devices, it is suggested to use [[Firewalls#ipset|ipset]] rules instead'''

'''General Bogon rules''' - see: https://en.wikipedia.org/wiki/Bogon_filtering

############################################################
# DROPS IP TRAFFIC THAT'S INVALID ENTERING OR EXITING AMPR
# THIS PREVENTS A GENERAL LOOP
iptables -I FORWARD -i tunl0 -o tunl0 -j DROP
# DROPS OUTBOUND IPs NOT FROM YOUR ALLOCATION (BCP 38)
iptables -t raw -I PREROUTING ! -s 44.xxx.xxx.xxx/xx -i br-amprnet -j DROP
# DROPS ROGUE INBOUND ASSIGNED IPs FROM LOOPING THROUGH tunl0 VIA IPENCAP
iptables -t raw -I PREROUTING -s 44.xxx.xxx.xxx/xx -i tunl0 -j DROP
# DROPS OUTBOUND UNASSIGNED IPs FROM LOOPING THROUGH tunl0 VIA IPENCAP
# YOU MUST ADD A RULE UNDER THIS LINE TO MAKE EXCEPTIONS (BCP 38)
iptables -I FORWARD ! -s 44.xxx.xxx.xxx/xx -o tunl0 -j DROP
############################################################
# DROPS BOGONS ENTERING AMPRNet
# SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
iptables -t raw -I PREROUTING -s 0.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 10.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 100.64.0.0/10 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 127.0.0.0/8 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 169.254.0.0/16 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 172.16.0.0/12 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.0.0.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.0.2.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 192.168.0.0/16 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 198.18.0.0/15 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 198.51.100.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 203.0.113.0/24 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 224.0.0.0/4 -i tunl0 -j DROP
iptables -t raw -I PREROUTING -s 240.0.0.0/4 -i tunl0 -j DROP
# Block of Test AMPRNet Subnet
# iptables -t raw -I PREROUTING -s 44.128.0.0/16 -i tunl0 -j DROP
# (you can optionally block your subnet)
############################################################
# THIS PREVENTS NESTED IPENCAP (BCP 38)
iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP

'''Dynamic IPENCAP Filtering of AMPR Nodes (using iptables)'''

To enable dynamic filtering of IPENCAP (IP Protocol Number 4)

''NOTE:''

* ''This script needs work, see Thu Jan 10 11:09:27 PST 2019 message in the [[44Net mailing list]] archive. Due to extreme overheard running on many devices, the ipset script is suggested instead.''
* This rule (or one of the ipset or static rules below) is required for other AMPR nodes to initiate inbound traffic to your node.

''REQUIRED:''
[[ampr-ripd]] (using the -x and -d arguments), the diff command from the [http://www.gnu.org/software/diffutils/manual/diffutils.html diffutils package] and the [https://www.gnu.org/software/sed/manual/sed.html sed command].

# Place this rule a the last firewall command
# Uncomment sleep command below if the rule does not appear
# as load_ipipfilter.sh is still executing
# sleep 10
# load ipipfilter list rule
iptables -t filter -I INPUT -p 4 -i '''<INTERFACE OF WAN>''' -j ipipfilter

#!/bin/sh
# load encap.txt into ipipfilter list
# by Rob, PE1CHL
# load_ipipfilter.sh

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
AMPRGW="'''<AMPRGW>'''"
gwfile="/tmp/gw"

cd /var/lib/ampr-ripd || exit 1

# Parse encap.txt for Node IPs and place in /tmp/gw
grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u >$gwfile

# Run command to create CHAIN, IF no system output, CHAIN was created
iptables -N ipipfilter 2>/dev/null
if [ $? -eq 0 ]
'''# DO NOT PLACE EMPTY LINES BETWEEN THE TWO COMMANDS ABOVE. ###'''
'''# THE EQUATION ASKS IF THE LAST SYSTEM COMMAND ENTERED ###'''
'''# RETURNS "NOTHING." ADDING A SPACE WILL CHANGE RESULTS OF THE IF COMMAND. ###'''

##The two lines above replace the line below, which does not work on OpenWRT
# if iptables -N ipipfilter 2>/dev/null
##

# IF no system output, THEN flush the CHAIN and add AMPRGW,
# add nodes in encap.txt and a final DROP rule
then
iptables -F ipipfilter
iptables -A ipipfilter -s $AMPRGW -j ACCEPT

while read ip
do
iptables -A ipipfilter -s $ip -j ACCEPT
done <$gwfile

iptables -A ipipfilter -j DROP

# ELSE, the CHAIN already exists, determine changes
# and INSERT new nodes and DELETE old nodes (excluding AMPRGW)
else
iptables -L ipipfilter -n | grep ACCEPT | fgrep -v $AMPRGW | \
sed -e 's/.*-- //' -e 's/ .*//' | sort | diff - $gwfile | \
while read d ip
do
case "$d" in
">")
iptables -I ipipfilter -s $ip -j ACCEPT
;;
"<")
iptables -D ipipfilter -s $ip -j ACCEPT
;;
*)
;;
esac
done
fi

# Delete /tmp/gw when done
rm -f $gwfile

# The full pathname of this script /usr/local/sbin/load_ipipfilter is passed with the new -x
# option to ampr-ripd. It will load the entire filter the first time, and later it will only update
# the filters that have changed. It is required that the -s option is passed as well, so the
# encap.txt file is created by ampr-ripd.

'''Static IPENCAP Filtering of AMPR Nodes'''

To enable input of IPENCAP (IP Protocol Number 4)

''Note:''
* This rule (the dynamic rule above, or the ipset rules) is required for other AMPR nodes to initiate inbound traffic to your node.'''

iptables -t filter -I INPUT -p 4 -i '''<INTERFACE OF YOUR WAN>''' -j ACCEPT

If your AMPR node is downstream, you will create an INPUT '''and''' DNAT forward rule to the destination LAN IP of your AMPR node.

''To enable receipt of [[RIP]]44''

iptables -t filter -I INPUT -p udp -s 44.0.0.1 --sport 520 -d 224.0.0.9 --dport 520 -i tunl0 -j ACCEPT

''Masquerade LAN Subnets to AMPRNet''

* In this instance, eth1 is your 192.168.1.0/24 LAN - (thanks to Brian, N1URO)
''See: https://n1uro.ampr.org/linuxconf/44nat.html''

# NAT setup
iptables -t nat -A POSTROUTING -s 192.168.0/24 -o tunl0 -j MASQUERADE -d 44.0.0.0/8
iptables -A FORWARD -s 192.168.1/22 -i eth1 -o tunl0 -m state --state RELATED,ESTABLISHED -j ACCEPT -d 44.0.0.0/8
iptables -A FORWARD -s 192.168.1/22 -i eth1 -o tunl0 -j ACCEPT -d 44.0.0.0/8

== ipset ==

'''General Bogon rules using ipset''' - see: https://en.wikipedia.org/wiki/Bogon_filtering

#######################BOGON FILTER ########################
ipset create bogons hash:net
# BOGON LIST
# SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
ipset -A bogons 0.0.0.0/8
ipset -A bogons 10.0.0.0/8
ipset -A bogons 100.64.0.0/10
ipset -A bogons 127.0.0.0/8
ipset -A bogons 169.254.0.0/16
ipset -A bogons 172.16.0.0/12
ipset -A bogons 192.0.0.0/24
ipset -A bogons 192.0.2.0/24
ipset -A bogons 192.168.0.0/16
ipset -A bogons 198.18.0.0/15
ipset -A bogons 198.51.100.0/24
ipset -A bogons 203.0.113.0/24
ipset -A bogons 224.0.0.0/4
ipset -A bogons 240.0.0.0/4
# Block of your own AMPRNet Subnet
# ipset -A bogons 44.xxx.xxx.xxx/xx
# Block of Test AMPRNet Subnet
# ipset -A bogons 44.128.0.0/16

(you can optionally block your subnet)

'''Dynamic IPENCAP Filtering of AMPR Nodes (using ipset)'''

To enable dynamic filtering of IPENCAP (IP Protocol Number 4)

''REQUIRED:'' [[ampr-ripd]] (using the -x and -d arguments) and the ipset package.'''

#!/bin/sh
# load encap.txt into ipipfilter list

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

cd /var/lib/ampr-ripd || exit 1

ipset -N ipipfilter hash:ip 2>/dev/null
ipset flush ipipfilter
ipset -A ipipfilter <AMPRGW>

grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u | while read ip
do
ipset -A ipipfilter $ip
done

== Microtik ==

== OpenBSD ==

''See the Instructions for [[Setting up a gateway on OpenBSD]].''

OpenBSD comes with a robust, flexible and highly performant firewall called "PF" that works well on AMPRNet. See https://www.openbsd.org/faq/pf/ for more information.

== OpenWrt ==

''See: [[Firewalls#iptables|iptables]] and [[Firewalls#ipset|ipset]] (above), and the Instructions for [[setting up a gateway on OpenWRT|setting up a gateway on OpenWRT]].''

* the Bogon ipset script is added to '''System > Startup''' on the web GUI - or into the Unified Configuration Interface (UCI) file ''/etc/rc.local''
* [[Firewalls#iptables|iptables]]-based scripts are entered at '''Network > Firewall > Custom Firewall''' on the LuCI web GUI interface - or into the Unified Configuration Interface (UCI) file ''/etc/firewall.user''
* [[Firewalls#ipset|ipset]]-based rules are entered on the command line - into the Unified Configuration Interface (UCI) file ''/etc/config/firewall'' ''(OpenWrt syntax must be used in this file!)''
* '''MSS Clamping is enabled in the Firewall Section, you should enable this on both the AMPRLAN and AMPRWAN interfaces'''

''Adding Bogon drop rule to OpenWrt (using [[Firewalls#ipset|ipset]])''

# in /etc/config/firewall
config rule
option name 'Drop-Bogons_In_AMPRWAN'
option family 'ipv4'
option proto 'all'
option src 'amprwan'
option target 'DROP'
option extra '-m set --match-set bogons src'

''Adding IPENCAP Filtering of AMPR Nodes to OpenWrt (using [[Firewalls#ipset|ipset]])''

# in /etc/config/firewall
config rule
option target 'ACCEPT'
option src 'wan'
option family 'ipv4'
option proto '4'
option name 'Allow-AMPR_IPENCAP'
option extra '-m set --match-set ipipfilter src'

''Adding ICMP Filtering of AMPR Nodes to OpenWrt (using [[Firewalls#ipset|ipset]])''

# in /etc/config/firewall
config rule
option target 'ACCEPT'
option family 'ipv4'
option proto 'icmp'
list icmp_type 'echo-request'
option src '*'
option extra '-m set --match-set ipipfilter src'
option name 'Ping_fromIPENCAPS'

Amprgw

2024-05-04T12:09:46Z

Cross: Suggested edits from KC8QBA.

AMPRGW is amprgw.ucsd.edu, at IP address 169.228.34.84. It is the Internet-to-AMPRNet router.

When initially configuring a local IPENCAP gateway, or when rebooting a gateway, traffic to and from the public internet may be unavailable and/or throttled for up to one hour if AMPRGW detects errors related to the gateway being down.

Additionally, traffic to the public internet will not be passed across the AMPRGW unless it originates from a ARMPNet IP address that has a DNS "A" record in the [[ampr.org]] domain.

OH7LZB VPN

2024-05-04T12:03:28Z

Cross: KC8QBA suggests bolding the sentence about the OH7LZB VPN being down.

The OH7LZB VPN was an experimental method to access the IPIP Mesh using a VPN from anywhere on the Internet. The VPN was openly available to any amateur radio operators who had successfully applied for an X.509 certificate from one of the following Certificate Authorities:

* [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]

As of May, 2024, the OH7LZB VPN appears to no longer be operational.

The Certificate Authority (CA) validates using a relatively strong method that the operator is actually licensed, and gives the operator a cryptographic certificate to prove that. Other services, such as this VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services. The operator can use his private key to sign LoTW log files, or any other information he wishes to communicate, and other parties trusting the CA can use the certificate to check that they have been transmitted by someone who has a private key and a certificate for a callsign from the CA.

If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the VPN will be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.

The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!

The VPN is only used to access the IPIP Mesh. While you're connected to the VPN, the VPN client will only transmit packets from you to the IPIP Mesh via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].

The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.

The VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.

= Getting a certificate from LoTW =

Go through [https://lotw.arrl.org/lotw-help/getting-started/ these simple steps]. After step 4 you're ready to continue with the VPN.

It's going to take some time to validate, and you'll have to do some manual work (especially if you're outside the USA), but that is intentional. It significantly reduces abuse of the system, and increases its security.

= Extracting the certificate from LoTW =

LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.

== Windows ==

* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.
* certs\user contains the '''user certificate'''
* certs\authorities contains an '''intermediate certificate'''
* keys\YOURCALL contains, within some XML, your '''private key'''

Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.

The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).

The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31

0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw
-----END RSA PRIVATE KEY-----

Copy-paste that block to a separate file named '''client.key'''.

== Linux and Mac ==

* ~/.tqsl/certs/user contains the '''user certificate'''
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''

The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:

cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt

The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31

0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw
-----END RSA PRIVATE KEY-----

Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.

= Configuring the VPN =

== Windows: OpenVPN ==

# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.
# Run the installer to install it.
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory.
# Place client.crt and client.key, which were created previously, in the configuration file directory.
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).
# Right-click the OpenVPN toolbar icon and select '''Connect'''.

If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.

To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).

== Linux: OpenVPN ==

=== Ubuntu 15.10 ===

Here is steps to install the VPN to Ubuntu 15.10 destop. Install OpenVPN plugin to network manager.
Open terminal and type

sudo apt-get install network-manager-open vpn-gnome

Then add VPN-connection information to NetworkManager

# Click network manager icon on taskbar
# Edit connections
# Add
# OpenVPN
# Create
#* Connection name: AMPRNet
#* Gateway: amprnet-vpn1.aprs.fi
#* Select proper files to User Certificate, CA certificate and Private key
#* Optionally enter private key password if you are set one
# Click Advanced
#* [x] Use custom gateway port: 1773
#* [x] Use LZO data compression
# Click OK
# Click Save
# Click Close

Now you can connect to VPN

# Click network manager icon on taskbar
# VPN connections -> AMPRNet
# Connection should be established

== Linux (Raspberry PI): OpenVPN ==

Log in to Raspberry Pi console. Install openvpn software.

sudo apt-get install openvpn

Create openvpn client configuration file with your favourite editor to /etc/openvpn/client.conf

<pre>
client
dev tun
proto udp
remote amprnet-vpn1.aprs.fi 1773
resolv-retry infinite
persist-key
persist-tun
ca amprnet-vpn-ca.crt
cert client.crt
key client.key
comp-lzo
verb 3
</pre>

Extract your client certificate and key as explained above section Extracting the certificate from LoTW. Copy your certificate files client.crt and client.key to /etc/openvpn/ . You also need amprnet-vpn-ca.crt which can be found inside this archive
http://he.fi/amprnet-vpn/amprnet-vpn-win.zip . Extract it and copy to /etc/openvpn/

Restart openvpn

service openvpn restart

All done.

== Mac OS X: Tunnelblick ==

# [https://tunnelblick.net/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration

You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.

If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.

To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).

Gateway

2024-05-04T12:02:04Z

Cross: Suggestions from KC8QBA re AMPRGW, and light edits for formatting and grammar

Much of the AMPRNet address space is interconnected via [[gateway|gateways]] that implement IPENCAP ([http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml IP Protocol Number 4]) encapsulated [[tunnel|tunnels]]. These tunnels provide endpoints for the AMPRNet address space allocated to a particular region or end user, effectively forming a mesh network of interconnected tunnels between AMPR subnets. There is a database of all the gateways, their public IP addresses, and the subnets they serve on the [[portal]] that is used to dynamically generate routing information that is distributed to the set of all gateways via modified [[RIP]] advertisements. This database is also regularly copied into a text file called [[encap.txt]] which is basically a routing table describing what subnets can be reached via which gateway.

In order to keep this database up to date, everyone that operates a gateway must register on the [[portal]] and have their gateway(s) assigned to their account and associated with their allocation(s).

In addition to the gateways operated by users who connect via IPENCAP tunnels, traffic exchanged between the ARMPNet mesh and the public Internet is routed via the [[Amprgw]] – please see the [[Amprgw]] page for important details on passing traffic between the public Internet and the IPENCAP tunnel mesh.

Learn how to [[Setting up a gateway on Cisco Routers|set up a Cisco Router gateway]]

Learn how to [[Setting up a gateway on Linux|set up a Linux gateway]]

Learn how to [[setting up a gateway on MikroTik Routers|set up a gateway on MikroTik Routers]]

Learn how to [[Setting up a gateway on OpenBSD|set up an OpenBSD gateway]]

Learn how to [[Setting up a gateway on OpenWRT|set up an OpenWRT gateway]]

FAQ

2024-05-03T17:24:49Z

Cross: Mention that AMPRGW will throttle traffic to a tunnel when it detects errors related to that tunnel.

'''Frequently Asked Questions'''

'''What is AMPRNet?'''

AMPRNet stands for AMateur Packet Radio NETwork. It is a collection of amateur radio-oriented computers, connected together via a variety of technologies, including radio, Internet, and ethernet. However, all of these computers have an IP address that begins with 44 (that is, IP addresses of the form 44.0.0.0/9 or 44.128.0.0/10). For this reason, AMPRnet can also be referred to as 44Net.

Some further details can be found at https://en.wikipedia.org/wiki/AMPRNet and https://wiki.ampr.org/wiki/Main_Page

'''What is AMPRNet for?'''

The purpose of AMPRNet is to permit experimentation by amateurs in digital networking and to provide computer services to other amateurs using AMPRNet.

'''What does it cost to use AMPRNet?'''

There is no cost for using any AMPRNet facilities, however, there may be costs associated with Internet access to reach AMPRNet and/or amateur radio equipment costs.

'''How do I connect to AMPRNet?'''

There are four main methods people use:

* VPN
* BGP routing (See Also [[Announcing your allocation directly]])
* Direct radio links.
* IP Tunneling

Note: Functionally, a VPN and a tunnel do much the same thing, except a VPN is designed for privacy (i.e. strong authentication and encryption), whilst IP tunnelling in the AMPRNet context is actually an all-to-all interconnected mesh of tunnels and is not encrypted (as often the data is transferred over radio).

'''What is IP Tunneling?'''

The information that traverses the Internet does so as "packets" of data, traveling over a variety of routes, between a source and a destination. Each packet contains a header, which tells all the devices along the route information such as the source and destination, plus the payload, which is the data to actually be transferred. Clearly, there must be a path all the way from the sources to the destination, and back.
AMPRNet consists of small, non-connected groups of computers, that would otherwise not be able to connect to one another. However, since internet devices along the route really don't care about the contents of the payload section, you can put a completely new packet into that section, including an entirely different header, and its own payload section. That second header has source and destination addresses completely different from the first header - all that is required is that the first destination recognizes the encapsulated packet, de-encapsulates it, and forwards it to the second header destination. Return traffic follows a corresponding process. In that way, 44-net hosts can communicate with other 44-net hosts, by means of encapsulating their data packets in packets to non-44net hosts. This is called tunneling (or encapsulating). A later section in this FAQ discusses installing a tunnel.
Tunneling is probably the most commonly used method of accessing AMPRNet.

'''How does AMPR over IP tunnel actually work?'''

AMPR nodes are actually not connected via a single tunnel but via a large mesh network of tunnels. Suppose user1 has public IP address 198.51.100.1 and user2 has 203.0.113.1. These two can normally communicate over the internet. However, if both users have a 44net IP address, user1 can encapsulate the 44 packet into an outer packet and send it to 203.0.113.1. Similarly, user2 can encapsulate the IP packet with the 44net addresses and send it to 198.51.100.1. In Linux (and most other systems), this is accomplished using a single ipip device and adding a route using the "nexthop" statement. When a packet is pushed into the ipip device, the outer IP header is added and sent to the router in the nexthop statement. A list of all AMPR users is required and this can be either accomplished by downloading a simple textfile and adding the routes manually or by using RIP44, as discussed in the FAQ section below.

'''What is a VPN?'''

VPN stands for Virtual Private Network. It is a facility that enables a computer to act (using the Internet) as though is physically connected to another computer network. There are many different ways to set up a VPN, so this is beyond the scope of this FAQ. However, it always involves configuring software and accounts on a computer, to connect to the VPN server. Some amateurs who have connections to AMPRNet have set up VPN servers so that other amateurs can achieve a "virtual" connection to AMPRNet. The technical details, account details, and IP address details must be obtained from the operator of that VPN. One such VPN is listed at https://wiki.ampr.org/wiki/AMPRNet_VPN.

'''What is BGP Routing?'''

The Internet has millions of different computers connected to it, each having an address. Devices called routers deliver traffic between computers and can send "advertisements" to other routers to tell those other routers about the locations of some of those addresses. The protocol used is called BGP, Border Gateway Protocol. If you are fortunate enough to have a computer that can send BGP advertisements, then you can advertise that your computer is part of the AMPRNet address range, and hence receive AMPRNet traffic.

Unfortunately, most companies and most commercial ISPs will not permit their users to originate BGP advertisements (especially for address ranges that are not in their usual address range), so BGP is not a viable means to connect to AMPRNet for most people. There are Virtual Private Server (VPS) Providers (or Cloud Providers) who will announce your AMPRNet allocation without the need for your own Autonomous System (AS) number. [[Routing your allocation via BGP]] has a list of VPS/Cloud Providers.

Installing BGP is beyond the scope of this FAQ. Note however that you must have written permission from the administrator of the ARDC 44 address space, before you BGP advertise any part of that space.

'''What about radio links?'''

In many places, groups of amateurs have established networks of radio links, and often have used one of the preceding approaches so that those radio networks connect to and become part of AMPRNet. You would need to contact those groups regarding frequencies, modes, and address allocations.

'''Do I need to consider security?'''

Yes! Any computer connected to the Internet must be configured and maintained in a secure fashion, and this includes any computer connected to AMPRNet (regardless of the connection technique). Repeat - you MUST secure your computer! This includes using firewalls, keeping software up to date, using strong passwords, etc etc. In some cases, encryption may also be used.

How to maintain security is beyond the scope of this FAQ. Searching for "How to secure my computer" will return many, many hits though!

'''How do I get an address allocation?'''

If you connect to an existing VPN or existing radio network, it is likely that the operators of those facilities will already have address ranges established and will allocate your address(es). If you wish to establish a new tunnel or BGP-based link, then the process is handled by a semi-automated process on our portal. The steps are:
1. Register using your callsign on the portal https://portal.ampr.org
2. Log in and navigate to the Networks page.
3. Click on your country. A list of regions/subnets may appear; if so, click on the appropriate one.
4. Click on the subnet and you'll be presented with a simple form to complete.
5. If you are requesting a single address for a host, leave the netmask as /32;
6. if you are requesting a block/subnet, select the appropriate netwidth. E.g. for a 256 host subnet, select /24.
7. Put a short message explaining your request in the Message area of the form. Be sure to indicate
if you are planning to directly route a subnet as these require special handling
8. Click Send. Your request will be forwarded to the coordinator for your region/subnet. You'll
receive a confirming email. The coordinator may contact you for further details if required.

'''Can I have a domain name entry for my AMPRNet host?'''

Yes. Currently, domain name requests are handled by the area coordinators - contact details are on the portal. Note: the old email robot facility no longer functions.

'''What about IPv6?'''

There is no IPv6 equivalent of AMPRNet at present.

'''How do I configure a Tunnel?'''

The technique varies according to the Operating System you use. However, all involve the creation of a new "pseudo" interface - unlike your normal ethernet network connection, this one doesn't actually exist on the back panel of your computer. However, it exists as far as the Operating System is concerned. A normal ethernet device accepts a data packet (consisting of a header and payload, as previously discussed) and sends it out the ethernet cable (often via a modem, to the Internet). A "pseudo" interface however accepts a data packet, encapsulates it in the data portion of a new packet, adds a new and different header, and passes all that to the ethernet device, which then processes this new data packet as normal, sending it to a recipient who will de-encapsulate it. Reception of tunneled traffic is the reverse process.

Consequently, two requirements apply:

a) The computer must have full connectivity to the non-44 hosts that will send or receive the tunneled packets containing 44-net traffic. You cannot route ALL traffic to the pseudo interface!

b) The pseudo driver must have a mechanism to tell it which non-44 net hosts can handle particular subsets of 44-net traffic - very few can handle the entire 44-net range! It should be noted that the information changes quite frequently, as tunnel hosts come and go, so must be updated as described below.

https://wiki.ampr.org/wiki/Main_Page has links to several different ways of configuring tunnels.

'''How do I obtain and maintain a list of tunnel hosts?'''

There are three main mechanisms:

a) log on to the portal (as described above) and navigate to the "Gateways/List" section that permits downloading of the "encap" file. Download that file, and use a script on the computer to turn it into commands that update the configuration of the tunnel device.

b) receive the encap file by mail, and use a script to process it. You can register for this email on the portal "Gateways/Options" page.

c) Receive and process "broadcasts" of configuration data that are available. This information is broadcast to all gateways listed on the portal. There is a software package called "ampr-ripd" that enables this process

'''Can I just route all 44net traffic via a single tunnel?'''

No. The main AMPRNet gateway does not provide this functionality - you must have a tunnel to each system you wish to contact.

'''What is the AmprGW?'''

The AmprGW is a server run by ARDC at UCSD as part of a long-running Internet research project. It has a number of functions:

a) It provides a selective gateway between non-AMPRNet internet devices and the IPIP (mesh) AMPRNet. For this traffic, it filters at the per-host(/32) level. Each host which is to receive traffic from the Internet into AMPRNet must individually be listed in the permissions file, which is built from the AMPR.ORG DNS 'A' records. If there is no DNS A record for a tunneled amprnet destination host, the traffic is not forwarded in either direction. Therefore, if you want hosts on your subnet to be able to communicate with the Internet, you will need to have your local coordinator add them to the AMPR.ORG DNS for you.

b) It forwards traffic between Internet hosts (including those AMPRNet that are directly connected to the Internet [BGP-routed]) and IPIP tunneled AMPRNet hosts. Some "validity" filtering is applied during this process - traffic that is invalid or misconfigured will be dropped. Note: AmprGW does NOT forward between different IPIP tunneled AMPRNet hosts. That is why you cannot have just a single IPIP tunnel for all of AMPRNet. Thus the tunneled AMPRNet as a whole forms a fully-connected mesh, not a 'star' configuration.

c) AmprGW originates RIP44 broadcasts containing routing information about gateways and the AMPRNet subnets they service. The RIP44 transmissions are sent as IPIP encapsulated UDP packets for port 520 from 169.228.34.84 and sent individually to the commercial (external) address of every gateway. The packets have an inner source address of 44.0.0.1 and an inner destination of 224.0.0.9, the RIP multicast address. They are IPIP encapsulated packets, so without de-encapsulating them, the RIP is not visible to conventional routing software. Specialized software such as 'ampr-ripd' may be employed to make use of the RIP44 broadcasts, to set up AMPRNet routes.

'''I rebooted my router and now I can't talk to the Internet, what's going on?'''

If AMPRGW detects errors when attempting to send traffic to a tunnel's configured gateway, it will automatically throttle traffic through that tunnel for approximately one hour. This is meant to prevent endlessly sending traffic to gateways that are no longer in service. An example of the sort of errors that will trigger this are ICMP Host Unreachable messages generated by an upstream provider, such as an ISP. Empirically, several users have observed that rebooting a gateway can pause traffic long enough for this to happen. However, traffic will start flowing again in an hour or so.

'''Can BGP, VPN, and IP tunnel hosts inter-communicate?'''

Yes. The AMPRNet gateway has been configured to support this functionality.

'''Can I put my tunnel on my home LAN and use NAT?'''

Yes. However, in general, a home modem using NAT won't be able to correctly process inbound tunneled 44-net traffic and forward it to the correct host - the "port forward" facility in most NAT devices relies on a port number, but there are no port numbers for a tunnel packet! However, most modems have a "DMZ" facility, whereby all unrecognized traffic (and this includes tunneled traffic) can be forwarded to one particular host on the LAN. That host can then be configured to recognize and correctly process tunneled data. However - security alert! - it will also be exposed to all sorts of other, unwanted traffic as well! See the Security section above.

'''Can I use an AMPRNet VPN on my home LAN?'''

Generally, yes. Most home modem/routers have good support for VPN usage, although you mustn't use it for general internet access as it is for amateur radio use only!

'''How can I get help with AMPRNet issues?'''

Many amateurs are willing to assist other hams. You can find some of them on the groups.io 44Net group here https://ardc.groups.io/g/44net

'''What about 44.128.0.0/16?'''

Subnet 44.128.0.0/16 is currently reserved for testing. No operational subnets are planned for this address space. Older documentation incorrectly referred to this block of addresses as "private", that is, unrouted like the 192.168.0.0/16 RFC1918 subnet. This is incorrect; the 44.128.0.0/16 subnet can be routed, but do not use it except for brief test purposes.

'''Credits'''

This FAQ was originally commenced by Steve VK5ASF, using material from earlier FAQs, from various contributors to the 44net mailing list, and from Brian Kantor.

Amprgw

2024-05-03T17:16:21Z

Cross: Mention that AMPRGW will throttle traffic if a router reboots.

AMPRGW is amprgw.ucsd.edu, at IP address 169.228.34.84. It is the Internet-to-AMPRNet router.

Note that, if AMPRGW detects errors for an endpoint, it will throttle traffic to that endpoint for approximately one hour. Often, rebooting a gateway system will be enough to trigger this behavior.

OH7LZB VPN

2024-05-03T17:14:08Z

Cross: KC8QBA reports on the 44Net mailing list that the OH7LZB VPN is no longer working; mention that on the wiki page.

The OH7LZB VPN was an experimental method to access the IPIP Mesh using a VPN from anywhere on the Internet. The VPN was openly available to any amateur radio operators who had successfully applied for an X.509 certificate from one of the following Certificate Authorities:

* [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]

As of May, 2024, the OH7LZB VPN appears to no longer be operational.

The Certificate Authority (CA) validates using a relatively strong method that the operator is actually licensed, and gives the operator a cryptographic certificate to prove that. Other services, such as this VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services. The operator can use his private key to sign LoTW log files, or any other information he wishes to communicate, and other parties trusting the CA can use the certificate to check that they have been transmitted by someone who has a private key and a certificate for a callsign from the CA.

If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the VPN will be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.

The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!

The VPN is only used to access the IPIP Mesh. While you're connected to the VPN, the VPN client will only transmit packets from you to the IPIP Mesh via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].

The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.

The VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.

= Getting a certificate from LoTW =

Go through [https://lotw.arrl.org/lotw-help/getting-started/ these simple steps]. After step 4 you're ready to continue with the VPN.

It's going to take some time to validate, and you'll have to do some manual work (especially if you're outside the USA), but that is intentional. It significantly reduces abuse of the system, and increases its security.

= Extracting the certificate from LoTW =

LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.

== Windows ==

* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.
* certs\user contains the '''user certificate'''
* certs\authorities contains an '''intermediate certificate'''
* keys\YOURCALL contains, within some XML, your '''private key'''

Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.

The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).

The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31

0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw
-----END RSA PRIVATE KEY-----

Copy-paste that block to a separate file named '''client.key'''.

== Linux and Mac ==

* ~/.tqsl/certs/user contains the '''user certificate'''
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''

The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:

cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt

The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31

0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw
-----END RSA PRIVATE KEY-----

Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.

= Configuring the VPN =

== Windows: OpenVPN ==

# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.
# Run the installer to install it.
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory.
# Place client.crt and client.key, which were created previously, in the configuration file directory.
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).
# Right-click the OpenVPN toolbar icon and select '''Connect'''.

If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.

To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).

== Linux: OpenVPN ==

=== Ubuntu 15.10 ===

Here is steps to install the VPN to Ubuntu 15.10 destop. Install OpenVPN plugin to network manager.
Open terminal and type

sudo apt-get install network-manager-open vpn-gnome

Then add VPN-connection information to NetworkManager

# Click network manager icon on taskbar
# Edit connections
# Add
# OpenVPN
# Create
#* Connection name: AMPRNet
#* Gateway: amprnet-vpn1.aprs.fi
#* Select proper files to User Certificate, CA certificate and Private key
#* Optionally enter private key password if you are set one
# Click Advanced
#* [x] Use custom gateway port: 1773
#* [x] Use LZO data compression
# Click OK
# Click Save
# Click Close

Now you can connect to VPN

# Click network manager icon on taskbar
# VPN connections -> AMPRNet
# Connection should be established

== Linux (Raspberry PI): OpenVPN ==

Log in to Raspberry Pi console. Install openvpn software.

sudo apt-get install openvpn

Create openvpn client configuration file with your favourite editor to /etc/openvpn/client.conf

<pre>
client
dev tun
proto udp
remote amprnet-vpn1.aprs.fi 1773
resolv-retry infinite
persist-key
persist-tun
ca amprnet-vpn-ca.crt
cert client.crt
key client.key
comp-lzo
verb 3
</pre>

Extract your client certificate and key as explained above section Extracting the certificate from LoTW. Copy your certificate files client.crt and client.key to /etc/openvpn/ . You also need amprnet-vpn-ca.crt which can be found inside this archive
http://he.fi/amprnet-vpn/amprnet-vpn-win.zip . Extract it and copy to /etc/openvpn/

Restart openvpn

service openvpn restart

All done.

== Mac OS X: Tunnelblick ==

# [https://tunnelblick.net/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration

You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.

If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.

To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).

Setting up a gateway on OpenBSD

2024-04-28T02:19:56Z

Cross: Specify use of the `-cloning` flag when creating routes.

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -cloning</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-cloning</code> flags indicate that this is an interface route, that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address, and that routes should be dynamically cloned when used. We can examine this route from the command line. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHCSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHCSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not decapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface will be accepted, decapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet subnets we have manually configured tunnels for, but suffers from a number of deficiencies. In particular, the following two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be decapsulated and delivered into our subnet. However, return traffic will be sent to the local router, but since the destination is generally not a tunnel, it will be sent via the default route, but with an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However this creates a new problem: how does the encapsulated traffic from the tunnel interface get sent to our ISP's gateway? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our local router's external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it and even if delivered, it wouldn't match the destination address of the original ICMP echo request packet anyway.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality lets us dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to or coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

<code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -cloning
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHCSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code>. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured. The <code>-D</code> and <code>-T</code> options set the routing domains for ''gif'' interfaces and their associated tunnels, respectively.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

User:Cross

2021-11-10T01:33:14Z

Cross: Correct callsign.

My name is Dan Cross. I am an engineer at Oxide Computer Company. My call sign is KZ2X and you can find out more about me on my personal web page: http://pub.gajendra.net/

Setting up a gateway on OpenBSD

2021-06-30T02:17:14Z

Cross: Minor grammar tweaks

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not decapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface will be accepted, decapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet subnets we have manually configured tunnels for, but suffers from a number of deficiencies. In particular, the following two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be decapsulated and delivered into our subnet. However, return traffic will be sent to the local router, but since the destination is generally not a tunnel, it will be sent via the default route, but with an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However this creates a new problem: how does the encapsulated traffic from the tunnel interface get sent to our ISP's gateway? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our local router's external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it and even if delivered, it wouldn't match the destination address of the original ICMP echo request packet anyway.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality lets us dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to or coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

<code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code>. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured. The <code>-D</code> and <code>-T</code> options set the routing domains for ''gif'' interfaces and their associated tunnels, respectively.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-06-16T13:00:16Z

Cross: Mainly grammar and typographical errors fixed.

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not decapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface will be accepted, decapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet subnets we have manually configured tunnels for, but suffers from a number of deficiencies. In particular, the following two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be decapsulated and delivered into our subnet. However, return traffic will be sent to the local router, but since the destination is generally not a tunnel, it will be sent via the default route, but with an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However this creates a new problem: how does the encapsulated traffic from the tunnel interface get sent to our ISP's gateway? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our local router's external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it and even if delivered, it wouldn't match the destination address of the original ICMP echo request packet anyway.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

<code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code>. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured. The <code>-D</code> and <code>-T</code> options set the routing domains for ''gif'' interfaces and their associated tunnels, respectively.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-01-21T13:20:23Z

Cross:

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to find match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not de-encapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface, will be accepted and de-encapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet directly-configured AMPRNet subnets, but suffers from a number of deficiencies. In particular, there are two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be de-encapsulated and delivered into our subnet. However, return traffic will be sent to the router, but since the destination is generally a tunnel, it will be sent via the default route, but from an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is how reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However, how does the encapsulated traffic from the tunnel interface get sent to our ISP's router? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

<code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code>. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured. The <code>-D</code> and <code>-T</code> options set the routing domains for ''gif'' interfaces and their associated tunnels, respectively.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-01-11T17:45:07Z

Cross:

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to find match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not de-encapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface, will be accepted and de-encapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet directly-configured AMPRNet subnets, but suffers from a number of deficiencies. In particular, there are two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be de-encapsulated and delivered into our subnet. However, return traffic will be sent to the router, but since the destination is generally a tunnel, it will be sent via the default route, but from an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is how reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However, how does the encapsulated traffic from the tunnel interface get sent to our ISP's router? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

<code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured. The <code>-D</code> and <code>-T</code> options set the routing domains for ''gif'' interfaces and their associated tunnels, respectively.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-01-11T17:32:22Z

Cross:

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to find match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not de-encapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface, will be accepted and de-encapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet directly-configured AMPRNet subnets, but suffers from a number of deficiencies. In particular, there are two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be de-encapsulated and delivered into our subnet. However, return traffic will be sent to the router, but since the destination is generally a tunnel, it will be sent via the default route, but from an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is how reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However, how does the encapsulated traffic from the tunnel interface get sent to our ISP's router? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

<code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Announcing your allocation directly

2021-01-09T00:42:54Z

Cross: Link to AMPRNet terms of service uses HTTPS, not HTTP.

NOTE: Direct announcements of AMPRNet address allocations are usually reserved for larger regional or country wide networks. Please consult with your regional allocation coordinator and the AMPRNet network administrator to determine whether directly announcing your AMPRNet allocation is appropriate.

To announce your allocation directly via your Internet Service Provider (ISP) you will need to:

# Contact your ISP and ask them if they are willing to announce your AMPRNet allocation in accordance with the terms of the [https://www.ampr.org/terms-of-service/ AMPRNet Terms of Service and Acceptable Use]. Many ISPs won't do this, and others charge a significant amount for the service.
# Apply for your AMPRNet allocation via the [[Portal]]. Check the Direct box to indicate that your connection will be using a direct announcement of the subnet (via the BGP protocol).
# Upon verification and approval, the AMPRNet administrator will provide authorization to your ISP allowing them to announce your allocation.

NOTE: How your ISP chooses to forward traffic for your AMPRNet allocation varies by ISP. You will have to work with them to set this up.

NOTE: Upon approval, [[ARDC]] issues a no-cost lease for up to five years (renewable on request and providing the use case remains valid) for the subnet. This includes a letter of authority that should be provided to your ISP. ARDC does NOT [[SWIP]] subnet allocations.

RIP

2021-01-08T17:13:50Z

Cross:

Information about other AMPRNet [[gateway| gateways]] can now be received dynamically via modified [http://en.wikipedia.org/wiki/Routing_Information_Protocol RIPv2] advertisements. Previously, routes were obtained by creating a [[munge script]] that parsed [[Encap.txt]].

= What's the difference? =

There is a big difference in how the packets are processed.

The regular RIPv2 sets a route to a specific subnet via the sender and
interface where the RIP broadcast was received on. The gateway
information is used only as an optimization element, in case a route
with to that gateway already exists so that the one with the lower
metric gets chosen.

In our case, we use the RIP announcements to transport the subnet AND
gateway information.

= Detailed description =

So, assuming a point to multipoint interface, if there is let's say an
announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0
interface, regular RIPv2 would translate this to:

44.128.0.0/24 via 44.0.0.1 if ipip0

while ampr rip would translate this to:

44.128.0.0/24 via 1.2.3.4 if ipip0

In the first case, traffic to 44.128.0.0/24 is sent directly to the
gateway (the RIP sender), while in the second case it is encapsulated to
1.2.3.4.

On a mikrotik router it even goes a step further:
it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates
a route

44.128.0.0/24 via ampr-1.2.3.4

This is the processing in the usual case, for 44 subnets having a 44net
gateway we assume that the gateway is published by BGP and is directly
reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there
are 2 route set:

44.128.0.1 via default-gw (which is autodetected), and
44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation

So, while the information structure in both cases conforms to the RIPv2
specifications, its usage is completely different.

= RIP44 Daemons =

Two programs are available for GNU/Linux to utilize these updates:

* [[ampr-ripd]], a C based routing daemon
* [[rip44d]], a PERL based routing daemon

A program is also available for [https://www.openbsd.org/ OpenBSD]:

* [https://github.com/dancrossnyc/44ripd 44ripd]

= Availability/Compatibility =

The RIP44 daemons have been tested and known to work on the following operating systems:

* BSD
* OpenWRT/LEDE
* Raspbian
* Slackware Linux
* Ubuntu/Debian Linux
* Vyatta/VyOS

= Non-RIP44 Workarounds =

The devices below do not possess a known, end-user method to install additional software (i.e. ampr-ripd). Operators have developed scripts to parse inbound routing packets to make them compatible for usage on AMPRNet:

* Cisco IOS (a separate machine must run the script) : look here http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Cisco_Routers at the "Making the route commands automatically" section
* JunOS
* MikroTik : look here http://www.yo2loj.ro/hamprojects/ at the "Mikrotik RIPv2 AMPR Gateway Setup Script 3.0"
* Ubiquiti OS

= See Also =

* [[startampr]] - a script that loads the routing daemon on boot on Linux server-type devices
* Instructions for [[setting up a gateway on Linux|setting up a tunnel gateway on Linux]]
* Instructions for [[setting up a gateway on OpenWRT|setting up a gateway on OpenWRT]]
* Instructions for [[setting up a gateway on OpenBSD|setting up a gateway on OpenBSD]]

RIP

2021-01-08T17:12:20Z

Cross:

Setting up a gateway on OpenBSD

2021-01-08T17:10:34Z

Cross:

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to find match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not de-encapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface, will be accepted and de-encapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet directly-configured AMPRNet subnets, but suffers from a number of deficiencies. In particular, there are two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be de-encapsulated and delivered into our subnet. However, return traffic will be sent to the router, but since the destination is generally a tunnel, it will be sent via the default route, but from an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is how reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However, how does the encapsulated traffic from the tunnel interface get sent to our ISP's router? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

</code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [https://www.openbsd.org/faq/pf/ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-01-08T14:20:46Z

Cross:

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to find match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not de-encapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface, will be accepted and de-encapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet directly-configured AMPRNet subnets, but suffers from a number of deficiencies. In particular, there are two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be de-encapsulated and delivered into our subnet. However, return traffic will be sent to the router, but since the destination is generally a tunnel, it will be sent via the default route, but from an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is how reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However, how does the encapsulated traffic from the tunnel interface get sent to our ISP's router? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

</code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured.

=== Set the Default AMPRNet Tunnel and Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-01-08T14:20:14Z

Cross:

== Introduction ==

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel and route to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif1 create
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84
ifconfig gif1 inet 44.44.107.1 netmask 255.255.255.255
route add -host 44.0.0.1 -link -iface gif1 -llinfo</nowiki>

The first command creates the interface, causing the kernel to synthesize it into existence. The second configures the tunnel itself: that is, the the IP addresses that will be put into the IPENCAP datagram that the tunnel creates: the first address is the ''local'' address, which will serve as the source address for the IPENCAP packet, while the second is the ''remote'' address, to which the packet will be sent. The third sets an IP address for the local endpoint of the interface: this exists solely so that traffic that is generated by the router, such as ICMP error messages (host or port unreachable, for example), have a valid source address. Note that despite the fact that this is a point-to-point interface, we do not specify the IP address of the remote end.

The fourth and final command creates a host route and associates it with the tunnel interface. The <code>-link</code>, <code>-iface</code> and <code>-llinfo</code> flags indicate that this is an interface route, and that traffic for the route should go directly to the given interface (<code>gif1</code>) instead of identifying the gateway via an IP address. We can examine this route from the commandline. E.g.,

<nowiki>$ route -n show -inet | grep '44\.0\.0\.1 '
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1</nowiki>

Consult the manual page for [https://man.openbsd.org/netstat.1 ''netstat''(1)] for details on what the <code>UHLSh</code> flags mean.

We can repeat this process for each AMPRNet tunnel, creating interfaces and adding routes for each subnet.

== Handling Encapsulated Inbound Traffic Without a Reciprocal Tunnel ==

When an inbound IPENCAP datagram arrives on our external interface, the network stack in the OpenBSD kernel recognizes it by examining the protocol number in the IP header: IPENCAP is protocol number 4 (not to be confused with IP version 4). Any such packets are passed to the packet input function in the ''gif'' implementation, which searches all configured ''gif'' interfaces trying to find match the configured tunnel source and destinations addresses with the corresponding addresses in the inbound packet. If such an interface is found, the packet is enqueued to the interface, which will strip the IPENCAP header and route the resulting "de-encapsulated" IP packet. This works for tunnels that are configured bidirectionally between any two sites. That is, if site A has a tunnel to site B, and B has a corresponding tunnel to A, they can send each other traffic.

Now consider the case where site A has a tunnel configured to send traffic to site B, but B has no tunnel configured to A: in this case, the datagram arrives as before and is presented to the ''gif'' implementation, but the search above fails since B has no tunnel to A, so nothing matches the source ''and'' destination addresses on the incoming packet. In this case, the system might be responsible for routing such packets to another computer or network, so the packet is not de-encapsulated and processed. However, in an AMPRNet context, we very well may want to process that packet. Accordingly, the ''gif'' implementation has a mechanism for describing an interface that accepts encapsulated traffic from any source destined to a local address. If we configure a ''gif'' interface where the distant end of the ''tunnel'' set to <code>0.0.0.0</code>, then any incoming datagram where the destination address is the same as the local address on the interface, will be accepted and de-encapsulated and processed as before. Using this, we can set up an interface specifically for accepting traffic from systems to which we have not defined a tunnel:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 0.0.0.0
ifconfig gif0 inet 44.44.107.1 255.255.255.255</nowiki>

Note the <code>0.0.0.0</code> as the remote address in the <code>ifconfig tunnel</code> command. Again, we set an interface address using our local AMPRNet router address purely for locally generated traffic.

One this interface is configured, IPENCAP traffic from remote systems that have defined tunnels to us will flow, regardless of whether we have created a tunnel to them.

== Policy-based Routing Using Routing Domains ==

The configuration explored so far is sufficient to make connections to AMPRNet directly-configured AMPRNet subnets, but suffers from a number of deficiencies. In particular, there are two issues that we will discuss now.

First, there is a problem with exchanging traffic with non-AMPRNet systems on the Internet. Presumably, these systems are not aware of AMPRNet tunneling, so traffic from them goes to the gateway at UCSD, where it will be encapsulated and sent through a tunnel to the external interface on our router. There, it will be de-encapsulated and delivered into our subnet. However, return traffic will be sent to the router, but since the destination is generally a tunnel, it will be sent via the default route, but from an AMPRNet source address. Since most ISPs will not pass AMPRNet traffic, the result will likely be lost before it reaches the destination. We may think it would be possible to work around that using a firewall rule to NAT the source address to something provided by our ISP, but even if the resulting datagram made it to the destination, for a protocol like TCP it would no longer match the 5-tuple for the connection, and would thus be lost.

The second problem is how reaching AMPRNet systems for which we have not configured a tunnel. Without a tunnel, and thus a route, we cannot send traffic to those systems.

We can solve both of these problems by sending all of our traffic through a tunnel interface to the UCSD gateway by default, e.g., by setting the default route:

<nowiki>route add default 4.0.0.1</nowiki>

However, how does the encapsulated traffic from the tunnel interface get sent to our ISP's router? We can add a host route for the UCSD gateway in our local routing table, but we have to do this for every tunnel, which is unwieldy. Further, connecting to our external interface becomes complicated: suppose someone <code>ping</code>s our external interface. Assuming we permit this, the response would be routed through the UCSD gateway tunnel, but even if the gateway passed arbitrary traffic back onto the Internet, the packet might be lost as upstream ISPs would refuse to route it.

The solution to all of these problems is to use [https://en.wikipedia.org/wiki/Policy-based_routing ''policy-based routing'']. Specifically, we would like to make routing decisions based on the source IP address of our traffic. We might be able to do this with firewall rules, but the edge cases get complicated very quickly. Fortunately, there is another way: [https://man.openbsd.org/rdomain.4 routing domains].

Routing domains in OpenBSD are a mechanism to isolate routing decisions from one another. Network interfaces are configured into exactly one routing domain, which has its own private set of routing tables. Those tables are isolated, but traffic can be passed between routing domains via firewall rules.

In our example, we put our external and local AMPRNet gateway interfaces into separate routing domains: all of the ''gif'' interfaces and the local AMPRNet gateway interface can both be assigned to routing domain 44, while the external interface might be 23. Routing domain 0 is the default. Note that the numbers here are arbitrary, and we can choose any value below 256 that we like; these are chosen to match the first octet of our example addresses.

The routing domain on an interface is set using the <code>rdomain</code> parameter to <code>ifconfig</code>:

<nowiki>ifconfig cnmac0 rdomain 23
ifconfig gif0 rdomain 44
ifconfig gif1 rdomain 44</nowiki>

We set the default route in the routing domain that owns our external interface to our ISP's router, while in the routing domain hosting our AMPRNet presence we can set it to the UCSD gateway:

<nowiki>route -T 23 add default 23.30.150.242
route -T 44 add default 44.0.0.1</nowiki>

Now traffic on our AMPRNet subnet will be routed through the UCSD gateway, while traffic on the external interface will be routed through our ISP's router.

Another piece of functionality allows us to dispense with much of the complexity of routing between domains: the tunnel assigned to a ''gif'' can be in a different routing domain than the interface itself. Going back to our example, if we place each of our ''gif'' interfaces into routing domain 44 then traffic routed out to on coming in from the tunnel will be routed with our AMPRNet-specific routing table. But if we place the tunnel on that interface into routing domain 23, then the encapsulated traffic that we send to and from the Internet (e.g., to other tunnel end points) will be routed in that domain, thus routing through our ISP's network. Critically, matching incoming datagrams to ''gif'' interfaces as described above happens in the routing domain associated with the tunnel, so inbound traffic coming through our external interface will be directed to the correct interface.

We specify the routing domain of a tunnel via the <code>tunneldomain</code> parameter to <code>ifconfig</code> when configuring the route on an interface:

<nowiki>ifconfig gif0 tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
ifconfig gif1 tunnel 23.30.150.141 169.228.34.84 tunneldomain 23</nowiki>

With this in place, routing works as expected for all of the cases mentioned above.

== Persistent Configuration Across Router Restarts ==

We now have enough information that we can set up tunnels between our router and arbitrary AMPRNet subnets. However, doing so manually is tedious and not particularly robust. We would like the system to automatically configure our tunnels and default routes at boot time. Fortunately, the OpenBSD startup code can do this easily. For each network interface <code>$if</code> on the system, we can configure it automatically at boot time by putting configuration commands into the file <code>/etc/hostname.$if</code>.

There are four interfaces we have configured: the two ethernet interfaces for our external and AMPRNet networks, and the two ''gif'' interfaces with the default incoming tunnel and the tunnel to the UCSD gateway. Thus, there are four files:

<code>/etc/hostname.cnmac0</code>:

<nowiki>rdomain 23
inet 23.30.150.141 0xfffffff8
!ifconfig lo23 inet 127.0.0.1
!route -qn -T 23 add default 23.30.150.142</nowiki>

<code>/etc/hostname.cnmac2</code>:

<nowiki>rdomain 44
inet 44.44.107.1 255.255.255.0
!ifconfig lo44 inet 127.0.0.1</nowiki>

<code>/etc/hostname.gif0</code>:

<nowiki>rdomain 44
tunnel 23.30.150.141 0.0.0.0 tunneldomain 23
inet 44.44.107.1 255.255.255.255</nowiki>

</code>/etc/hostname.gif1</code>:

<nowiki>tunnel 23.30.150.141 169.228.34.84 tunneldomain 23
inet 44.44.107.1 255.255.255.255
!route -qn -T 44 add 44.0.0.1/32 -link -iface gif1 -llinfo
!route -qn -T 44 add default 44.0.0.1</nowiki>

Note that each routing domain also has its own associated loopback interface, hence configuring <code>lo23</code> and <code>lo44</code>. These interfaces are automatically created when the routing domain is created, but we configure them when we bring up the associated ethernet interfaces.

We can examine the interfaces and separate routing tables to ensure that things are set up as expected:

<nowiki>$ ifconfig cnmac0
cnmac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 23 mtu 1500
lladdr 44:d9:e7:9f:a7:64
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143
$ ifconfig cnmac2
cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> rdomain 44 mtu 1500
lladdr 44:d9:e7:9f:a7:66
index 3 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 6 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 0.0.0.0 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> rdomain 44 mtu 1280
index 7 priority 0 llprio 3
encap: txprio payload rxprio payload
groups: gif
tunnel: inet 23.30.150.141 -> 169.228.34.84 ttl 64 nodf ecn rdomain 23
inet 44.44.107.1 --> 0.0.0.0 netmask 0xffffffff
$ route -T 23 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 23.30.150.142 UGS 0 51126 - 8 cnmac0
23.30.150.136/29 23.30.150.141 UCn 1 7 - 4 cnmac0
23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 88377 - 1 cnmac0
23.30.150.142 4a:1d:70:de:c3:5a UHLch 1 386 - 3 cnmac0
23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo23
$ route -T 44 -n show -inet
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 44.0.0.1 UGS 0 54718 - 8 gif1
44.0.0.1 link#7 UHLSh 1 2 - 8 gif1
44.44.107/24 44.44.107.1 UCn 16 4 - 4 cnmac2
44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 4825 - 1 cnmac2
44.44.107.255 44.44.107.1 UHb 0 0 - 1 cnmac2
127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo44</nowiki>

== Restricting Traffic with the [ PF] Firewall ==

All of these interfaces will fully integrate with the PF firewall software that comes with OpenBSD, and we can implement nearly arbitrary policies in our configuration. For example, we might restrict traffic on the external interface to only ICMP messages and IPENCAP datagrams by setting the following rules in <code>/etc/pf.conf</code>:

<nowiki># Constants
extif = "cnmac0"
extamprgate = "23.30.150.141"

# Options
set skip on lo
set block-policy return

block return # block stateless traffic
pass # establish keep-state

# Normalize incoming packets.
match in all scrub (no-df random-id max-mss 1440)

# By default, block everything. We selectively override in subsequent rules.
block in on $extif

# Pass 44net traffic
pass in on $extif inet proto ipencap from any to $extamprgate

# Pass ping and ICMP unreachable messages on external interface
pass in on $extif inet proto icmp icmp-type echoreq code 0 keep state
pass in on $extif inet proto icmp icmp-type unreach keep state</nowiki>

We can verify that these rules are in place as expected by querying the rule tables:

<nowiki># pfctl -sr -vv
@0 block return all
[ Evaluations: 115977 Packets: 3776 Bytes: 168422 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@1 pass all flags S/SA
[ Evaluations: 115977 Packets: 242418 Bytes: 25899015 States: 253 ]
[ Inserted: uid 0 pid 31812 State Creations: 102105]
@2 match in all scrub (no-df random-id max-mss 1440)
[ Evaluations: 115977 Packets: 261105 Bytes: 31394491 States: 136 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@3 block return in on cnmac0 all
[ Evaluations: 64726 Packets: 5925 Bytes: 325492 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@4 pass in on cnmac0 inet proto icmp all icmp-type echoreq code 0
[ Evaluations: 8149 Packets: 342 Bytes: 27424 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 171 ]
@5 pass in on cnmac0 inet proto icmp all icmp-type unreach
[ Evaluations: 308 Packets: 5 Bytes: 368 States: 0 ]
[ Inserted: uid 0 pid 31812 State Creations: 0 ]
@6 pass in on cnmac0 inet proto ipencap from any to 23.30.150.141
[ Evaluations: 8149 Packets: 126197 Bytes: 16538717 States: 5 ]
[ Inserted: uid 0 pid 31812 State Creations: 2048 ]</nowiki>

A site can add more elaborate rules as desired.

== Maintaining Mesh Routes with 44ripd ==

The above shows how to set up AMPRNet tunnel interfaces, set routes to them, use routing domains for policy-based routing, and set firewall rules. However, so far all of these steps have been manual. This works for a handful of tunnels and routes, but there are hundreds of subnets AMPRNet in the AMPRNet mesh; maintaining all of these manually is not reasonable.

However, Dan Cross (KZ2X) has written a daemon specific to OpenBSD called <code>44ripd</code> that maintains tunnel and route information as distributed via the [https://wiki.ampr.org/wiki/RIP AMPRNet RIP] variant sent from <code>44.0.0.1</code. To use this, make sure that multicasting is enabled on the host by setting <code>multicast=YES</code> in <code>/etc/rc.conf.local</code>, and then retrieve the 44ripd software from Github at https://github.com/dancrossnyc/44ripd. The software is built with the <code>make</code> command. For example:

<nowiki>git clone https://github.com/dancrossnyc/44ripd
cd 44ripd
make
doas install -c -o root -g wheel -m 555 44ripd /usr/local/sbin</nowiki>

Once installed, this can be run at boot by adding the following lines to <code>/etc/rc.local</code>:

<nowiki>if [ -x /usr/local/sbin/44ripd ]; then
echo -n ' 44ripd'
route -T 44 exec /usr/local/sbin/44ripd -s0 -s1 -D 44 -T 23
fi</nowiki>

Note that the <code>-s</code> options instruct the daemon not to try and allocate the <code>gif0</code> and <code>gif1</code> interfaces, as these are manually configured.

=== Set the Default AMPRNet Route Manually ===

While route information for the UCSD AMPRNet gateway is distributed in RIP44 packets and we could in theory only configure the default incoming tunnel and rely on 44ripd to set up a route to UCSD, this leads to a problem. Specifically, without an interface configured to the UCSD gateway, we cannot set a default route in our AMRPNet routing domain for the gateway. Since we rely on periodic route broadcasts from UCSD to set those routes, we would delay setting up our default route for an indeterminate amount of time (on the order of minutes).

Thus, it is advised to explicitly configure the tunnel to UCSD at boot time along with the default route.

=== Notes on 44ripd Implementation ===

* 44ripd maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree).
* A similar table of tunnels is maintained.
* Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
* Routes are expired after receiving a RIP packet.
* The program is completely self-contained in the sense that it does not fork/exec external commands to configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.
* 44ripd does not examine the state of the system or routing tables at startup to bootstrap its internal state, but arguably should.
* Bugs in 44ripd should be reported via Github issues.
* Exporting and/or parsing an encap file would be nice.
* Logging and error checking can always be improved.

Setting up a gateway on OpenBSD

2021-01-08T03:35:48Z

Cross:

Setting up a gateway on OpenBSD

2021-01-08T00:12:38Z

Cross:

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

* A dedicated static IP address to use as an endpoint for AMPRNet traffic.
* An ISP-provided router that is just a router; no NATing, no firewall.
* An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
*# cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
*# cnmac1 connects to an internal network (its configuration is irrelevant)
*# cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel to the AMPRNet gateway at UCSD:

<nowiki>ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 169.228.34.84
ifconfig gif0 inet 44.44.107.1 netmask 255.255.255.255
route add 44.0.0.1 -link -iface gif0 -llinfo</nowiki>

Once I had a tunnel up to UCSD, I found that I could ping my
44.44.107.1 machine from a host on my internal network, but not
from arbitrary machines. This was interesting; it turns out that
hosts on my internal network get NAT'ed to another IP address on
the small subnet I got from Comcast (through another, completely
separate router -- not comcast's router but another ERL). What was
happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
ICMP echo request packets got NAT'ed to this other address and
routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
external interface of my AMPRNet gateway. The gateway accepted the
encapsulated ICMP echo requests (I have a PF rule that explicitly
allows ping) and forwarded them across the tunnel interface where
they were unencapsulated; the IP stack saw that the result was
addressed to an IP address on a local interface (i.e., they were
for the router) and generated an ICMP echo response packet with a
*source* address of 44.44.107.1 and a *destination* address of the
external address of my other router (that is, the address the ICMP
echo request was NAT'ed to). This matched the network route for
my local Comcats subnet and so my AMPRNet router realized it could
pass the packet back to my other router directly. It did so and
the other router happily took the packet, matched it back through
the NAT back to the original requesting machine (my laptop) and
forwarded it: hence, I got my ping responses back. But note that
the response was not going through the tunnel back to UCSD: it was
being routed directly through the external interface.

Now consider what happens when I tried to ping 44.44.107.1 from
a different machine on some other network. The ICMP echo request
packet gets routed through the UCSD gateway and tunneled back to
my gateway as before, but since responses don't go through back
through the tunnel, the response packet matches the default route
of my gateway and get's forwarded to comcast's router. Comcast
would look at it, see that 44.44.107.1 wasn't on one of it's known
networks that it would route floor, and discard the response. Oops.

The solution was to set up a separate routing table in a different
routing domain specifically for AMPRNet traffic, and tie the two
together using firewall rules. In the AMPRNet routing table, I
could set my default route to point to the UCSD gateway, so any
traffic sent from one of my 44.44.107.0/24 addresses that doesn't
match a route to a known tunnel gets forwarded through
amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
from random machines. This must seem obvious to a lot of folks
here, but it took me a little while to figure out what was going
on. Things are working now, however.

So far I have encountered two other caveats: I decided to
configure two tunnel interfaces statically at boot time: 'gif0'
goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
his 44.88 net. Under OpenBSD, I assumed that the natural way to
do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
files and this does in fact create the tunnels at boot time. However,
traffic going out from my gateway doesn't seem to get sent through
the tunnels; I did not bother to track down exactly why, but I
believe it has to do with some kind of implicit ordering dependency
when initializing PF. When I set up the separate routing domain,
it struck me that the language accepted by /etc/netstart in an
/etc/hostname.if file was not sufficiently rich to set up tunnels
in a routing domain, so I capitulated and just set up the static
interfaces from /etc/rc.local; imperfect but it works.

The second caveat is that I seem to have tickled a kernel error
trying to set up an alias of a second IP address on my 44.44.107.1
NIC; I get a kernel panic due to an assertion failure. It looks a
bug to me, but I haven't had the bandwidth to track it down. In
the meanwhile, simply don't add aliases to interfaces in non-default
routing domains.

The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others.

A couple of quick notes on implementation:

# The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet.
# A similar table of tunnels is maintained.
# Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
# The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.

There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.

It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd

Setting up a gateway on OpenBSD

2021-01-08T00:11:27Z

Cross:

Setting up a gateway on OpenBSD

2021-01-08T00:09:07Z

Cross:

[https://www.openbsd.org OpenBSD] is a mature Unix-like operating system that focuses on security and correctness. It features a flexible, robust, performant TCP/IP stack and a [https://www.openbsd.org/faq/pf/ highly configurable firewall]. This page describes how to configure a computer running OpenBSD as an AMPRNet router to transfer traffic between AMPRNet subnets and the Internet.

OpenBSD natively supports [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP (IP-IP)] tunnels through [https://man.openbsd.org/gif.4 ''gif''(4)] pseudo-devices. Each ''gif'' device is a virtual network interface, synthesized by the operating system, that implements a point-to-point tunnel. Unlike Linux, OpenBSD requires a separate ''gif'' interface for each tunnel. An essentially arbitrary number of such interfaces can be created and it scales to the number required to route all of AMPRNet.

One can manually configure ''gif'' tunnels and routes at the command line, or configure the system to establish tunnels and routes at boot time.

We will describe how to set things up by way of example. Assume a system configuration that looks substantially similar to the following:

# A dedicated static IP address to use as an endpoint for AMPRNet traffic.
# An ISP-provided router that is just a router; no NATing, no firewall.
# An OpenBSD computer with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter 3 Lite:
## cnmac0 is the external interface connected to the ISP's network (in this example, we use 23.30.150.141 routing to 23.30.150.142)
## cnmac1 connects to an internal network (its configuration is irrelevant)
## cnmac2 is the internal interface connected to the subnet (in this example, we use 44.44.107.1 routing for 44.44.107.0/24)

Let us start by configuring a single tunnel to the AMPRNet gateway at UCSD:

ifconfig gif0 create
ifconfig gif0 tunnel 23.30.150.141 169.228.34.84
ifconfig gif0 inet 44.44.107.1 netmask 255.255.255.255
route add 44.0.0.1 -link -iface gif0 -llinfo

Once I had a tunnel up to UCSD, I found that I could ping my
44.44.107.1 machine from a host on my internal network, but not
from arbitrary machines. This was interesting; it turns out that
hosts on my internal network get NAT'ed to another IP address on
the small subnet I got from Comcast (through another, completely
separate router -- not comcast's router but another ERL). What was
happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
ICMP echo request packets got NAT'ed to this other address and
routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
external interface of my AMPRNet gateway. The gateway accepted the
encapsulated ICMP echo requests (I have a PF rule that explicitly
allows ping) and forwarded them across the tunnel interface where
they were unencapsulated; the IP stack saw that the result was
addressed to an IP address on a local interface (i.e., they were
for the router) and generated an ICMP echo response packet with a
*source* address of 44.44.107.1 and a *destination* address of the
external address of my other router (that is, the address the ICMP
echo request was NAT'ed to). This matched the network route for
my local Comcats subnet and so my AMPRNet router realized it could
pass the packet back to my other router directly. It did so and
the other router happily took the packet, matched it back through
the NAT back to the original requesting machine (my laptop) and
forwarded it: hence, I got my ping responses back. But note that
the response was not going through the tunnel back to UCSD: it was
being routed directly through the external interface.

Now consider what happens when I tried to ping 44.44.107.1 from
a different machine on some other network. The ICMP echo request
packet gets routed through the UCSD gateway and tunneled back to
my gateway as before, but since responses don't go through back
through the tunnel, the response packet matches the default route
of my gateway and get's forwarded to comcast's router. Comcast
would look at it, see that 44.44.107.1 wasn't on one of it's known
networks that it would route floor, and discard the response. Oops.

The solution was to set up a separate routing table in a different
routing domain specifically for AMPRNet traffic, and tie the two
together using firewall rules. In the AMPRNet routing table, I
could set my default route to point to the UCSD gateway, so any
traffic sent from one of my 44.44.107.0/24 addresses that doesn't
match a route to a known tunnel gets forwarded through
amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
from random machines. This must seem obvious to a lot of folks
here, but it took me a little while to figure out what was going
on. Things are working now, however.

So far I have encountered two other caveats: I decided to
configure two tunnel interfaces statically at boot time: 'gif0'
goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
his 44.88 net. Under OpenBSD, I assumed that the natural way to
do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
files and this does in fact create the tunnels at boot time. However,
traffic going out from my gateway doesn't seem to get sent through
the tunnels; I did not bother to track down exactly why, but I
believe it has to do with some kind of implicit ordering dependency
when initializing PF. When I set up the separate routing domain,
it struck me that the language accepted by /etc/netstart in an
/etc/hostname.if file was not sufficiently rich to set up tunnels
in a routing domain, so I capitulated and just set up the static
interfaces from /etc/rc.local; imperfect but it works.

The second caveat is that I seem to have tickled a kernel error
trying to set up an alias of a second IP address on my 44.44.107.1
NIC; I get a kernel panic due to an assertion failure. It looks a
bug to me, but I haven't had the bandwidth to track it down. In
the meanwhile, simply don't add aliases to interfaces in non-default
routing domains.

The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others.

A couple of quick notes on implementation:

# The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet.
# A similar table of tunnels is maintained.
# Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
# The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.

There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.

It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd

Setting up a gateway on OpenBSD

2016-10-16T13:59:40Z

Cross:

TODO(Cross): Wordsmith this section

This page describes how to configure a router running OpenBSD to transfer traffic between a 44Net subnet and the rest of the world.

Assume a setup that looks substantially similar to the following:

# A dedicated static IP address to use as an endpoint for 44net traffic.
# An ISP-provided router that is just a router; no NATing, no firewalling.
# An edge router OpenBSD with three ethernet interfaces. For example, using a Ubiquiti EdgeRouter Lite:
## cnmac0 is the external interface connected to the ISP's network
## cnmac1 connects to your internal network
## cnmac2 is your AMPRNet internal gateway to your subnet (in this example, we use 44.44.107.0/24)

On OpenBSD, tunneling interfaces for IPENCAP are provided by 'gif' pseudo-devices. Unlike Linux, one creates a separate 'gif' interface for each tunnel, but one can create an essentially arbitrary number of such interfaces. If there is a limit it is well above the number required for supporting the full AMPRNet mesh, so don't worry about scalability to the number of interfaces.

On AMPRNet, the UCSD gateway *will not* pass traffic for an IP address that does not have a corresponding entry in the AMPR.ORG DNS domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's. Caveat emptor as one tries to test: make sure you have DNS entries for your addresses and try pinging something other than 44.0.0.1 or you'll suffer contusions banging your head against a desk trying to figure out why nothing appears to work....

Once I had a tunnel up to UCSD, I found that I could ping my
44.44.107.1 machine from a host on my internal network, but not
from arbitrary machines. This was interesting; it turns out that
hosts on my internal network get NAT'ed to another IP address on
the small subnet I got from Comcast (through another, completely
separate router -- not comcast's router but another ERL). What was
happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
ICMP echo request packets got NAT'ed to this other address and
routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
external interface of my AMPRNet gateway. The gateway accepted the
encapsulated ICMP echo requests (I have a PF rule that explicitly
allows ping) and forwarded them across the tunnel interface where
they were unencapsulated; the IP stack saw that the result was
addressed to an IP address on a local interface (i.e., they were
for the router) and generated an ICMP echo response packet with a
*source* address of 44.44.107.1 and a *destination* address of the
external address of my other router (that is, the address the ICMP
echo request was NAT'ed to). This matched the network route for
my local Comcats subnet and so my AMPRNet router realized it could
pass the packet back to my other router directly. It did so and
the other router happily took the packet, matched it back through
the NAT back to the original requesting machine (my laptop) and
forwarded it: hence, I got my ping responses back. But note that
the response was not going through the tunnel back to UCSD: it was
being routed directly through the external interface.

Now consider what happens when I tried to ping 44.44.107.1 from
a different machine on some other network. The ICMP echo request
packet gets routed through the UCSD gateway and tunneled back to
my gateway as before, but since responses don't go through back
through the tunnel, the response packet matches the default route
of my gateway and get's forwarded to comcast's router. Comcast
would look at it, see that 44.44.107.1 wasn't on one of it's known
networks that it would route floor, and discard the response. Oops.

The solution was to set up a separate routing table in a different
routing domain specifically for AMPRNet traffic, and tie the two
together using firewall rules. In the AMPRNet routing table, I
could set my default route to point to the UCSD gateway, so any
traffic sent from one of my 44.44.107.0/24 addresses that doesn't
match a route to a known tunnel gets forwarded through
amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
from random machines. This must seem obvious to a lot of folks
here, but it took me a little while to figure out what was going
on. Things are working now, however.

So far I have encountered two other caveats: I decided to
configure two tunnel interfaces statically at boot time: 'gif0'
goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
his 44.88 net. Under OpenBSD, I assumed that the natural way to
do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
files and this does in fact create the tunnels at boot time. However,
traffic going out from my gateway doesn't seem to get sent through
the tunnels; I did not bother to track down exactly why, but I
believe it has to do with some kind of implicit ordering dependency
when initializing PF. When I set up the separate routing domain,
it struck me that the language accepted by /etc/netstart in an
/etc/hostname.if file was not sufficiently rich to set up tunnels
in a routing domain, so I capitulated and just set up the static
interfaces from /etc/rc.local; imperfect but it works.

The second caveat is that I seem to have tickled a kernel error
trying to set up an alias of a second IP address on my 44.44.107.1
NIC; I get a kernel panic due to an assertion failure. It looks a
bug to me, but I haven't had the bandwidth to track it down. In
the meanwhile, simply don't add aliases to interfaces in non-default
routing domains.

The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others.

A couple of quick notes on implementation:

# The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet.
# A similar table of tunnels is maintained.
# Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
# The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.

There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.

It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd

Setting up a gateway on OpenBSD

2016-09-24T02:47:10Z

Cross: More wiki-formatting.

TODO(Cross): Wordsmith this section

I am now successfully transferring traffic between my 44net subnet
(44.44.107.0/24) and the rest of the world using my OpenBSD-based
router.

A quick recap of my setup:
1. I have a Comcast business class circuit.
2. I have a dedicated static IP address to use as an endpoint for 44net traffic.
3. My comcast router is just a router; no NATing, no firewalling.
4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite running OpenBSD 5.9. It has three ethernet interfaces:
a. cnmac0 is the external interface connected to Comcast's network
b. cnmac1 connects to my internal network
c. cnmac2 is my internal gateway to 44.44.107.0/24.

On OpenBSD, tunneling interfaces for IPENCAP are provided by
'gif' pseudo-devices. Unlike Linux, it appears that one creates a
separate 'gif' interface for each tunnel, but one seems able to
create an arbitrary number of such interfaces: I created a thousand
as a test. I'm sure there is a limit but it seems sufficiently
high that practically routing AMPRNet traffic won't run up against
it. (Again, if someone knows of a different way to configure a
single 'gif' interface so that it could support multiple tunnels,
I'd be happy to know about it). In other words, don't worry about
scalability because you are creating a separate 'gif' interface for
each tunnel to another AMPRNet site.

On AMPRNet, the UCSD gateway *will not* pass traffic for an
IP address that does not have a corresponding entry in the AMPR.ORG
domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's.
Caveat emptor as one tries to test: make sure you have DNS entries
for your addresses and try pinging something other than 44.0.0.1
or you'll suffer contusions banging your head against a desk trying
to figure out why nothing appears to work....

Once I had a tunnel up to UCSD, I found that I could ping my
44.44.107.1 machine from a host on my internal network, but not
from arbitrary machines. This was interesting; it turns out that
hosts on my internal network get NAT'ed to another IP address on
the small subnet I got from Comcast (through another, completely
separate router -- not comcast's router but another ERL). What was
happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
ICMP echo request packets got NAT'ed to this other address and
routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
external interface of my AMPRNet gateway. The gateway accepted the
encapsulated ICMP echo requests (I have a PF rule that explicitly
allows ping) and forwarded them across the tunnel interface where
they were unencapsulated; the IP stack saw that the result was
addressed to an IP address on a local interface (i.e., they were
for the router) and generated an ICMP echo response packet with a
*source* address of 44.44.107.1 and a *destination* address of the
external address of my other router (that is, the address the ICMP
echo request was NAT'ed to). This matched the network route for
my local Comcats subnet and so my AMPRNet router realized it could
pass the packet back to my other router directly. It did so and
the other router happily took the packet, matched it back through
the NAT back to the original requesting machine (my laptop) and
forwarded it: hence, I got my ping responses back. But note that
the response was not going through the tunnel back to UCSD: it was
being routed directly through the external interface.

Now consider what happens when I tried to ping 44.44.107.1 from
a different machine on some other network. The ICMP echo request
packet gets routed through the UCSD gateway and tunneled back to
my gateway as before, but since responses don't go through back
through the tunnel, the response packet matches the default route
of my gateway and get's forwarded to comcast's router. Comcast
would look at it, see that 44.44.107.1 wasn't on one of it's known
networks that it would route floor, and discard the response. Oops.

The solution was to set up a separate routing table in a different
routing domain specifically for AMPRNet traffic, and tie the two
together using firewall rules. In the AMPRNet routing table, I
could set my default route to point to the UCSD gateway, so any
traffic sent from one of my 44.44.107.0/24 addresses that doesn't
match a route to a known tunnel gets forwarded through
amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
from random machines. This must seem obvious to a lot of folks
here, but it took me a little while to figure out what was going
on. Things are working now, however.

So far I have encountered two other caveats: I decided to
configure two tunnel interfaces statically at boot time: 'gif0'
goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
his 44.88 net. Under OpenBSD, I assumed that the natural way to
do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
files and this does in fact create the tunnels at boot time. However,
traffic going out from my gateway doesn't seem to get sent through
the tunnels; I did not bother to track down exactly why, but I
believe it has to do with some kind of implicit ordering dependency
when initializing PF. When I set up the separate routing domain,
it struck me that the language accepted by /etc/netstart in an
/etc/hostname.if file was not sufficiently rich to set up tunnels
in a routing domain, so I capitulated and just set up the static
interfaces from /etc/rc.local; imperfect but it works.

The second caveat is that I seem to have tickled a kernel error
trying to set up an alias of a second IP address on my 44.44.107.1
NIC; I get a kernel panic due to an assertion failure. It looks a
bug to me, but I haven't had the bandwidth to track it down. In
the meanwhile, simply don't add aliases to interfaces in non-default
routing domains.

The biggest piece missing was a daemon to handle receiving 44net
RIP packets and use that data to maintain tunnels and routes. I
thought about porting one, but decided of write my own instead.
It has been running for a few weeks now on my node and while it's
still not quite "done" it seems to work well enough that I decided
it was time to cast a somewhat a wider net and push it up to
GitHub for comment from others.

A couple of quick notes on implementation:

1. The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet.
2. A similar table of tunnels is maintained.
3. Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained.
4. The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket.

There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.

It's about 1200 lines of non-comment code, compiles down to a 28K
MIPS64 executable (stripped). The code is at
https://github.com/dancrossnyc/44ripd

Setting up a gateway on OpenBSD

2016-09-24T02:46:11Z

Cross: De-indent paragraphs so they aren't interpreted as code by the Wiki

TODO(Cross): Wordsmith this section

I am now successfully transferring traffic between my 44net subnet
(44.44.107.0/24) and the rest of the world using my OpenBSD-based
router.

A quick recap of my setup:
1. I have a Comcast business class circuit.
2. I have a dedicated static IP address to use as an endpoint for
44net traffic.
3. My comcast router is just a router; no NATing, no firewalling.
4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite
running OpenBSD 5.9. It has three ethernet interfaces:
a. cnmac0 is the external interface connected to Comcast's network
b. cnmac1 connects to my internal network
c. cnmac2 is my internal gateway to 44.44.107.0/24.

On OpenBSD, tunneling interfaces for IPENCAP are provided by
'gif' pseudo-devices. Unlike Linux, it appears that one creates a
separate 'gif' interface for each tunnel, but one seems able to
create an arbitrary number of such interfaces: I created a thousand
as a test. I'm sure there is a limit but it seems sufficiently
high that practically routing AMPRNet traffic won't run up against
it. (Again, if someone knows of a different way to configure a
single 'gif' interface so that it could support multiple tunnels,
I'd be happy to know about it). In other words, don't worry about
scalability because you are creating a separate 'gif' interface for
each tunnel to another AMPRNet site.

On AMPRNet, the UCSD gateway *will not* pass traffic for an
IP address that does not have a corresponding entry in the AMPR.ORG
domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's.
Caveat emptor as one tries to test: make sure you have DNS entries
for your addresses and try pinging something other than 44.0.0.1
or you'll suffer contusions banging your head against a desk trying
to figure out why nothing appears to work....

Once I had a tunnel up to UCSD, I found that I could ping my
44.44.107.1 machine from a host on my internal network, but not
from arbitrary machines. This was interesting; it turns out that
hosts on my internal network get NAT'ed to another IP address on
the small subnet I got from Comcast (through another, completely
separate router -- not comcast's router but another ERL). What was
happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
ICMP echo request packets got NAT'ed to this other address and
routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
external interface of my AMPRNet gateway. The gateway accepted the
encapsulated ICMP echo requests (I have a PF rule that explicitly
allows ping) and forwarded them across the tunnel interface where
they were unencapsulated; the IP stack saw that the result was
addressed to an IP address on a local interface (i.e., they were
for the router) and generated an ICMP echo response packet with a
*source* address of 44.44.107.1 and a *destination* address of the
external address of my other router (that is, the address the ICMP
echo request was NAT'ed to). This matched the network route for
my local Comcats subnet and so my AMPRNet router realized it could
pass the packet back to my other router directly. It did so and
the other router happily took the packet, matched it back through
the NAT back to the original requesting machine (my laptop) and
forwarded it: hence, I got my ping responses back. But note that
the response was not going through the tunnel back to UCSD: it was
being routed directly through the external interface.

Now consider what happens when I tried to ping 44.44.107.1 from
a different machine on some other network. The ICMP echo request
packet gets routed through the UCSD gateway and tunneled back to
my gateway as before, but since responses don't go through back
through the tunnel, the response packet matches the default route
of my gateway and get's forwarded to comcast's router. Comcast
would look at it, see that 44.44.107.1 wasn't on one of it's known
networks that it would route floor, and discard the response. Oops.

The solution was to set up a separate routing table in a different
routing domain specifically for AMPRNet traffic, and tie the two
together using firewall rules. In the AMPRNet routing table, I
could set my default route to point to the UCSD gateway, so any
traffic sent from one of my 44.44.107.0/24 addresses that doesn't
match a route to a known tunnel gets forwarded through
amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
from random machines. This must seem obvious to a lot of folks
here, but it took me a little while to figure out what was going
on. Things are working now, however.

So far I have encountered two other caveats: I decided to
configure two tunnel interfaces statically at boot time: 'gif0'
goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
his 44.88 net. Under OpenBSD, I assumed that the natural way to
do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
files and this does in fact create the tunnels at boot time. However,
traffic going out from my gateway doesn't seem to get sent through
the tunnels; I did not bother to track down exactly why, but I
believe it has to do with some kind of implicit ordering dependency
when initializing PF. When I set up the separate routing domain,
it struck me that the language accepted by /etc/netstart in an
/etc/hostname.if file was not sufficiently rich to set up tunnels
in a routing domain, so I capitulated and just set up the static
interfaces from /etc/rc.local; imperfect but it works.

The second caveat is that I seem to have tickled a kernel error
trying to set up an alias of a second IP address on my 44.44.107.1
NIC; I get a kernel panic due to an assertion failure. It looks a
bug to me, but I haven't had the bandwidth to track it down. In
the meanwhile, simply don't add aliases to interfaces in non-default
routing domains.

The biggest piece missing was a daemon to handle receiving 44net
RIP packets and use that data to maintain tunnels and routes. I
thought about porting one, but decided of write my own instead.
It has been running for a few weeks now on my node and while it's
still not quite "done" it seems to work well enough that I decided
it was time to cast a somewhat a wider net and push it up to
GitHub for comment from others.

A couple of quick notes on implementation:

1. The program maintains a copy of the AMPRNet routing table in
a modified PATRICIA trie (really a compressed radix tree).
Routes are expired after receiving a RIP packet.
2. A similar table of tunnels is maintained.
3. Tunnel interfaces are reference counted and garbage collected.
A bitmap indicating which tunnels are in use is
maintained.
4. The program is completely self-contained in the sense that I
do not fork/exec external commands to e.g. configure tunnels
or manipulate routes. That is all done via ioctls or writing
messages to a routing socket.

There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.

It's about 1200 lines of non-comment code, compiles down to a 28K
MIPS64 executable (stripped). The code is at
https://github.com/dancrossnyc/44ripd

Setting up a gateway on OpenBSD

2016-09-24T02:44:52Z

Cross: Incorporate content from the mailing list. Next, I will massage this into a more useful page.

TODO(Cross): Wordsmith this section

Folks,

I just wanted to do a quick followup to this for the archives.
I am now successfully transferring traffic between my 44net subnet
(44.44.107.0/24) and the rest of the world using my OpenBSD-based
router.

A quick recap of my setup:
1. I have a Comcast business class circuit.
2. I have a dedicated static IP address to use as an endpoint for
44net traffic.
3. My comcast router is just a router; no NATing, no firewalling.
4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite
running OpenBSD 5.9. It has three ethernet interfaces:
a. cnmac0 is the external interface connected to Comcast's network
b. cnmac1 connects to my internal network
c. cnmac2 is my internal gateway to 44.44.107.0/24.

On OpenBSD, tunneling interfaces for IPENCAP are provided by
'gif' pseudo-devices. Unlike Linux, it appears that one creates a
separate 'gif' interface for each tunnel, but one seems able to
create an arbitrary number of such interfaces: I created a thousand
as a test. I'm sure there is a limit but it seems sufficiently
high that practically routing AMPRNet traffic won't run up against
it. (Again, if someone knows of a different way to configure a
single 'gif' interface so that it could support multiple tunnels,
I'd be happy to know about it). In other words, don't worry about
scalability because you are creating a separate 'gif' interface for
each tunnel to another AMPRNet site.

On AMPRNet, the UCSD gateway *will not* pass traffic for an
IP address that does not have a corresponding entry in the AMPR.ORG
domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's.
Caveat emptor as one tries to test: make sure you have DNS entries
for your addresses and try pinging something other than 44.0.0.1
or you'll suffer contusions banging your head against a desk trying
to figure out why nothing appears to work....

Once I had a tunnel up to UCSD, I found that I could ping my
44.44.107.1 machine from a host on my internal network, but not
from arbitrary machines. This was interesting; it turns out that
hosts on my internal network get NAT'ed to another IP address on
the small subnet I got from Comcast (through another, completely
separate router -- not comcast's router but another ERL). What was
happening was that as I ping'ed 44.44.107.1 from e.g. my laptop,
ICMP echo request packets got NAT'ed to this other address and
routed over to amprgw.sysnet.ucsd.edu and tunneled back to the
external interface of my AMPRNet gateway. The gateway accepted the
encapsulated ICMP echo requests (I have a PF rule that explicitly
allows ping) and forwarded them across the tunnel interface where
they were unencapsulated; the IP stack saw that the result was
addressed to an IP address on a local interface (i.e., they were
for the router) and generated an ICMP echo response packet with a
*source* address of 44.44.107.1 and a *destination* address of the
external address of my other router (that is, the address the ICMP
echo request was NAT'ed to). This matched the network route for
my local Comcats subnet and so my AMPRNet router realized it could
pass the packet back to my other router directly. It did so and
the other router happily took the packet, matched it back through
the NAT back to the original requesting machine (my laptop) and
forwarded it: hence, I got my ping responses back. But note that
the response was not going through the tunnel back to UCSD: it was
being routed directly through the external interface.

Now consider what happens when I tried to ping 44.44.107.1 from
a different machine on some other network. The ICMP echo request
packet gets routed through the UCSD gateway and tunneled back to
my gateway as before, but since responses don't go through back
through the tunnel, the response packet matches the default route
of my gateway and get's forwarded to comcast's router. Comcast
would look at it, see that 44.44.107.1 wasn't on one of it's known
networks that it would route floor, and discard the response. Oops.

The solution was to set up a separate routing table in a different
routing domain specifically for AMPRNet traffic, and tie the two
together using firewall rules. In the AMPRNet routing table, I
could set my default route to point to the UCSD gateway, so any
traffic sent from one of my 44.44.107.0/24 addresses that doesn't
match a route to a known tunnel gets forwarded through
amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway
from random machines. This must seem obvious to a lot of folks
here, but it took me a little while to figure out what was going
on. Things are working now, however.

So far I have encountered two other caveats: I decided to
configure two tunnel interfaces statically at boot time: 'gif0'
goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for
his 44.88 net. Under OpenBSD, I assumed that the natural way to
do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1
files and this does in fact create the tunnels at boot time. However,
traffic going out from my gateway doesn't seem to get sent through
the tunnels; I did not bother to track down exactly why, but I
believe it has to do with some kind of implicit ordering dependency
when initializing PF. When I set up the separate routing domain,
it struck me that the language accepted by /etc/netstart in an
/etc/hostname.if file was not sufficiently rich to set up tunnels
in a routing domain, so I capitulated and just set up the static
interfaces from /etc/rc.local; imperfect but it works.

The second caveat is that I seem to have tickled a kernel error
trying to set up an alias of a second IP address on my 44.44.107.1
NIC; I get a kernel panic due to an assertion failure. It looks a
bug to me, but I haven't had the bandwidth to track it down. In
the meanwhile, simply don't add aliases to interfaces in non-default
routing domains.

The biggest piece missing was a daemon to handle receiving 44net
RIP packets and use that data to maintain tunnels and routes. I
thought about porting one, but decided of write my own instead.
It has been running for a few weeks now on my node and while it's
still not quite "done" it seems to work well enough that I decided
it was time to cast a somewhat a wider net and push it up to
GitHub for comment from others.

A couple of quick notes on implementation:

1. The program maintains a copy of the AMPRNet routing table in
a modified PATRICIA trie (really a compressed radix tree).
Routes are expired after receiving a RIP packet.
2. A similar table of tunnels is maintained.
3. Tunnel interfaces are reference counted and garbage collected.
A bitmap indicating which tunnels are in use is
maintained.
4. The program is completely self-contained in the sense that I
do not fork/exec external commands to e.g. configure tunnels
or manipulate routes. That is all done via ioctls or writing
messages to a routing socket.

There is more to do; I'm sure there are a few bugs. I'd also like
to query the system state at startup to initialize the routing and
tunnel tables. Exporting and/or parsing an encap file would be
nice. Logging and error checking can, I'm sure, be improved.

It's about 1200 lines of non-comment code, compiles down to a 28K
MIPS64 executable (stripped). The code is at
https://github.com/dancrossnyc/44ripd

Setting up a gateway on OpenBSD

2016-09-24T02:13:57Z

Cross: Setting up an AMPRNet Gateway on OpenBSD

TODO(Cross): Fill this section in

Archive/Main Page

2016-09-24T02:13:20Z

Cross: /* How to connect to AMPRNet */

Welcome to the AMPRNet Wiki.

Since its allocation to Amateur Radio in the mid-1980's, Internet network 44 (44.0.0.0/8), known as the AMPRNet™, has been used by amateur radio operators to conduct scientific research and to experiment with digital communications over radio with a goal of advancing the state of the art of Amateur Radio networking, and to educate amateur radio operators in these techniques. - [http://www.ampr.org/ www.ampr.org]
__NOTOC__
== Starting points ==
* [[Quickstart]] guide for getting onto the [[AMPRNet]]
* Basic information about the [[AMPRNet]] and the [[ampr.org]] domain
* [[Services]] available on AMPRNet
* If you are looking to get an IP allocation within the 44/8 AMPRNet please read the [[Portal]] page.
* Frequently Asked Questions (FAQ) [[FAQ]]

== How to connect to AMPRNet ==

* Instructions for [[Setting up a gateway on Linux|setup a Linux gateway]]
* Instructions for [[Setting up a gateway on OpenBSD|setting up an OpenBSD gateway]]
* Instructions for [[setting up a gateway on Cisco Routers|setting up a gateway on Cisco Routers]].
* Instructions for [[setting up a gateway on MikroTik Routers|setting up a gateway on MikroTik Routers]].
* Instructions for [[setting up a gateway on OpenWRT|setting up a gateway on OpenWRT]].
* Instructions for [[setting up a gateway on Ubiquiti EdgeRouter|setting up a gateway on Ubiquiti EdgeRouter]].
* Instructions for [[announcing your allocation directly|directly announcing your allocation via your Internet Service Provider (ISP)]].
* Instructions for [[AMPRNet VPN|Accessing AMPRNet via VPN]] (experimental).
* [[Why can't I just route my AMPRNet allocation directly myself ?]]
* If you already operate a [[gateway]] please ensure you have registered on the [[portal]] and "claimed" your [[gateway]].

== Mailing List ==
To keep up-to-date on AMPRNet information please consider joining the [[44Net mailing list]].

== Contribute! ==
If you wish to contribute to the wiki, please send an email to <tt>wiki (at) ampr.org</tt> introducing yourself. Please specify your full name, amateur radio callsign and your preferred username. A login will then be created for you.

== Terms of Service ==
Use of 44.0.0.0/8 address space and ampr.org DNS is governed by the following [http://www.ampr.org/wp-content/uploads/tos.txt Terms of Service]

== All Pages ==
[http://wiki.ampr.org/wiki/Special:AllPages Here's a list of all pages currently on the AMPRNet Wiki]

Talk:Ampr.org

2016-06-20T23:26:21Z

Cross: Create the Talk:Ampr.org page.

Talk about [[Ampr.org]]

Talk:Ampr.org

2016-06-20T23:25:03Z

Cross: Created page with "Test"

Test

User talk:Cross

2016-06-20T19:41:43Z

Cross: Blanked the page

User talk:Kb3vwg

2016-06-19T12:25:34Z

Cross: I'm sorry, I still don't understand your comment.

I'm not sure which edit you were referring to in the note you left on my talk:Cross page?

I'm sorry but I don't understand your comment. What about that edit were you referring to? You linked to an RFC that talks about CIDR for reverse DNS delegation and a non-AMPR case, but the edit was to a page specifically about AMPR and had nothing to do with reverse delegation.... The UCSD filter configuration is independent of all of that, right? Perhaps it would make more sense to move this conversation over to the http://wiki.ampr.org/wiki/User_talk:Ampr.org page?

User:Cross

2016-06-18T22:22:53Z

Cross: Created page with "My name is Dan Cross. I'm a software engineer; my call sign is AC2OI. You can find out more about me on my personal web page: http://pub.gajendra.net/"

My name is Dan Cross. I'm a software engineer; my call sign is AC2OI. You can find out more about me on my personal web page: http://pub.gajendra.net/

User talk:Kb3vwg

2016-06-18T22:21:04Z

Cross: Created page with "I'm not sure which edit you were referring to in the note you left on my talk:Cross page?"

I'm not sure which edit you were referring to in the note you left on my talk:Cross page?

User talk:Cross

2016-06-18T22:19:40Z

Cross:

I'm not sure this edit is totally relevant to the NON-AMPR Community, this is actually recommended under RFC 2317 (see https://tools.ietf.org/html/rfc2317), and is simply standard practice.

I'm not sure which edit you're referring to specifically; I only see a note on my talk:Cross page?

Ampr.org

2016-06-17T19:34:56Z

Cross: Mention that and entry in the AMPR.ORG domain is mandatory for the UCSD gateway to forward packets to an IP address.

AMPR.ORG is the domain that is available for ham radio operators to register their [[AMPRNet]] network [https://en.wikipedia.org/wiki/Host_%28network%29 hosts], and for other ham radio related computer systems.

Domain names in AMPR.ORG are available to any licensed [https://en.wikipedia.org/wiki/Amateur_radio_operator amateur radio operator] who is interested in advancing the art of ham radio digital communications. In most countries, there is a local coordinator who is responsible for assigning an address and updating the master hosts list. There is no formal organization, no membership requirements, and no dues. All of the work is done by volunteers as they have time to do it. Note that an IP address ''must'' be associated with a domain name in AMPR.ORG in order for the main gateway at UCSD to pass packets to it.

If you are a ham who needs an address, contact your local coordinator. AMPR.ORG is not intended to be, and should not be used as, a substitute for buying a personal domain name. It's really there for ham radio use.

= Updating the ampr.org DNS zone =

... TODO: write up on how to formulate a good update request to the local coordinator.

Contact your local coordinator to request an update of the zone. A list of coordinators can be found on the [[Portal]]:

* [https://portal.ampr.org/networks.php https://portal.ampr.org/networks.php]

Archive/Main Page

2016-06-17T19:32:05Z

Cross: Link quickstart to main page.

Welcome to the AMPRNet Wiki.

Since its allocation to Amateur Radio in the mid-1980's, Internet network 44 (44.0.0.0/8), known as the AMPRNet™, has been used by amateur radio operators to conduct scientific research and to experiment with digital communications over radio with a goal of advancing the state of the art of Amateur Radio networking, and to educate amateur radio operators in these techniques. - [http://www.ampr.org/ www.ampr.org]
__NOTOC__
== Starting points ==
* [[Quickstart]] guide for getting onto the [[AMPRNet]]
* Basic information about the [[AMPRNet]] and the [[ampr.org]] domain
* [[Services]] available on AMPRNet
* If you are looking to get an IP allocation within the 44/8 AMPRNet please read the [[Portal]] page.
* Frequently Asked Questions (FAQ) [[FAQ]]

== How to connect to AMPRNet ==

* Instructions for [[Setting up a gateway on Linux|setup a Linux gateway]]
* Instructions for [[setting up a gateway on Cisco Routers|setting up a gateway on Cisco Routers]].
* Instructions for [[setting up a gateway on MikroTik Routers|setting up a gateway on MikroTik Routers]].
* Instructions for [[setting up a gateway on OpenWRT|setting up a gateway on OpenWRT]].
* Instructions for [[setting up a gateway on Ubiquiti EdgeRouter|setting up a gateway on Ubiquiti EdgeRouter]].
* Instructions for [[announcing your allocation directly|directly announcing your allocation via your Internet Service Provider (ISP)]].
* Instructions for [[AMPRNet VPN|Accessing AMPRNet via VPN]] (experimental).
* [[Why can't I just route my AMPRNet allocation directly myself ?]]
* If you already operate a [[gateway]] please ensure you have registered on the [[portal]] and "claimed" your [[gateway]].

== Mailing List ==
To keep up-to-date on AMPRNet information please consider joining the [[44Net mailing list]].

== Contribute! ==
If you wish to contribute to the wiki, please send an email to <tt>wiki (at) ampr.org</tt> introducing yourself. Please specify your full name, amateur radio callsign and your preferred username. A login will then be created for you.

== Terms of Service ==
Use of 44.0.0.0/8 address space and ampr.org DNS is governed by the following [http://www.ampr.org/tos.txt Terms of Service]

== All Pages ==
[http://wiki.ampr.org/wiki/Special:AllPages Here's a list of all pages currently on the AMPRNet Wiki]

Quickstart

2016-06-17T19:31:26Z

Cross: Remove more elaborate heading.

So you're a licensed amateur radio operator, you're interested in IP networking, and you want to combine the two. [[AMPRNet]] is for you. This Quickstart guide can help get you set up quickly.

To get online with [[AMPRNet]], you will probably want to start with a tunnel connection to the rest of the network. You will need the following:

# A router. This can be a specialized routing device, or a general purpose computer. It probably won't need a lot of compute power, so you can recycle an old PC or something similar.
# An Internet connection that gives you a stable IP address for the rest of the network to talk to you: [[AMPRnet]] tunnels pass 44/8 data between parts of the AMPR network by encapsulating them in non-44net Internet traffic. Static IP addresses are best for this, but IP addresses dynamically assigned to you by your ISP may work if they change infrequently.

Once you have a machine to act as a router and a suitable network connection, do the following:

# [https://portal.ampr.org/register.php Register] on the [[portal]].
# Request a network allocation from your regional coordinator.
## From the portal's [https://portal.ampr.org/networks.php networks] page, navigate to your country and region's network subpage.
## From the regional network page, request an allocation. Note, select only ONE of the connection options (Radio, Tunnel, or Direct). To start, you probably want to select 'Tunnel'. For more information on requesting an allocation, see the wiki page on [[Requesting a block]].
# Once your allocation has been granted, [https://portal.ampr.org/gateways_manage.php register your gateway through the portal].
# Once your gateway has been registered, contact your regional coordinator to register DNS mappings for the hosts on your network. Note that the main tunnel router at UCSD will NOT pass traffic to an IP address unless that address is associated with a hostname in the [[Ampr.org|ampr.org]] DNS domain.
# Configure your router to act as a [[Gateway]] to the rest of the network.

That's it! You now have a tunnel to the rest of the network. From here, you can connect devices via RF links, subnet your network if you like, and start exploring TCP/IP over amateur radio.

== Next Steps ==

Once you are connected, you should subscribe to the [[44Net mailing list]].