44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] OpenVPN
by Steve L 18 Mar '16

18 Mar '16

Thanks Corey that is the info I was seeking. For anyone else with further clarification: Server Side: - ca.crt = The latest LotW Root CA cert certs\root*, you need to break them apart an select the latest one - server.crt* = Your personal LotW cert concatenated with the intermediate that signed it. certs\user* + certs\authorities* - server.key = The private key associated with your personal cert keys\YOURCALL* *References are to the Windows TQSL program: C:\Documents and Settings\your-username\Application Data\TrustedQSL\

3 2

BGP community values
by Rob Janssen 18 Mar '16

18 Mar '16

Is there any registry or documented method for allocation values for "BGP communities" to be used inside the AMPRnet as helpers for the BGP routing? Note I am not referring to internet BGP, but to the BGP protocol used on isolated radio networks operated using private AS numbers. Some time ago we have discussed the allocation of AS numbers in the 32-bit AS space, and I would like to know if people feel a necessity for allocating (reserving) community values as well. These are 32-bit values, commonly written as two decimal 16-bit values separated by a colon, used to communicate attributes of a route. I now use one value to tell the other routers that a route is not over radio (but over internet tunnel, in this case) so inside the network it can be used as a backup route when the radio route fails. In practice there is little chance of collision of these community values, and they can easily be filtered or translated at boundaries between areas where different values are used. Originally a common practice was to use the own AS number as the first value in the 2x16bit pair, but of course that no longer works now the AS number can be 32 bits. Rob

4 3

Re: [44net] BGP community values
by Rob Janssen 18 Mar '16

18 Mar '16

> RFC4360 defines extended communities, but I don't know much more about them. > So far not I haven't seen much usage of communities within AMPR BGP networks. Of course the used routers must support it as well... > Which usages would you like to coordinate? My question is if I need to coordinate... I think probably not. The usage is to mark routes with an origin, just like Jann mentioned in his reply: we have a central gateway with VPN support and we can setup a VPN from routers in the country that are interlinked by radio links, where of course we would like the traffic to flow over the radio links unless they have failed, in which case the routing via VPN would be an alternative. For BGP to know which routes are radio routes and which are VPN routes, a "community" is the BGP name for an attribute that you can add to each separate route, at its origin. Then every router can examine this attribute and assign a lower preference value to the route. Routes with a lower preference are not used when a route to the same destination with default or higher preference is available. > Since these are arbitrary numbers, I use the first decimal part of the 32bit > address as the high word (so that the 42 + country is conserved). > Just an idea, and it works... > e.g. 42226:0 Yes, that would be a possibility. Right now I have used 44137 (our net is 44.137) but a numbering like that would be possible too. Of course this conflicts with the common practice to use the 16-bit AS as the first 16 bits, because we don't own any of those two AS numbers. Jann's proposal of using a 16-bit private AS avoids this conflict, but it is incompatible with 32-bit AS. However, in practice there is no problem because we will never see community values from an AS like 42226 or 44137 on our isolated network. (where we are using private AS numbers only) Again, for clarity, our network is BGP routed on internet, but this is a completely separate thing. BGP at the internet side is run by our ISP who advertises our 44.137.0.0/16 network on internet (under agreement with ARDC) using their own AS number, receive the data and send it over an ethernet link to our gateway, where we relay it to our radio network which also uses BGP, using private AS numbers and those community values we are discussing, but there is no BGP traffic "across" the gateway, only IP traffic to/from internet. So my guess is that any community value set up using a convenient numbering scheme to reduce the conflicts with cross-border schemes is sufficient, a more elaborate scheme like the IP address or AS number coordination is not required. (note that HamnetDB has a registration for AS numbers, but not for community values) Rob

2 1

Re: [44net] OpenVPN
by Steve L 17 Mar '16

17 Mar '16

While I appreciate the responses from everyone, no one is really explaining this in a nice step by step manner that I need. I suspect its because everyone is trying to help me learn it rather than give me the answer. The problem is the terminology compounded by extraneous info. ________________________________ >If you want to use LotW keys, you CAN NOT generaty any keys. > >Let me motivate: Well its not working. I am real close to throwing in the towel and moving on to a different project. > >- LotW has a CA certificate, and its private key. >- using those, it generates some intermediate certificates, public and >private keys. >- using those intermediate certificates, it generates the public and >private keys for the user which are sent to him. I understand all this. >To generate user keys, you NEED the private keys of the intermediate >certificates, which you do not have. These are needed to sign the newly >generated keys. I think of this as two parts, client and server. Maybe thats the wrong way to look at it, but either way user keys equates to me as client keys, which has already been documented in a simple manner. I don't need the private keys because A.) I am not asking about the user/client end of this. These are the related files in my server,conf file. I am asking where/how do I get these so that my openvpn server can be accessed by clients using the method documented in the wiki: http://wiki.ampr.org/wiki/AMPRNet_VPN ca.crt server + all clients Root CA certificate ca.key key signing machine only Root CA key dh{n}.pem server only Diffie Hellman parameters server.crt server only Server Certificate server.key server only Server Key

3 2

Re: [44net] BGP community values
by Rob Janssen 17 Mar '16

17 Mar '16

> Here you can find the proposed allocation method: > http://laru.lu/on-the-air/hamnet-44net.html <http://laru.lu/on-the-air/hamnet-44net.html> > It uses 32 bit ASNs, which are represented as a single number, the old > 16bit:16bit scheme being obsolete, but backwards compatible. I know about AS numbers but I am asking about community values, not AS numbers. Rob

3 2

Re: [44net] OpenVPN
by Steve L 17 Mar '16

17 Mar '16

>Ok, so you're trying to generate a server certificate for your VPN server. I am trying to generate/gather all the files I need for the server side so that when its done it works like yours. Where I don't have to issue client keys, and all that. (Just a config file and the public key ca.crt file). They can just follow the well documented steps in the wiki that work for yours. So I don't need to build a Certificate Signing Request after all? > >For this step, we actually do not need *anything* from LotW/TQSL side (and >can not use any)! Just use any openvpn server setup guide's instructions >for setting up a CA and generating a server certificate out from that CA. >That CA cert is then given to the openvpn client, so that the client can >make sure it is talking to the correct server. This is what I have done before. Builds a private root ca, and all the rest. ./clean-all ./build-ca ./build-key-server server ./build-key client1 ./build-dh The first line makes sure we start from scratch. The second generates a key for the Certificate Authority (ca.crt and ca.key). The key for the server itself is generated on the third line (server.crt, server.key, and server.csr) . Repeat the forth line for each client that needs to connect (client1.key, client1.csr, client.crt, etc). Finally, we need the Diffie Hellman key as well, which is generated on the fifth line (dh1024.pem). In my server config file: ca ca.crt cert server.crt key server.key dh dh1024.pem >The LotW certificates are only used for authenticating the client. The >server's "ca" config option points to the LotW root certs bundle. The >cleint's "ca" config option points to the private CA which signed the >server's certificate. A paragraph ago I thought you said build ones own private root ca... But it sounds like you are now saying I just copy: C:\Documents and Settings\your-username\Application Data\TrustedQSL\certs\root over to the server, rename it to ca.crt?

2 1

Re: [44net] OpenVPN
by Steve L 16 Mar '16

16 Mar '16

Tal, thanks for the follow up. Most of that I already knew. As I have said, I have a functioning openvpn server. The only thing it lacks is the ability to work with client keys that folks extract from their lotw credentials. I have to issue client keys to people and that is what I am trying to get away from. I really need a watered down step by step guide on how to do this till it all clicks in my mind. Multi-factor authentication is pretty confusing and new to me yet. As I have said the client key extraction and documentation in the wiki is easy to understand, I just wish the same existed for the server end. http://wiki.ampr.org/wiki/AMPRNet_VPN It appears I need to build certificate signing request (maybe I am wrong). Again its not clear to me where/how to extract the root certificate from the ARRL LOTW program.

4 5

Re: [44net] OpenVPN
by Steve L 16 Mar '16

16 Mar '16

My callsign.tq6 is binary data. However it looks like the root certificate is locate here: C:\Documents and Settings\your-username\Application Data\TrustedQSL\certs\root I noticed it looks like three stacked into one file based on the begin/end markings. But from the link Tom shared, it looks like you don't have to do anything different like break them apart, with a chained vs single. Step one (./build-req server ) went ok however stuck at step two:, root@test:/etc/openvpn/easy-rsa/2.0# ./build-key server pkitool: Need a readable ca.crt and ca.key in /etc/openvpn/easy-rsa/2.0/keys Try pkitool --initca to build a root certificate/key. root@test:/etc/openvpn/easy-rsa/2.0# I simply copied the TQSL root file over to /etc/openvpn/easy-rsa/2.0/keys and renamed it ca.crt So I am guessing I need to split each certificate into its own file? Is there anyway to support more than one?

3 2

Re: [44net] Help Not receiving ampr-ripd encap route broadcast
by Rob Janssen 15 Mar '16

15 Mar '16

> If it works without it, don't. > The -r flag will make ampr-ripd receive ALL interface traffic and filter out > multicasts in user space, while in regular operation mode that's left to the > kernel and is more efficient. > While on a big system it probably doesn't make much difference, on a limited > resource device like the PI it could. > Marius, YO2LOJ I fully agree with that! Do you have any idea why it was broken and if this has been fixed? Of course it may depend on the details like which IP address was assigned to which interface, just like the problem that you fixed in version 1.6... Probably I should test again on some different systems and kernels... Rob

2 1

Re: [44net] Help Not receiving ampr-ripd encap route broadcast
by Rob Janssen 15 Mar '16

15 Mar '16

> How can I diagnose why my ampr-ripd is not receiving the broadcast? Any > tools? Likely your problem is caused by a kernel bug that was introduced some time ago, I don't know if it has been fixed in the meantime or if it was defined as 'desirable behaviour' and left that way. Some time ago I faced the same problem, and I could only fix it by adding the -r flag ("Use raw socket instead of multicast") to ampr-ripd. In multicast mode, which used to work fine, it simply did not work anymore on the Pi. Rob

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net