On Tue, Jun 14, 2016 at 1:23 PM, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:

I see your list of Ethernet interfaces...but where's your IPENCAP tunnel interface?

What commands are you using to set your IPENCAP interface Up?

Lynwood,

Thanks for the note. Setting up the IPENCAP interface is the thing I haven't figured out yet. :-)

Here is an example of what I've tried:

# ifconfig gif0 create # ifconfig gif0 tunnel 23.30.150.141 169.228.66.251 netmask 255.255.255.254 # route add -host 169.228.66.251 23.30.150.142 add host 169.228.66.251: gateway 23.30.150.142 # ifconfig gif0 inet 23.30.150.141 169.228.66.251 netmask 255.255.255.254 # ifconfig gif0 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 priority: 0 groups: gif tunnel: inet 23.30.150.141 -> 169.228.66.251 inet 23.30.150.141 --> 169.228.66.251 netmask 0xfffffffe # route add 44/8 23.30.150.141 add net 44/8: gateway 23.30.150.141 # netstat -rn -f inet Routing tables

Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 23.30.150.142 UGS 4 48 - 8 cnmac0 23.30.150.136/29 23.30.150.141 UC 1 0 - 4 cnmac0 23.30.150.141 44:d9:e7:9f:a7:64 UHLl 0 77 - 1 cnmac0 23.30.150.142 4a:1d:70:de:c3:5a UHLc 2 9 - 4 cnmac0 23.30.150.143 23.30.150.141 UHb 0 0 - 1 cnmac0 44/8 23.30.150.141 UGS 0 33 - 8 gif0 44.44.107/24 44.44.107.1 C 0 0 - 4 cnmac2 44.44.107.1 44:d9:e7:9f:a7:66 UHLl 0 0 - 1 cnmac2 44.44.107.255 44.44.107.1 Hb 0 0 - 1 cnmac2 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UHl 0 0 32768 1 lo0 169.228.66.251 23.30.150.142 UGHSP 0 11 - 8 cnmac0 169.228.66.251 23.30.150.141 UHP 0 0 - 8 gif0 192.168/16 192.168.129.1 UGS 3 3 - 8 cnmac1 192.168.129/24 192.168.129.4 UC 1 0 - 4 cnmac1 192.168.129.1 24:a4:3c:05:57:b5 UHLc 1 2 - 4 cnmac1 192.168.129.4 44:d9:e7:9f:a7:65 UHLl 0 7 - 1 cnmac1 192.168.129.255 192.168.129.4 UHb 0 0 - 1 cnmac1 224/4 127.0.0.1 URS 0 24 32768 8 lo0 #

Let's suppose I try to ping something based on this.

# ping -I 44.44.107.1 -c 5 44.0.0.1 PING 44.0.0.1 (44.0.0.1): 56 data bytes --- 44.0.0.1 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss #

However, it appears these are being forwarded. In another window I ran 'tcpdump -vni gif0' and see this output:

# tcpdump -vni gif0 tcpdump: listening on gif0, link-type LOOP 17:54:23.704315 44.44.107.1 > 44.0.0.1: icmp: echo request (id:17cb seq:0) [icmp cksum ok] (ttl 255, id 47502, len 84) 17:54:24.715928 44.44.107.1 > 44.0.0.1: icmp: echo request (id:17cb seq:1) [icmp cksum ok] (ttl 255, id 47611, len 84) 17:54:25.710780 44.44.107.1 > 44.0.0.1: icmp: echo request (id:17cb seq:2) [icmp cksum ok] (ttl 255, id 16830, len 84) 17:54:26.705734 44.44.107.1 > 44.0.0.1: icmp: echo request (id:17cb seq:3) [icmp cksum ok] (ttl 255, id 34739, len 84) 17:54:27.710742 44.44.107.1 > 44.0.0.1: icmp: echo request (id:17cb seq:4) [icmp cksum ok] (ttl 255, id 32354, len 84) ^C 5 packets received by filter 0 packets dropped by kernel #

And running 'tcpdump -vni cnmac0 proto ipencap' in yet another window I see the following:

# tcpdump -vni cnmac0 proto ipencap tcpdump: listening on cnmac0, link-type EN10MB 17:56:16.647503 23.30.150.141 > 169.228.66.251: 44.44.107.1 > 44.0.0.1: icmp: echo request (id:1ace seq:0) (ttl 255, id 7822, len 84) (ttl 64, id 27590, len 104) 17:56:17.658425 23.30.150.141 > 169.228.66.251: 44.44.107.1 > 44.0.0.1: icmp: echo request (id:1ace seq:1) (ttl 255, id 22527, len 84) (ttl 64, id 20077, len 104) 17:56:18.653338 23.30.150.141 > 169.228.66.251: 44.44.107.1 > 44.0.0.1: icmp: echo request (id:1ace seq:2) (ttl 255, id 63017, len 84) (ttl 64, id 22814, len 104) 17:56:19.648295 23.30.150.141 > 169.228.66.251: 44.44.107.1 > 44.0.0.1: icmp: echo request (id:1ace seq:3) (ttl 255, id 24579, len 84) (ttl 64, id 13778, len 104) 17:56:20.653301 23.30.150.141 > 169.228.66.251: 44.44.107.1 > 44.0.0.1: icmp: echo request (id:1ace seq:4) (ttl 255, id 31869, len 84) (ttl 64, id 32539, len 104) ^C 21 packets received by filter 0 packets dropped by kernel #

But, no responses are receieved. Perhaps I'm just not pinging the right thing? Trying to ping '44.44.107.1' from an external address does not see incoming packets, either.

Thanks for any help! 73 de AC2OI,

- Dan C.

Dan,

The reason your AMPR traffic does not yet work - is because you haven't yet created an IPENCAP tunnel to listen on cnmac0 that will decapsulate the IP traffic and forward/bridge/NET/etc. it to the network located at cnmac2.

At this point, you're still looking at the encapsulated IPENCAP traffic with the additional Public IP header included. The tunnel interface strips this header - and your traffic will be ready for your local 44 subnet.

Hopefully, someone can provide you information on IPENCAP in BSD (once you receive it, consider making a BSD page on the Wiki site).

73,

KB3VWG

On Tue, Jun 14, 2016 at 04:57:06PM -0400, Dan Cross wrote:

...

From this point, I would expect to be able to 'ping 44.44.107.1' (my 44net

interface) from an external, Internet connected host and at least see an ICMP echo request. However, doing so from a random machine, I see neither an unencapsulated ICMP echo request packet on gif0, nor an encapsulated packet on cnmac0.

Trying to 'traceroute 44.44.107.1' from a machine on the Internet shows hops until I get to the amprgw at UCSD, and then nothing. Should I expect to see those make it to my router?

No, because there is a filter at UCSD which requires you to be registered in the AMPR.ORG DNS. You are not. Once that is in place you should be able to traceroute and ping your 44.44.107.1 address from anywhere on the great unwashed Internet. I would register you but I don't know your callsign.

In the meantime, if you set up a tunnel to another 44-net address, you should be able to ping it even though you're not in the DNS as the filter only affects non-44 inbound Internet traffic. I often test tunnels by seeing if I can ping to n1uro.ampr.org, 44.88.0.9, which is dependably there. - Brian

On Tue, Jun 14, 2016 at 8:26 PM, Brian n1uro@n1uro.ampr.org wrote:

...

No, because there is a filter at UCSD which requires you to be registered in the AMPR.ORG DNS. You are not.

[snip]

From his allocated block notes authored by me 6 months ago:

Dan; You'll need to email me your DNS requests manually

Indeed, you did write that and I overlooked it. Mea culpa. I'll write you off-list with some entries.

- Dan C.

Received and entered. Considering I work 3rd shift and 1st shift I may not get to it in the click of a mouse but I do keep watch considering. --- Pardon my brevity, I'm on a Samsung Galaxy smartphone. --- Sent via axMail-Fax by N1URO.

On June 15, 2016 12:04:02 AM Brian n1uro@n1uro.ampr.org wrote:

(Please trim inclusions from previous messages) _______________________________________________ When you do I'll be glad to enter them in.

---

Pardon my brevity, I'm on a Samsung Galaxy smartphone.

Sent via axMail-Fax by N1URO.

On June 14, 2016 10:05:39 PM Dan Cross crossd@gmail.com wrote:

...

(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 14, 2016 at 8:26 PM, Brian n1uro@n1uro.ampr.org wrote:

...

...

No, because there is a filter at UCSD which requires you to be registered in the AMPR.ORG DNS. You are not.

...

[snip]

...

From his allocated block notes authored by me 6 months ago: Dan; You'll need to email me your DNS requests manually

Indeed, you did write that and I overlooked it. Mea culpa. I'll write you off-list with some entries.

    - Dan C.

You're good, you didn't imply anything. --- Pardon my brevity, I'm on a Samsung Galaxy smartphone. --- Sent via axMail-Fax by N1URO.

On June 15, 2016 1:22:19 AM Dan Cross crossd@gmail.com wrote:

(Please trim inclusions from previous messages) _______________________________________________ On Wed, Jun 15, 2016 at 12:46 AM, Brian n1uro@n1uro.ampr.org wrote:

...

Received and entered.

Thank you so much!

Considering I work 3rd shift and 1st shift I may not get to it in the click

...

of a mouse but I do keep watch considering.

Oh I hope I didn't imply I was being impatient; that wasn't my intent if I did.

Thanks again!

    - Dan C.

On 6/14/16 5:49 PM, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 14, 2016 at 04:57:06PM -0400, Dan Cross wrote:

...

...

From this point, I would expect to be able to 'ping 44.44.107.1' (my 44net

interface) from an external, Internet connected host and at least see an ICMP echo request. However, doing so from a random machine, I see neither an unencapsulated ICMP echo request packet on gif0, nor an encapsulated packet on cnmac0.

Trying to 'traceroute 44.44.107.1' from a machine on the Internet shows hops until I get to the amprgw at UCSD, and then nothing. Should I expect to see those make it to my router?

No, because there is a filter at UCSD which requires you to be registered in the AMPR.ORG DNS. You are not. Once that is in place you should be able to traceroute and ping your 44.44.107.1 address from anywhere on the great unwashed Internet. I would register you but I don't know your callsign.

Can you delegate out a subdomain from ampr.org to someone's nameserver? So could I, for example, have *.n5xns.ampr.org have an NS record delegated out to my own name server?

And if not, does that mean I should send you my DNS record requests, Brian?

Dan,

wouldn't a complete user space implementation be more appropriate? May you want to check my amprd 1.4 software (http://www.yo2loj.ro/hamprojects/) which includes the same functionalities like ampr-ripd except dynamic gateway resolution but does all the encap and RIPv2 handling in user space providing a virtual 44net interface to the system.

Marius, YO2LOJ

On 2016-06-18 00:46, Dan Cross wrote:

(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross crossd@gmail.com wrote:

...

I'm trying to set up an AMPRNet gateway at home and am running into

some problems. Has anyone successfully configured a BSD-based gateway that would be willing to give me some pointers?

[snip]

It seems like what I want to do is configure a gif(4) interface

for tunnel traffic, but my attempts at doing so all seem to fail, and documentation for setting up an IPENCAP tunnel is related to setting up IPsec gateways; my attempts at transliterating from the examples for e.g. Linux and Cisco et al have failed.

If someone has gone down this road before and has a working

setup, that would be tremendously helpful. If someone could send me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and possibly some 'tcpdump' output, I could probably muddle through the rest. If there are any caveats in setting up a 'pf' based firewall, that would be helpful as well. If not, I suppose my next step will be to reinstall RouterOS on the ERL, try and get everything configured, and then see if I can replicate under BSD.

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.

I'll try to go through my notes and type up something for the

wiki.

The next step is to write a modified version of rip44d for BSD.

I may take a stab at that this weekend if I can get some time. As near as I can tell, the wire format of the protocol is strictly RIPv2; the difference is what the gateway does with the data in the RIP packet (it sets up tunnels in addition to maintaining routes).

Anyway, I hope this can be of some small help to someone else

who wants to run an OpenBSD-based gateway!

    - Dan C.

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

I was to lazy to put amprd into Github, so only ampr-ripd is there.

So the only source is my server for the moment.

Marius, YO2LOJ

On 2016-06-18 21:17, Dan Cross wrote:

I'll have a look at amprd and ping you off-list; do you by chance have a github repo or something?

    - Dan C.