Documentation Index
Alphabetic Index
XRPi Documentation - Protocols
IPUDP Tunnelling
Introduction
The "Amateur Packet Radio IP Network" (amprnet) is a private network for transferring TCP/IP between amateur radio stations. It uses the class A IP address block 44.x.x.x, but although it is notionally part of the wider Internet, the public Internet has no knowledge of how to route it.
To solve this problem, amprnet traffic is usually wrapped or "encapsulated" within publicly-routable IP. At the destination gateway the frame is "unwrapped" to reveal the original ampr datagram.
IPUDP is IP encapsulated in UDP/IP. It allows amateur IP to be transported across other IP networks such as the Internet, to form "Virtual Private Networks" (VPN's).
In contrast to IPIP (commonly called IPEncap), which transports the private (e.g. amateur) IP directly inside the payload portion of a public (e.g. Internet) IP datagram, IPUDP transports the private datagram in the payload portion of a UDP frame, which is itself transported as payload in a public IP datagram. This requires 8 bytes more overhead than IPIP, but it is far more flexible.
| Public IP header 62.31.20.2->82.31.65.8 | UDP header 94->94 | ampr IP header 44.131.91.2->44.68.1.5 | ampr payload data (TCP UDP ICMP etc) |
IPUDP Packet Structure
(In the above diagram, the blue section represents the ampr (44-net) datagram, which forms the payload of a publicly-routable UDP/IP datagram. The IP addresses are for illustrative purposes only.)
IPIP is a "portless" protocol, and it is therefore difficult (in come cases impossible) to get it to pass through some types of NAT / PAT router which rely on translating TCP and UDP service port numbers in order to share a public IP address among several LAN hosts.
IPUDP overcomes this limitation because it transports the data using a well known protocol (UDP) which NAT / PAT routers can understand, thus it can get through where IPIP cannot. For example, it is easy to configure even the most lowly domestic router to route incoming UDP port 94 to a specific machine on the LAN, but it is not often possible to do the same with IPIP.
The IPUDP protocol currently uses UDP service port 94 for no better reason than because the number was easy to remember, being the same as the original protocol number for IPIP. In addition, there were no other well-known protocols using this port number. If difficulties are encountered with port 94, please inform the protocol originator (G8PZT).
IPUDP is only used for tunnelling amateur IP through the public Internet, or for situations where conventional routing isn't possible (e.g. XR32 without NdisXpkt). It would be pointless when routing via radio.
IPUDP tunnels are one-way. To create two-way IPUDP routing, the other end of a link needs to set up a reverse tunnel. However, the reverse route needn't necessarily use a tunnel.
When To Use IPUDP
XR32 was originally designed to be used with the NdisXpkt driver, which allowed it to have its own LAN IP address and IP stack. In this mode it could route anything, just like its 16 bit predecessor. However, since there is no 64-bit version of the NdisXpkt driver, XR32 was subsequently made "dual-mode", in that it could be made to run with or without the driver.
Without the NdisXpkt driver, XR32 was forced to use facilities provided by the Windows TCP/IP stack. Those facilities are very limited, and in some cases are deliberately crippled by Microsoft. For example, later versions of Windows XP prevent the use of IPEncap (protocol number 4).
Since no-one likes having to install and load drivers, the majority of sysops tend to use XR32 without NdisXpkt. However this was a "basic" mode, with limited facilities, compared to the "full" (NdisXpkt) mode. It was only intended as a stop-gap measure, until a 64-bit driver could be written.
In basic mode, XR32 can originate and terminate all the common protocols (TCP, UDP, ICMP etc.), but cannot actually route raw IP without some form of encapsulation.
As mentioned above, XR32 in "basic" mode cannot currently use the IPEncap protocol, so if one of your partners is using this mode, your IP routing options are limited to the following:
- Route IP across existing AXUDP/AXIP links.
- Use original IPIP protocol (protocol number 94).
- Use IPUDP protocol.
Option (a) is the least efficient in terms of packet overhead, although that is of litle concern on a broadband connection! It is easy to set up, but the downside is that you can only route IP to your AXUDP or AXIP partners. However, if everyone sets up their default routes to direct the traffic to and from an IPEncap-capable gateway, this should be no barrier.
Option (b) is the most efficient, and allows you to make a single hop (as far as 44-net is concerned) tunnel to *any* gateway Option (c) also allows you to hop directly to any other gateway, providing they can handle IPUDP, and doesn't use AX25. It is only marginally less efficient than IPIP, and as mentioned previously, it has the advantage that it's easy to route through NAT/PAT routers.
Although "full" mode allows IPEncap, it is of no benefit if your Internet router can't route it. So even in this mode, IPUDP may be the preferable option.
Note: For the purposes of this guide it is assumed that your connection to the Internet is via a domestic NAT/PAT router/firewall.
This may sound obvious, but in order to create any form of tunnel between amprnet hosts, each host needs both an amprnet (44.x.x.x.) and a public (e.g. 62.x.x.x) address. You MUST ensure that your amprnet IP address is specified as XRPi's "main" address, by including the line IPADDRESS=44.x.x.x near the top of the XROUTER.CFG file (replacing x.x.x with your IP address of course).
If you are using the EXTERNAL interface (which allows XRPi to use its own IP stack), you then "override" this address on the port which connects to the LAN or Internet, by including a different IPADDRESS= statement in the PORT block.
If you are not using the EXTERNAL interface, Linux will provide the LAN/Internet IP address instead. In this case you must run XRPi as root, unless you reassign the IPUDP service number above 1023 (see later).
Secondly, you and your link partner(s) must set up and test IP routing between your public (i.e. non-44.x.x.x) IP addresses. You cannot proceed until this step is complete..
If you are using a domestic router between XRPi and the Internet, you must "open" UDP port 94 to direct incoming traffic to XRPi's LAN address. This must be a "static" (permanent and unchanging) translation, not a transient or "port triggered" one.
Finally, for each tunnel destination you must add an IP route entry into IPROUTE.SYS, similar to the following:
The first IP address is the amateur IP address, or range thereof, to be routed via this IPUDP tunnel. If you don't fully understand this format, see the manual sections detailing IPROUTE.SYS and the IP ROUTE ADD command.
The second address is the public IP address or hostname of the link partner to whom the first address(es) will be routed. It is more efficient to use an IP address if possible, rather than a hostname, but the hostname may be required if the partner's public IP address changes frequently. (DO NOT put the partner's 44-net address in here!)
The last but one field (which is normally an XRPi PORT number in regular route entries) is used in IPUDP entries to specify the UDP service number. "0" is the recommended setting, meaning "use default" (see "advanced operation" below).
Mode "u" signifies IPUDP encapsulation.
Since you can only have one instance of a given UDP port number per IP address, you are not able to run more than one copy of XRPi on the same machine unless you reassign or disable the IPUDP ports to avoid contention. You may do this using the IPUDPPORT=n keyword anywhere in XROUTER.CFG, where n is a number between 0 and 65535.
It is recommended that you use port 94 (the default) as the primary port, 95 as the first alternative, 96 for the second, 97 for the third, and so on, as these numbers are not assigned to any particular service.
However, if you are NOT running the EXTERNAL interface, Linux will not allow you to use a port below 1024 unless you run XRPi as root.
You should avoid using the numbers associated with standard services such as DNS (53), DHCP (67 and 68), AXUDP (93), WINS (135) and so on. For a comprehensive list see
Please bear in mind that if you reassign your IPUDP port, others will not be able to route IP to you unless you inform them of the new number.
If you are using XRPi for AX25/Netrom only, and don't wish to take part in the amprnet, then you probably won't have included an IPADDRESS= line in XROUTER.CFG. In this case all IP facilities, including IPUDP are disabled automatically. However, you may have an IP address but wish to disable IPUDP for other reasons. You can do this easily by including the line IPUDPPORT=0, anywhere in XROUTER.CFG.
Creating an IPUDP tunnel to a peer who has reassigned his IPUDP port is relatively simple, as the following example shows:
A) Possible circumstances would be as follows:
A) No. It is believed that IPUDP is only understood by XRouter (XR16), XR32 and XRPi at present. However, whilst this means that you cannot directly use the routing information from the regular ENCAP.TXT file, at least some of those hosts will be running XRouter, and may therefore be able to accept IPUDP if the sysop has enabled it.
A) Yes. You can safely "mix and match" your IP routing modes to suit your own requirements. What you mustn't do is have identical route table entries with different modes. Nothing dangerous will happen, but XRPi will ignore the duplicates.
A) No. IPDUP is completely unrelated to AX25, AXIP, AXUDP etc. and does not need a special INTERFACE or PORT.
A) No, not for IPUDP itself, but you may need it if you intend to use IPEncap alongside IPUDP.
When things don't work, it is always due to a configuration error, not a fault in XRPi itself. Try PINGing the destination host to see if XRPi generates an error message. Some of the errors so far observed are lsted below:
The IPUDP port is already in use by another process on the PC. This error is usually caused by trying to run more than one XRPi on the same machine. You must use the IPUDPPORT keyword in XROUTER.CFG to disable IPUDP on all but one XRPi, or to assign a different port number to each one.
This should never happen, but if it does, Linux must be seriously overloaded!
The IP Access Control List is preventing the packet from being sent because the combination of source and destination IP addresses is not within one of the ranges you have defined to be "legal". Possible causes are:
The IPUDP subsystem was not initialised because the main IP address was not defined, or because IPUDPORT is set to 0 in XROUTER.CFG.
Assuming you have set up the route entry correctly, there are many possible reasons for failure. The following list is by no means exhaustive:
Creating An IPUDP Tunnel
IP ROUTE ADD 44.131.91.0/24 62.31.206.176 0 u
Advanced Operation
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
IP ROUTE ADD 44.131.91.0/24 62.31.206.176 95 u
Note the "95" in the last but one field, which tells XRouter to address the packets to UDP port 95 instead of the default port 94. That's all there is to it!
Frequently Asked Questions
Troubleshooting