Hi Lonnie Sorry for the confusion. No I will have three separate servers, one purely for management and the other two are transit switches, one primary and one backup in case the primary fails. The path the VPN takes will be completely up to the Astlinux configuration which may or may not have a failover route configured. Its actually a really neat solution whereby I don't care about any NAT or the path it takes and the testing I have done, Wireguard can fail back to the Primary route so quickly that it is unnoticeable when you are in a voice call. Very cool!
I have overcome having to reset Wireguard by adding it to the configuration and then adding the peer from the command line as follows: wg set wg0 peer <Public key of Endpoint VPN Peer collected above> allowed-ips <Allocated Endpoint IP Address>/32 Seems to work fine. May be worthwhile adding it to the GUI. As far as overlapping routes, the overlap is between individual customer Astlinux peers e.g. you could have a satellite office on 172.29.253.2/24 which overlaps with another customer Astlinux peer with the same address. This is not a problem of course unless they know about each other but this is a possibility for a multisite customer. It also means that I cant standardise the VPN gateway address at each site for mobile peers e.g. 172.29.253.1 for site 1, 172.29.253.2 for site 2 etc. None of this is insurmountable, just maybe not quite a neat as a Local /24 subnet for local peers and a separate subnet for the three upstream servers (not three separate subnets as I first mentioned). So if I did have a secondary IP Address on the wg0 interface, would I need custom firewall rules? Regards Michael Knill On 8/6/19, 11:20 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote: Hi Michael, A single /24 looks simpler to my eye ... very similar to how I do it myself. > Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. Overlapping routes ? I don't see any, all basically point-to-point in your internal WG 172.29.253.0/24 net, so far. > It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers. Can you explain what you mean by "messy" ? === As an aside, I'm trying to think how the "clients" could be configured as "Mobile Clients" on one of the "servers". As it is now, adding or removing a "client" requires restarting WireGuard on each of the three servers to apply changes. Michael, correct me if I am wrong, but your current parallel design: client --|-- Primary --|-- Secondary --|-- Management is to allow each 3 paths to go over different transports (PPPoE, Cable, 4G/LTE). But, if you can cleverly use WAN Failover to swap network paths (PPPoE, Cable, 4G/LTE) using this layout: client --|-- Primary --|-- Secondary --|-- Management In this case only the Primary server needs to know about the clients credentials, and *if* the clients only need a single WG IP address (no client LAN routing over WG) then clients could be auto-assigned "Mobile Client" credentials with IP's in the .101 to .199 range. "Mobile Clients" can be added and removed in realtime without restarting WireGuard. Lonnie > On Jun 7, 2019, at 11:40 PM, Michael Knill <michael.kn...@ipcsolutions.com.au> wrote: > > Thanks Lonnie > > Yes I'm replying to the original post and yes I do recall now talking about that. > Hmm maybe I can just use a /24: > > -- All 3 upstream servers -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.253.[252|253|254]" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Peer 1 > PublicKey = ### > AllowedIPs = 172.29.253.1/32 > > [Peer] > # Peer 2 > PublicKey = ### > AllowedIPs = 172.29.253.2/32 ........> > > [Peer] > # Peer 100 (Note 101-199 used for Client peer's Remote Peers) > PublicKey = ### > AllowedIPs = 172.29.253.100/32 > > -- Client -- > gui.wireguard.conf: > WIREGUARD_IP="172.29.253.[1-100]" > WIREGUARD_NM="255.255.255.0" > > wg0.peer: > [Peer] > # Management Server > PublicKey = ### > Endpoint = management01.ipcaccess.net > AllowedIPs = 172.29.253.254/32 > PersistentKeepalive = 25 > > [Peer] > # Primary Server > PublicKey = ### > Endpoint = primary01.ipcaccess.net > AllowedIPs = 172.29.253.253/32 > # No keepalive required as SIP Options ping will keep it up > > [Peer] > # Secondary Server > PublicKey = ### > Endpoint = secondary01.ipcaccess.net > AllowedIPs = 172.29.253.252/32 > # No keepalive required as SIP Options ping will keep it up > > [Peer] > # Another Astlinux box peering to us > PublicKey = ### > AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> > # No keepalive required as SIP Options ping will keep it up > -- > > Hmm it certainly is unusual as there are overlapping routes everywhere but they just don't know about each other. It will certainly also get messy if Astlinux boxes peering to us are also peering to the 3 upstream servers. > So would Secondary addresses actually work if I did it purely for my sanity? > > Regards > Michael Knill > > On 8/6/19, 12:33 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote: > > Hi Michael, > > I seem to recall discussing this before, but why the 3 separate /24 networks requiring a rc.elocal rather than one /22 network set by the WG configs ? > > # netcalc 172.29.200.1/22 > Address : 172.29.200.1 10101100.00011101.110010 00.00000001 > Netmask : 255.255.252.0 = 22 11111111.11111111.111111 00.00000000 > Wildcard : 0.0.3.255 00000000.00000000.000000 11.11111111 > => > Network : 172.29.200.0/22 10101100.00011101.110010 00.00000000 > HostMin : 172.29.200.1 10101100.00011101.110010 00.00000001 > HostMax : 172.29.203.254 10101100.00011101.110010 11.11111110 > Broadcast: 172.29.203.255 10101100.00011101.110010 11.11111111 > Hosts/Net: 1022 Class B, Private network (RFC1918) > > > Other than that, with only a quick glance, it looks like you understand the elegance of WireGuard. > > Also I see you noted: > -- > # No keepalive required as SIP Options ping will keep it up > -- > which is probably just fine, though there is not much added overhead if "PersistentKeepalive = 25" is also set possibly on the remote non-"SIP Options ping" peer, just something to file away in your mind. > > Lonnie > > > >> On Jun 7, 2019, at 8:57 PM, Michael Knill <michael.kn...@ipcsolutions.com.au> wrote: >> >> Hi Group >> >> I would like to bring this up again as I have begun development of a transit switch for my customers (using Astlinux). >> The architecture will be both a primary and secondary server for the transit switch with regular synchronisation from Primary to Secondary. Both will have trunks to my upstream SIP provider with active/active redundancy. >> All customer Astlinux boxes will connect via Wireguard VPN as a client to 3 servers being Primary Transit, Secondary Transit and a Management server (I would rather not manage through the Transit servers). The customer Astlinux box could also be a VPN server for other satellite sites and user Remote Peers. >> Should this config work? >> >> -- Management Server -- >> gui.wireguard.conf: >> WIREGUARD_IP="172.29.200.254" >> WIREGUARD_NM="255.255.255.0" >> >> wg0.peer: >> [Peer] >> # Peer 1 >> PublicKey = ### >> AllowedIPs = 172.29.200.1/32 >> >> [Peer] >> # Peer 2 >> PublicKey = ### >> AllowedIPs = 172.29.200.2/32 ........> >> >> [Peer] >> # Peer 200 >> PublicKey = ### >> AllowedIPs = 172.29.200.200/32 >> >> >> -- Primary Server -- >> gui.wireguard.conf: >> WIREGUARD_IP="172.29.201.254" >> WIREGUARD_NM="255.255.255.0" >> >> wg0.peer: >> [Peer] >> # Peer 1 >> PublicKey = ### >> AllowedIPs = 172.29.201.1/32 >> >> [Peer] >> # Peer 2 >> PublicKey = ### >> AllowedIPs = 172.29.201.2/32 ........> >> >> [Peer] >> # Peer 200 >> PublicKey = ### >> AllowedIPs = 172.29.201.200/32 >> >> >> -- Secondary Server -- >> gui.wireguard.conf: >> WIREGUARD_IP="172.29.202.254" >> WIREGUARD_NM="255.255.255.0" >> >> wg0.peer: >> [Peer] >> # Peer 1 >> PublicKey = ### >> AllowedIPs = 172.29.202.1/32 >> >> [Peer] >> # Peer 2 >> PublicKey = ### >> AllowedIPs = 172.29.202.2/32. ........> >> >> [Peer] >> # Peer 200 >> PublicKey = ### >> AllowedIPs = 172.29.202.200/32 >> >> >> -- Client -- >> gui.wireguard.conf: >> # This range is used for peers to us that we are a server e.g. satellite sites and users >> WIREGUARD_IP="172.29.253.1" >> WIREGUARD_NM="255.255.255.0" >> >> rc.elocal: >> # Add Secondary IP Addresses to wg0 >> ip addr add 172.29.200.1/24 dev wg0 >> ip addr add 172.29.201.1/24 dev wg0 >> ip addr add 172.29.202.1/24 dev wg0 >> >> wg0.peer: >> [Peer] >> # Management Server >> PublicKey = ### >> Endpoint = management01.ipcaccess.net >> AllowedIPs = 172.29.200.254/32 >> PersistentKeepalive = 25 >> >> [Peer] >> # Primary Server >> PublicKey = ### >> Endpoint = primary01.ipcaccess.net >> AllowedIPs = 172.29.201.254/32 >> # No keepalive required as SIP Options ping will keep it up >> >> [Peer] >> # Secondary Server >> PublicKey = ### >> Endpoint = secondary01.ipcaccess.net >> AllowedIPs = 172.29.202.254/32 >> # No keepalive required as SIP Options ping will keep it up >> >> [Peer] >> # Another Astlinux box peering to us >> PublicKey = ### >> AllowedIPs = 172.29.253.2/32,<other accessible routes at the satellite site> >> # No keepalive required as SIP Options ping will keep it up >> -- >> >> Can anyone see problems with this configuration? >> >> Regards >> Michael Knill >> >> From: David Kerr <da...@kerr.net> >> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Date: Tuesday, 1 January 2019 at 6:21 pm >> To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Subject: Re: [Astlinux-users] Multiple wg interfaces >> >> Michael, >> A single wg interface can have multiple IP addresses. They can be different subnets too. You will have to manually edit the config files. >> >> David. >> >> On Tue, Jan 1, 2019 at 6:37 AM Michael Knill <michael.kn...@ipcsolutions.com.au> wrote: >>> Hi group >>> >>> Here is my scenario. I have primary and backup Wireguard VPN Peers that multiple Astlinux boxes will be connecting to. >>> I assume that I will need different wgx interfaces for this as I cant have the same IP Address. >>> If so, just wondering how to set this up in Astlinux? >>> >>> Regards >>> Michael Knill >>> _______________________________________________ >>> Astlinux-users mailing list >>> Astlinux-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users >>> >>> Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org. >> -- >> David Kerr Sent from Gmail Mobile >> _______________________________________________ >> Astlinux-users mailing list >> Astlinux-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org. > > > > _______________________________________________ > Astlinux-users mailing list > Astlinux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org. > > > > _______________________________________________ > Astlinux-users mailing list > Astlinux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org. _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org. _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.