Hi Michael, Thanks for clarifying.
> Wireguard can fail back to the Primary route so quickly that it is > unnoticeable when you are in a voice call. Very cool! Yes, very cool, I use that as well. > So if I did have a secondary IP Address on the wg0 interface, would I need > custom firewall rules? Keep in mind that the default setting in the WireGuard Config: _x_ Create routes for Allowed IP's for all peers As it says, it will auto-create routes for any AllowedIPs using foreign addresses. I don't think any custom firewall rules will be needed. I also don't think you need the rc.elocal "Add Secondary IP Addresses to wg0" given above. Lonnie > On Jun 8, 2019, at 10:28 PM, Michael Knill > <michael.kn...@ipcsolutions.com.au> wrote: > > 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. _______________________________________________ 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.
