Lynwood,
Please tell me more about your version of DD-WRT.
I have: Firmware: DD-WRT v24-sp2 (08/07/10) std, and it does not pass
IPIP rip packets, unless I enable DMZ.
------Clip----
It's noted that IPIP does not traverse firewalls, that is not the
case with me, as I am traversing two firewalls to reach my Gateway
server, both devices using using DD-WRT, and it appears to broadcast any
packet that is not UDP or TCP. ......
Thanks for sharing that note about DD-WRT broadcasting any packet that
is not UDP or TCP.
I wouldn't mind compiling a list of other home grade gateway/modems
that do or don't do the same, if anyone else has that info to share.
To clarify my note about securing with IPtables, I was referring to
the outside addresses. As in dropping all (non-44) inbound IP's that
are not listed as a gateway.
------Quote------
All,
A few points and questions:
1.) It's noted that IPIP does not traverse firewalls, that is not the
case with me, as I am traversing two firewalls to reach my Gateway
server, both devices using using DD-WRT, and it appears to broadcast any
packet that is not UDP or TCP. In fact, I also run a IPv6 tunnel on a
Vyatta instance in the same manner. Also, depending on the firewall's
NOS, it can be permitted through configuration (granted, you must have
control of that network device).
2.) KB9MWR asked if anyone was using a firewall or IPtables, I do
firewall my 44 Network, and only permit forwarding on that network for
44 hosts (i.e. someone could send an enscapsulated packet for any AMPR
subnet and it will be forwarded via my GW, all other IP addresses are
dropped at the firewall). I also restrict/permit services to certain /32
IP addresses, etc. In addition, some hosts on my network are only
available on AMPR and/or ACLs only permitting 44 hosts to use those
services (e.g. my DNS ACL permits full recursion for 44 hosts and allows
only 44.in-addr.arpa and ampr.org resolution for all others).
3.) Would this VPN system allow me to use my 44Net allocation, or only
the allocation located at the VPN server itself?
4.) It is my understanding that the ARRL CA is not online, this would
require manual revocations, manual trusts (I'm not very familiar with
VPN via certificate)?
73,
Lynwood
KB3VWG
OpenVPN does this by default. It always assigns the same IP based on
the client certificate. That mapping is stored in
/etc/openvpn/ipp.txt
Here is some documentation I have been working on. I see I didn't
explain that part very well.
http://www.qsl.net/kb9mwr/wapr/tcpip/openvpn.html
73'
Steve, KB9MWR
------Quote------
I was wondering if it were possible for a VPN server package to
consistently assign a specific, reserved IP address to a VPN client based
on the authenticating certificate.
The scope of the VPN server would be subject to the region/subnet coordinating
contact, such as a portion of:
Gateway area: 44.80.32/24 Central Pennsylvania
Thanks for your consideration.
73,
Jim A.
KB3TBX
I was wondering if it were possible for a VPN server package to
consistently assign a specific, reserved IP address to a VPN client based
on the authenticating certificate.
The scope of the VPN server would be subject to the region/subnet coordinating
contact, such as a portion of:
Gateway area: 44.80.32/24 Central Pennsylvania
Thanks for your consideration.
73,
Jim A.
KB3TBX
Ciao Hessu,To answer shortly...a) Connecting via OpenVPN we permit to access to all of 44/8 amprnet, to all our "private" management network 10/8; we are vorking just these days to publish to big Internet radioham services reaching CisarNet via OpenVPN, using static 44.208/16 ip addresses directly routed to big Internet (under amprnet agreement);b) More or less we are using the same verify procedure around amprnet...We could not say that it is a strong authentication or biometrics solution, but it's working ;-): are you interested on ?c) We are using 44.208/16 addresses also directly on radio link, for radioham purpose but exposed on big Internet. In some case VPN links are used to backup radio link (using OSPF routing protocol with different weighted routes), and we are simply considering big Internet as Radio...so, same rules! Full compliance to regulatories and amprnet policy.
Concluding, at the beginning we supported OpenVPN extension to try to find an easy "workaround" when you have not radio connection to CisarNet/amprnet, nor a public ip address for tunneling using ip2ip, but at the same time you'd like to connect to CisarNet and/or amprnet. Now, in a classic solution, you have a main gateway using OpenVPN client connect to CisarNet backbone, and your "local" ham wireless network around you covering your near towns. In this way we consolidated new isolated wireless radioham small networks, using ready-to-connect CisarNet ip addressing, rules, services, and so on.
Ciao from Italy.
Thank you for this opportunity to "compare" different approach, I believe anyway both of them are interesting.
IW0SAB Renzo.
I'm not sure if I understood right... just to check, are you allowing access to all of 44/8 amprnet via this VPN? Or just to your local 10.x network over there?
Are you giving VPN access to anyone with a common signed key? Do you somehow verify that those users are amateurs, or can anyone download the key+certificate from somewhere?
Our regulations over here prevent us from using crypto on radio, which is good and fine. The regulations don't prohibit using crypto on the Internet. The VPN provides strong authentication, the encryption is a side-effect which does not really matter much to one direction or the other. We need to do authentication and license verification to prevent non-ham access to the radio channels - looking up from logs afterwards isn't of much use.
- Hessu
I never really had an interest in log book of the world till now.
So I just signed up, and awaiting their postcard or whatever.
Using those certificates sure seems like a logical way to keep the
network secure.
I have been wondering if anyone running a IPIP gateway applies any
security by locking it down with iptables to only the other known
gateways.
Perhaps this could be worked into rip44d as an option?
This is essentially what D-Star the dssecd D-STAR Gateway security
enhancement application/daemon does.
At that point the only issue is who is allowed to create a gateway in
the portal. And perhaps that is where this ham verification technique
could be applied.
I realized it was a return route issue on my way to work yesterday.
It's all working now.
Thanks again
------------ Quote ------------
One thing to check would be if the VPN client has a route for 44/8 pointing
through the VPN ("ip route" on the client). The VPN server should give the
client the route using a directive in the server config:
push "route 44.0.0.0 255.0.0.0"
Ciao Hessu,
just to share our experience in using OpenVPN solution to access CisarNet (http://wifi.cisar.it for the map, http://www.cisarnet.it for other services, ...),
Before to setup the solution (about three years ago), inside our working group we discussed about using named certificates, Certification Authority, user registration process, crypto and so on...
At the end, we decided just to share one only common signed key, and also permit free guest access without user identification (just as equivalence to radio Push-To-Talk button), no crypto (for regulatory compliance in several country for radio ham radio communication, Italy included). Storing logs permit us to be compliant to law about taking care of timestamp, ip source of the VPN client peer and destination ip public address. Also, in this way we are extending in Italy the usage of amprnet, by managing directly the CIDR 44.208/16 subnet as Internet IP public Address.
I hope this help you to know our point of view, a little different from yours, but also useful for share several experiences (thanks to your well done guide on ampr wikis). We'd like also to know your (and others) opinion about Italian Cisar association approach to OpenVPN access.
Ciao from Italy.
IW0SAB Renzo.
>----Messaggio originale----
>Da: hessu(a)hes.iki.fi
>Data: 08/05/2013 0.42
>A: "AMPRNet working group"<44net(a)hamradio.ucsd.edu>
>Ogg: [44net] VPN access to AMPRNet using amateur X.509 certificates
>
>(Please trim inclusions from previous messages)
>_______________________________________________
>
>Hi,
>
>The AMPRNet might be more useful if it had:
>
>(1) more services which would be interesting to hams
>(2) more access to the AMPRNet
>
>Tonight I tried to attack (2) a bit. Access to the AMPRNet over the
>Internet could maybe be made easier to hams by allowing them to connect
>over VPNs instead of setting up their own IPIP tunnels at home, or trying
>to find a working radio gateway. After getting a VPN running it might be
>easier for them to set up a radio gateway, or some services. As discussed
>on the other mailing list, VPNs are easier to get up on NATed residential
>networks than IPIP tunnels.
>
>Setting up VPN user accounts and maintaining them can be a pain. It
>doesn't take a lot of weekly or monthly maintenance work to run a VPN
>service, but it can be a major pain to manage an user account database for
>thousands of hams and check if your users around the Internet are, in
>fact, licensed.
>
>It turns out that ARRL's Logbook of the World has already given out
>cryptographic X.509 certificates to 57334 amateur users, after verifying
>their license status against the FCC database (they send a postcard with a
>random token code to the FCC-listed snail-mail address to make sure they
>give the certificate to the right guy) or after looking at a paper
>photocopy of a license + a photo ID. I had to physically mail in a photo
>of my ham license and my driver's license and wait a couple weeks to get
>the cert. If they can get 50k contesters and DXers to work with
>certificates, maybe certs can work for the AMPRnet, too.
>
>Technically, we can validate if a VPN user is in possession of one of
>those certificates and the respective private key. Politically, K4JH asked
>the ARRL guys, and they said that they don't mind if we use them for other
>ham authentication needs. We can start accepting other CAs too once they
>come around. I plan to help SRAL, the Finnish amateur radio union, to set
>up a CA within their web site (they already have user accounts for
>members). I know ARRL isn't for everyone, but smaller clubs could set up
>CAs too, or even commercial entities - as long as we trust them to do the
>license validation in a proper manner.
>
>Tonight I hacked up an OpenVPN setup which authenticates users with LoTW
>certs, and wrote a little documentation:
>
>http://wiki.ampr.org/index.php/AMPRNet_VPN
>
>What do you think? Technically, it seems to work - try it out if you like.
>It's not very straightforward to set up, but the license validation is
>pretty strong, and running the service shouldn't be a lot of work. There
>can be many VPN servers around the world, serving the whole customer base
>(VPN servers do not need access to any central user database, they just
>need the certificates of the trusted CAs). With a little Dynamic DNS
>magic, you could get a oh7lzb.vpn.ampr.org hostname on DNS within a few
>seconds after connecting (I've got code for that in another project).
>
>(Yes, eventually certificates need to be revoked after they accidentally
>get into wrong hands, or ham licenses are revoked. Technically that can be
>done using CRLs and/or OCSP, but ARRL apparently does not do those yet.
>Maybe they will, if the need arises. We can also set up a blocked
>certificates list of our own.)
>
> - Hessu, OH7LZB
>
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
>http://www.ampr.org/donate.html
>
Thanks for refreshing my memory. I am really rusty at this, since
they have made home networking plug and play.
I have IP forwarding enabled.
root@ampr-test:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Could you give an example of what I need for iptables forwarding rules.?
Steve