Hi, Le 15/03/2019 à 19:03, Rob Janssen a écrit : Our future design should be able to take care of that. It's a mix-and-match between our old custom design (using private addressing) and AMPRNet IP addressing : - We are an island, so our network will be managed as a "closed" network, with only two gateways to "the rest of the world", in two data centers located in the two the main cities. - Our "internal" network will use radio links when possible, and VPN links when not. Our VPNs are made with OpenVPN running on OpenWRT boxes (called TKBoxes). This makes them 100% Plug-and-Play, which has shown to be very useful and reliable over the years in various situations where IP-IP would have been unusable (end-users with poor network skills, low points hosted by third-party partners over which we have no control, ISP resetting their boxes thus loosing port openings, specific business ISPs where all outgoing traffic except 80 and 443 is closed, etc...) - Our "internal" net will use OSPF where redundant or meshed links are available - We'll use 44.190 addressing for all things that need to be reachable from Internet (Web servers, VoIP, Echolink, XLX, DMR, OpenBridge, etc...). This subnet is already announced in BGP. - We'll use 44.168 addressing for all "internal" addresses (machines that are purely HAM, that won't have to be reachable from Internet, but that should be reachable from AMPRNets/HamNets). We planned to announce them in BGP, too. At this point, it's still unclear whether we'll need a specific VPN tunnel with iBGP to reach German networks or not. In fact, our design is just like a tiny German network, but in a closed area(an island), and with Internet routing in mind (each site can have both 44.190 "public" addresses, and 44.168 "private" adresses). We then split the problem in two parts : - "internal" things (fully handled by us, whatever the rest of the world does) - "gateways" managing connections to the rest of the world. All routing/firewalling/tunelling problems will have to be handled there (and only there) As we'll have only two gateways, this should make things easier (I hope !) -- Most of the things involved in this topology have been tested individually, but we still need to glue them all together, and migrate our old 10.44 addressing scheme to this new one. If someone sees any inconsistency or discrepancy in this design, please tell, before it's too late, HI :-) We'd like to start migration ASAP... 73 de TK1BI