Thanks Lonnie.
I'm looking forward to having a play.
Regards
Michael Knill
On 9/6/19, 9:43 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
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.
_______________________________________________
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.
