Background: N2MO is a multi-multi station. Each operating position has a workstation for logging and other uses.
The N2MO network is a flat class "C" in 10 net. Workstations are DHCP, assigned by the windows server. Servers, printers, clocks, cameras are static.
We are in-process to connect via VPN (and later direct fiber) to our academic partner. They use 10 net as well, however they carved out the class C we are using. A domain trust is under construction.
Firewall:
Port 1 LAN
Port 2 WAN (Cable Modem)
Port 3 AREDN
Port 4 Future fiber to academic partner
Basic problem: The academic partner is all over 10 net. How do we stop AREDN from duplicating a 10 net address already in use?
The intent is not to allow AREDN traffic from exiting the N2MO LAN to the academic partner.
73 Martin
If the WAN of AREDN is on the N2MO it's RF network will be isolated from the N2MO LAN.
A user plugged into the LAN could still access the directly connected range to the node (or anything I'd the default gateway is set to be out that interface). The only issue than would be the very small (2^8 out of 2^24) chances that an AREDN node is in the same subnet as the the N2MO network blocking access from LAN to N2MO network
If a computer plugged into the AREDN LAN needs to be accessible to a user on the N2MO net you can use a WAN to LAN port forward.
Path selection for someone plugged into the LAN port is as following priority: local network plugged into WAN, known mesh nodes, gateway out WAN, Gateway out Mesh whichever one hits first gets access.
Lan to WAN is NAT masqueraded as is mesh to WAN if you use the MeshGW feature (otherwise access is blocked on Mesh to Wan
Another option is to to just treat the N2MO network as an 'internet' connection and create tunnels between mesh nodes (all users plug into a "lan" network on the mesh node) and become directly accessible to each other both over RF mesh and wired "tunnel" mesh at their full 10.x address (which will not be in the N2MO network but you wouldn't need to get to the N2MO net you would go to the mesh network. This allows you the advantage of being able to access all the systems remotely if you want from any mesh node (the system will choose the best path which will often be the wired network unless it fails than it will try and find an RF path to get to them)
To confirm (and some guessing) to see full picture--are the below definitions correct? Some potential twists in all the options given AD involvement--issues across NAT (not supported by MS) and permission issues across domains/workgroups to get everything working--no doubt all solveable or something that can be worked around.
1) Devices on N2MO LAN on Port 1 of your firewall:
a) need to route to and potentially talk to any device on Port 4 academic partner
b) need to route to and potentially talk to any device on Port 3 - AREDN
c) Users and machine policies managed under N2MO windows domain
d) N2MO domain controller requires 1-way (or 2-way?) trust to Academic domain controller
2) Devices on Port 3 - AREDN:
a) shall not know about and/or route and talk to any device on Port 4 academic partner
b) need to route to and potentially talk to any device on Port 1 - N2MO LAN
c) are not managed under any windows domain
d) shall have access (or not?) to Port 2 WAN - internet
3) Devices on Port 4 - Academic partner
a) shall not route and/or know about devices on Port 3 AREDN
b) will route and talk to potentially any device on Port 1 LAN N2MO
c) shall not route to Port 2 WAN - internet access (separate access)
Pretty much dead on.
One way trust for the moment
AREDN may have tunnel access to the N2MO Internet at a later date.
At the end of the day, the options to manage IP allocations with another network necessitate getting into each mesh node (a router) and manually configuring in linux (or re-coding the setup UI). This isn't something that the simplied AREDN perl UI was designed to do. We could start talking about tweaking source code to stay within an IP allocation, but then the routing issues still present hurdles.
All of these options should only be persued if you are or have an IT expert (that knows linux) available to help you--otherwise it will be painful.
So here's an idea that completely gets around the IP conflict issue, but it pushes the problem elsewhere. It stil necessitates IT networking skills, but minimal linux knowlege.
Consider if both the N2MO and the AREDN networks were connected to the internet (or a pass-through network you created on say 172.16.x.x). This is a NAT masquarded gateway same as any home router going out to the internet. Both networks see each other as 1 IP address, say 172.16.0.100 and 172.16.0.101 (or the IP addresses from the ISP). All you need to do at this point is 'port forward' the services through that you wish to pass in both directions.
On the AREDN gateway node, to do this port forward, one edits the /etc/config/firewall config file and adds a rule (example below) to make avaialble a service anywhere on the mesh that you wish to be accessed externally (do this in /etc/config.mesh/firewall also). As an example if you had a laptop on the mesh somewhere hosting a web site, the addreses would look like this:
Laptop 1 mesh IP and web server: 10.123.45.63:80
Known outside (on N2MO network) as: 172.16.0.100:8084
Laptop 2 mesh IP and web server: 10.42.36.109:80
Known outside (on N2MO network) as 172.16.0.100:8085
The reverse setup is the same, to port forward into a service on the N2MO network. Here's what the firewall rules look like on the AREDN gateway node:
config redirect
option name 'http8'
option src 'wan'
option proto 'tcp'
option src_dport '8088' <- external port
option dest_ip '10.116.207.50' <- internal IP address of device across the mesh
option dest_port '80' <- internal port
option target 'DNAT'
option dest 'wifi'
config redirect
option dest 'wifi'
option src 'wan'
option src_dip '10.84.38.164' <- IP of the self gateway node
option dest_ip '10.116.207.50' <- internal IP of the mesh device
option dest_port '80' <- internal port
option target 'SNAT'
Sorry, not a lot of easy answers here and while this option could work, it still has usability issues.
Joe AE6XE
Joe,
I'm going to have to ponder the interconnection of AREDN to the station LAN a bit. It looks like we are getting in to diminishing returns for the effort involved.
We are going forward with building portable systems for event support and disaster recovery.
Martin
W2RWJ
I was discussing this issue with my local Cisco IOS resource. He is of the opinion that in this *specific* case we would be better off using NAT on separate hardware to shift the AREDN 10 net traffic to 44 net, and deal with the routing on the firewall itself.
We have a suggestion of an Cisco HWIC-4ESW-POE in a CISCO 2800 router to supply power for the 3 sectors and do the NAT.
I expressed a concern that the device does not have enough memory for an entire class "A", supposedly you can use wildcards to get around this.
Will report back after testing this configuration.
73 Martin
W2RWJ
Ref: http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation...
This Cisco router supports 48volt devices. The UBNT devices are 24volts max. Don't know if the POE standards the module is advertised to support are somehow able to recognize the 24volt requirement... But I woulnt risk it without further confirmation.
Andre, K6AH
Andre,
I am looking at the TYCON TP-POE-1824 set for 18 volts. Will let you know hw it works
Martin
W2RWJ
It would appear to be a valid solution. I have not used one personably, but by design it will take 802.3at/af to the power voltage and pinout that Ubiquiti needs, and would appear to have enough current capability (matching that of the Ubiquiti 802.3af converter) so I don't see an issue with it and being able to be set to 18v means it will be less likely to "bake" the unit at max voltage so a good combination.
Martin,
I think your approach using the dedicated firewall to handle 10./44. network translations makes sense given the scope of services and addresses involved and your timeframe.
Noting the capabilities of the referenced Cisco FW device, it would be cool if there was an open source Linux package that could implement the core functionality. http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation
Then you could take an off the shelf box like a Jetway and load it up.
Putting too much in a Ubiquiti node could chew memory and possibly CPU pretty quickly.
If you have the Cisco device then this is academic for OMARC. I can meet you at the club one evening if you have time.
Note to all others...I am a member of OMARC even though I live in Bergen County, as it is near AT&T's Middletown R&D Lab.
73,
Gordon, W2TTT
201.314.6964
These private address conflicts, and the NAT/port forwarding kludges required to overcome them, is a very powerful argument for IPv6.
Not really. Linux already has excellent IPv6 support (I have been using it heavily for years) and it looks to me like olsrd also has IPv6 support.
I think I'll try to fire it up on a bunch of my own Linux machines and see what happens.
IPv6 is really nice. The #1 feature is that it makes NATs obsolete and returns the Internet to how it was in the good old days, with each host having a globally unique address and everyone able to talk directly to everyone else. It's hard to oversell how great this is. Distributed, peer-to-peer applications become easy again. (This is important in emergency communications because centralized servers are a serious potential point of failure.) No more manual forwarding of individual ports just to get inward access to a single service on a single server. No more UPnP, SOCKS, ICE, STUN, application level gateways and other kludges to try to get around NATs automatically. The fact that there are so many NAT traversal schemes shows both how much of a problem NATs are and that no one scheme works very well.
There are some other ancillary benefits to IPv6 that greatly simplify configuration, especially in ad-hoc networks. DHCP is still available but you can often get along quite well without it thanks to stateless autoconfiguration. Prefix delegation lets an ISP hand blocks of addresses to a customer router, which can then pass them onto its local users. Although this is usually done at just one level, I don't see anything to keep you from doing this recursively. Because nearby nodes will now have similar prefixes, it becomes easy to coalesce routes in kernel routing tables and in routing protocol updates. This can let an ad-hoc network scale to a very large size as compared to one in which each node has a randomly chosen address independent of topology and every single node has to be advertised and routed individually.
Because the address space is so large and it's so easy to give every node a globally unique address, problems like conflicts between AREDN/BBHN's use of network 10 and an existing network's use of the same block simply vanish. If you still wish to do flat routing, individual addresses can be generated at random with a vanishingly small probability of colliding with someone else's choice. (Collisions in the IPv4 network 10 space are inevitable if AREDN/BBHN continues to grow. If you reach just 4096 nodes on a network, you'll have a roughly 50% chance of a collision somewhere in the network with random generation of the lower 24 address bits. (You can't count on every node being a Ubiquity with its MAC addresses for IPv4 address generation.)
IPv6 addresses are big enough that we can consider embedding our call signs in them, although I'm not sure this is always a good idea or what the best way to do it would be.
I think we'd all love to get to IPv6--the choir is singing along. Want to help us get there faster?
I suspect olsr has some risks -- it's a stability question. We've pushed out the olsr secure connect due to lack of olsr.org support and a sufficiently robust solution (well, it didn't work at all) until a olsr-v2 production release exists (or other better option). Doing an IPv6 transition with olsr on v1 needs investigation if the solution has sufficient stability to use. For this release and next we're focused on other invasive items, like replace UI/perl with UI/Luci.
Joe AE6XE
I'm still scratching my head a bit about the use of automatic 10-net addressing. It seems counter-productive for everyone using 10-net addressing at their local sites and requires NAT basically everywhere that want to connect to resources on the mesh (unless someone was only using 192.168/16 or 172.16/12 address space). Perhaps it is my disdain for NAT in general whenever avoidable, or just the whole "KISS" mindset I try to have.
Is there a reason not to just apply for and use allocations from within the 44/8 address space? Yes, you can still NAT before going to the Internet. At some point if you desired no NAT anywhere (from Mesh to Internet), you could tunnel the 44 space back to San Diego (or route it directly if you can speak BGP with your ISP). But by using 44 address space and everyone applying for and managing their allocations, it seems, well, frankly just logical to me.
Consider this: what if you have an AREDN device die? You replace it, and all your addresses change. You have to re-write all your NAT and FW rules. That just seems... troublesome at best. Working in IT, I just recognize that devices will fail, and having spares on the shelf and a documented method to restore a failed device config and restore service as if the original device had never failed is the way to go.
Am I missing something? Plug and play sounds nice, except the reality is that somewhere you need something to map addresses to resources, be it DNS or NAT or whatever, and having addresses change just seem to be the opposite of plug and play.
Please enlighten me.
PS - I'd love to see IPv6 support. I drank that Kool-Aid in 2001 (connected to Sprint's 6-Bone) and haven't looked back. Now all the clients have native support, the mesh should as well. Hmm, we really should have AMPRNETv6.
This thread is a year old and the questions being brought forward not appear to me to be directly related to the original post.
I believe some of your questions may be answered in other threads. If not I believe a new thread would probably be a better location to bring these up so that they do not get mingled with another topic making it easier for others in the future.
Sure thing. I'll start a new thread on it: http://www.aredn.org/content/why-automatic-10-net-addressing