...I have my machine all set up to route packets through my local gateway(I
was originally going to tinker with high speed mesh networks but an
equipment supplier let me down) and I got thinking: what kind of services
are intended to run over the new improved 44net? I've being lurking, and I
see are discussions on VPNs, routing and stuff but nothing higher up the
stack.
Web servers? Twitter-like services? Bulletin boards? POP3? What can we *do*
with it?
Please forgive me for asking this question! I get the feeling everyone else
is up to speed except me!
73
de Matt M0ZAI
Well I don't know what to tell you. I should really try DD-WRT on
other hardware to see if it behaves differently (I can't imagine so)
I have the standard dd-wrt build, Firmware: DD-WRT v24-sp2 (08/07/10)
std on a Ubiquiti Router Station pro.
With two terminals open on my linux server, one running rip44d -v and
the other running tcpdump, and an entry in the portal, I see nothing.
Shortly after I enable DMZ, set to 192.168.1.100 (my linux servers
inside address) I see them.
I logged into the DD-WRT terminal and ran iptables -L, before and
after enabling DMZ in the GUI to see what it changes.
the magic appears to be this line:
target prot opt source destination
ACCEPT 0 -- anywhere 192.168.1.100
This is under the Chain FORWARD (policy ACCEPT)
That line is absent without DMZ enabled.
I have no rules that specify a broadcast address. That is really the
only way I can imagine IPIP reaching a machine on the inside of a
network, without a specific forwarding rule directing it to a specific
inside IP address.
Lynwood, could you share a dump of your iptables -L (sanitize as needed)
Curiosity has the best of me at this point.
Steve, KB9MWR
Lynwood,
Thanks for the info. It must have something to do with the mega
version of DD-WRT that you are using. I am using the standard
version, and it does not pass, even with the VPN passthough options
enabled.
I see the mega version has IPV6 support. Since that is usually
tunneled, I suspect that is what makes it work for you.
-
Question for anyone. Is there anyway to use the ampr.org name service
as a dynamic dns?
For my IPIP gateway, and other ham radio related things, I have have
been using dyn.com to provide a dynamic dns name.
With the new http://dyn.com update policy,, makes me think the ham
community could use a dynamic dns of their own.. anyone?
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