Ah thanks Lonnie. Yes this is when I'm using one-way peers. Problem is that yes
Asterisk does bail quickly but then complains about it in the logs.
Two-way endpoints are out of the question unfortunately. Do you think there is
any way to fool it e.g. add a dummy endpoint or would this break stuff or be
very inefficient?
I'm thinking to reduce the problem I will only use VPN when I need to e.g. when
behind NAT, failover, dynamic address etc. and use direct trunk all other times.
Regards
Michael Knill
On 15/5/22, 11:34 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
Hi Michael,
That is what WireGuard does if there is no "Endpoint" and the peer route is
down.
Simple examples ...
Example #1
-- wg.conf snip (no Endpoint) --
[Peer]
## hpe-ms|pbx-pve
PublicKey = ...
AllowedIPs = 10.4.0.15/32
--
# fping 10.4.0.15
10.4.0.15: error while sending ping: Destination address required
10.4.0.15 is unreachable
Note: fping returns immediately
Example #2
-- wg.conf snip (with Endpoint) --
[Peer]
## hpe-ms|pbx-pve
PublicKey = ...
Endpoint = 10.10.10.15:51820
AllowedIPs = 10.4.0.15/32
--
# fping 10.4.0.15
10.4.0.15 is unreachable
Note: fping returns after a few seconds of trying
So, if you have one-way established WireGuard peers, this is working as
efficiently as possible. This allows Asterisk to bail quickly.
Alternatively if you have two-way established WireGuard peers, each end's
peer can contain a "Endpoint" which will try to establish the tunnel and only
return "unreachable" if it can't.
Lonnie
> On May 14, 2022, at 10:07 PM, Michael Knill
<michael.kn...@ipcsolutions.com.au> wrote:
>
> I use Wireguard VPN’s extensively and our softswitch has many peers
connected to it.
> One issue that is very annoying is that if a VPN route drops out of the
routing table, rather than just Unreachable, Asterisk complains as below:
> [May 14 07:20:37] WARNING[2082]: chan_sip.c:3781 __sip_xmit: sip_xmit of
0x2b61f424e7a0 (len 509) to 172.29.1.252:5060 returned -1: Destination address
required
> [May 14 07:20:38] WARNING[2082]: chan_sip.c:3781 __sip_xmit: sip_xmit of
0x2b61f458c940 (len 507) to 172.29.1.13:5060 returned -1: Destination address
required
> You also get the same when you try to ping it.
>
> Can you think of any way to resolve this. I tried a null route and that
didn't work.
>
> Regards
>
> Michael Knill
> Managing Director
>
> D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: michael.kn...@ipcsolutions.com.au
> W: ipcsolutions.com.au
>
> <image001.png>
> Smarter Business Communications
>
> _______________________________________________
> 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.
