Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Fernando F. <dig...@gm...> - 2018-10-14 14:58:55
|
Team, I added a astlinux repo on git hub so I can share some of the scrpits and dialplan I have done for my astlinux setup. I will also add some of the work and examples that you guys have share and I have adapted to my env. I will credit the correct source :) https://github.com/parallelsys/astlinux_scripts Thank You, Fernando Fuentes Texas Weather <http://www.txweather.org> |
|
From: Michael K. <mic...@ip...> - 2018-10-12 23:01:28
|
What is your voicemail.conf configuration? Regards Michael Knill From: "Fernando F." <dig...@gm...> Reply-To: AstLinux List <ast...@li...> Date: Saturday, 13 October 2018 at 9:43 am To: AstLinux List <ast...@li...> Subject: [Astlinux-users] help with email When a file trys to email it trys to set the recipient as the file... Not sure why: Oct 12 17:06:13 pbx mail.info<http://mail.info> msmtpqueue: (65) msmtp: recipient address /tmp/1539359810.82.wav not accepted by the server msmtp: server message: 550 5.1.1 </tmp/1539359810.82.wav>: Recipient address rejected: User unknown in local recipient table msmtp: could not send mail (account default from /etc/msmtprc) Oct 12 17:06:13 pbx mail.info<http://mail.info> msmtpqueue: Failure: Keeping mail queue /var/spool/mail/2018-10-12-12.16.54-2 msmtp/mail pair. Any ideas why is sending with an invalid recipient? Thank You, Fernando Fuentes Texas Weather<http://www.txweather.org> |
|
From: Fernando F. <dig...@gm...> - 2018-10-12 22:42:43
|
When a file trys to email it trys to set the recipient as the file... Not sure why: Oct 12 17:06:13 pbx mail.info msmtpqueue: (65) msmtp: recipient address /tmp/1539359810.82.wav not accepted by the server msmtp: server message: 550 5.1.1 </tmp/1539359810.82.wav>: Recipient address rejected: User unknown in local recipient table msmtp: could not send mail (account default from /etc/msmtprc) Oct 12 17:06:13 pbx mail.info msmtpqueue: Failure: Keeping mail queue /var/spool/mail/2018-10-12-12.16.54-2 msmtp/mail pair. Any ideas why is sending with an invalid recipient? Thank You, Fernando Fuentes Texas Weather <http://www.txweather.org> |
|
From: Michael K. <mic...@ip...> - 2018-10-12 20:40:25
|
Yes I thought about that but it certainly seems a bit messy ☹
Back to the drawing board I guess.
Regards
Michael Knill
On 13/10/18, 6:47 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Michael,
It appears the "DEFAULTROUTE=yes" is set to the pppoe.conf in our network script ... you don't want to be messing with that.
> Do I have any other options?
Make the PPPoE as the primary link and the other as the EXT2IF link, add some major routing to EXT2IF link.
Lonnie
> On Oct 12, 2018, at 2:25 PM, Michael Knill <mic...@ip...> wrote:
>
> Hmm that's a pity. The scenario is that I have a site where I believe I am having voice issues on the primary link (static IP), so I have installed another WAN service from a known working provider (PPPoE).
> So I want to send all traffic out the primary and send the voice traffic only out the backup. I was hoping to do this with WAN Failover with a secondary route configured and I really don't want to configure the modem into router mode and rely on it to do NAT.
>
> Do I have any other options?
>
> Regards
> Michael Knill
>
> On 13/10/18, 6:10 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
>> However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF.
>
> Yes, I can see that happening.
>
> Possibly we need to edit that WiKi section.
> https://doc.astlinux-project.org/userdoc:tt_wan_failover#pppoe_on_failover_interface
>
> For PPPoE on a failover (EXT2IF) interface, can you configure your PPPoE modem in "router" mode where the credentials are set in the modem ? Then the AstLinux configuration would be just like a 4G/LTE modem in "router" mode. In such a case you would set the "WAN Failover Configuration -> External Failover Interface:" as "Static IP" to match the subnet defined by the PPPoE modem in "router" mode.
>
> If the failover connection is over WireGuard the extra NAT of the PPPoE modem in "router" mode should not be an issue.
>
> Lonnie
>
>
>
>> On Oct 12, 2018, at 2:24 AM, Michael Knill <mic...@ip...> wrote:
>>
>> And the other question is what I set the WAN Failover Tab -> Connection Type: to? DHCP?
>>
>> Regards
>> Michael Knill
>>
>> From: Michael Knill <mic...@ip...>
>> Reply-To: AstLinux List <ast...@li...>
>> Date: Friday, 12 October 2018 at 6:20 pm
>> To: AstLinux List <ast...@li...>
>> Subject: [Astlinux-users] WAN Failover and PPPoE
>>
>> Hi Group
>>
>> As per the WAN Failover page, I tried to configure the backup interface for PPPoE as follows. Note primary WAN is static address on eth0:
>>
>> Network Tab -> Failover Interface -> eth2
>>
>> user.conf
>> PPPOEUSER="username"
>> PPPOEPASS="password"
>> PPPOEIF="eth2"
>> EXT2IF="ppp0"
>>
>> However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF.
>> WAN Failover would also not start with an error of ‘daemon.err wan-failover: ERROR Primary interface gateway not found, will restart on a network change.’
>>
>> Any ideas?
>>
>> Regards
>> Michael Knill
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2018-10-12 19:47:07
|
Michael, It appears the "DEFAULTROUTE=yes" is set to the pppoe.conf in our network script ... you don't want to be messing with that. > Do I have any other options? Make the PPPoE as the primary link and the other as the EXT2IF link, add some major routing to EXT2IF link. Lonnie > On Oct 12, 2018, at 2:25 PM, Michael Knill <mic...@ip...> wrote: > > Hmm that's a pity. The scenario is that I have a site where I believe I am having voice issues on the primary link (static IP), so I have installed another WAN service from a known working provider (PPPoE). > So I want to send all traffic out the primary and send the voice traffic only out the backup. I was hoping to do this with WAN Failover with a secondary route configured and I really don't want to configure the modem into router mode and rely on it to do NAT. > > Do I have any other options? > > Regards > Michael Knill > > On 13/10/18, 6:10 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > >> However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF. > > Yes, I can see that happening. > > Possibly we need to edit that WiKi section. > https://doc.astlinux-project.org/userdoc:tt_wan_failover#pppoe_on_failover_interface > > For PPPoE on a failover (EXT2IF) interface, can you configure your PPPoE modem in "router" mode where the credentials are set in the modem ? Then the AstLinux configuration would be just like a 4G/LTE modem in "router" mode. In such a case you would set the "WAN Failover Configuration -> External Failover Interface:" as "Static IP" to match the subnet defined by the PPPoE modem in "router" mode. > > If the failover connection is over WireGuard the extra NAT of the PPPoE modem in "router" mode should not be an issue. > > Lonnie > > > >> On Oct 12, 2018, at 2:24 AM, Michael Knill <mic...@ip...> wrote: >> >> And the other question is what I set the WAN Failover Tab -> Connection Type: to? DHCP? >> >> Regards >> Michael Knill >> >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Friday, 12 October 2018 at 6:20 pm >> To: AstLinux List <ast...@li...> >> Subject: [Astlinux-users] WAN Failover and PPPoE >> >> Hi Group >> >> As per the WAN Failover page, I tried to configure the backup interface for PPPoE as follows. Note primary WAN is static address on eth0: >> >> Network Tab -> Failover Interface -> eth2 >> >> user.conf >> PPPOEUSER="username" >> PPPOEPASS="password" >> PPPOEIF="eth2" >> EXT2IF="ppp0" >> >> However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF. >> WAN Failover would also not start with an error of ‘daemon.err wan-failover: ERROR Primary interface gateway not found, will restart on a network change.’ >> >> Any ideas? >> >> Regards >> Michael Knill >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2018-10-12 19:26:01
|
Hmm that's a pity. The scenario is that I have a site where I believe I am having voice issues on the primary link (static IP), so I have installed another WAN service from a known working provider (PPPoE).
So I want to send all traffic out the primary and send the voice traffic only out the backup. I was hoping to do this with WAN Failover with a secondary route configured and I really don't want to configure the modem into router mode and rely on it to do NAT.
Do I have any other options?
Regards
Michael Knill
On 13/10/18, 6:10 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
> However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF.
Yes, I can see that happening.
Possibly we need to edit that WiKi section.
https://doc.astlinux-project.org/userdoc:tt_wan_failover#pppoe_on_failover_interface
For PPPoE on a failover (EXT2IF) interface, can you configure your PPPoE modem in "router" mode where the credentials are set in the modem ? Then the AstLinux configuration would be just like a 4G/LTE modem in "router" mode. In such a case you would set the "WAN Failover Configuration -> External Failover Interface:" as "Static IP" to match the subnet defined by the PPPoE modem in "router" mode.
If the failover connection is over WireGuard the extra NAT of the PPPoE modem in "router" mode should not be an issue.
Lonnie
> On Oct 12, 2018, at 2:24 AM, Michael Knill <mic...@ip...> wrote:
>
> And the other question is what I set the WAN Failover Tab -> Connection Type: to? DHCP?
>
> Regards
> Michael Knill
>
> From: Michael Knill <mic...@ip...>
> Reply-To: AstLinux List <ast...@li...>
> Date: Friday, 12 October 2018 at 6:20 pm
> To: AstLinux List <ast...@li...>
> Subject: [Astlinux-users] WAN Failover and PPPoE
>
> Hi Group
>
> As per the WAN Failover page, I tried to configure the backup interface for PPPoE as follows. Note primary WAN is static address on eth0:
>
> Network Tab -> Failover Interface -> eth2
>
> user.conf
> PPPOEUSER="username"
> PPPOEPASS="password"
> PPPOEIF="eth2"
> EXT2IF="ppp0"
>
> However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF.
> WAN Failover would also not start with an error of ‘daemon.err wan-failover: ERROR Primary interface gateway not found, will restart on a network change.’
>
> Any ideas?
>
> Regards
> Michael Knill
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Michael K. <mic...@ip...> - 2018-10-12 19:17:11
|
Its even worse if you are using Local channels as you get one for each of the channel legs and then if you are using Direct Media, you get another when the bridging changes. I have got to the stage where I am considering writing my own simple CDR. Regards Michael Knill From: "Fernando F." <dig...@gm...> Reply-To: AstLinux List <ast...@li...> Date: Friday, 12 October 2018 at 11:58 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] CDR Log Well that sucks... lol It is what it is... :P Thank You, Fernando Fuentes Texas Weather<http://www.txweather.org> On Fri, Oct 12, 2018 at 7:18 AM Michael Keuter <li...@mk...<mailto:li...@mk...>> wrote: You cannot change that. That is because the handling oft CDRs was changed in Asterisk 12. Plesse read the changelog and update files for Asterisk for more info. For group- and parallel calls this looks not very nice :-(. Am 12. Oktober 2018 13:56:57 MESZ schrieb "Fernando F." <dig...@gm...<mailto:dig...@gm...>>: Team, How can I stop the CDR to log each channel is opening IE: Same call is been logged on the CDR log 3 times, one for each of the phones that ring in my house. Thank You, Fernando Fuentes Texas Weather<http://www.txweather.org> -- Sent via a tiny mobile device. _______________________________________________ Astlinux-users mailing list Ast...@li...<mailto:Ast...@li...> https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>. |
|
From: Lonnie A. <li...@lo...> - 2018-10-12 19:10:19
|
Hi Michael, > However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF. Yes, I can see that happening. Possibly we need to edit that WiKi section. https://doc.astlinux-project.org/userdoc:tt_wan_failover#pppoe_on_failover_interface For PPPoE on a failover (EXT2IF) interface, can you configure your PPPoE modem in "router" mode where the credentials are set in the modem ? Then the AstLinux configuration would be just like a 4G/LTE modem in "router" mode. In such a case you would set the "WAN Failover Configuration -> External Failover Interface:" as "Static IP" to match the subnet defined by the PPPoE modem in "router" mode. If the failover connection is over WireGuard the extra NAT of the PPPoE modem in "router" mode should not be an issue. Lonnie > On Oct 12, 2018, at 2:24 AM, Michael Knill <mic...@ip...> wrote: > > And the other question is what I set the WAN Failover Tab -> Connection Type: to? DHCP? > > Regards > Michael Knill > > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Friday, 12 October 2018 at 6:20 pm > To: AstLinux List <ast...@li...> > Subject: [Astlinux-users] WAN Failover and PPPoE > > Hi Group > > As per the WAN Failover page, I tried to configure the backup interface for PPPoE as follows. Note primary WAN is static address on eth0: > > Network Tab -> Failover Interface -> eth2 > > user.conf > PPPOEUSER="username" > PPPOEPASS="password" > PPPOEIF="eth2" > EXT2IF="ppp0" > > However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF. > WAN Failover would also not start with an error of ‘daemon.err wan-failover: ERROR Primary interface gateway not found, will restart on a network change.’ > > Any ideas? > > Regards > Michael Knill > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2018-10-12 13:49:42
|
I have found it extremely difficult to control this. It does seem to
affect inbound calls much more than outbound. You could try using NoCDR()
inside your dialplan, something like this during call hangup...
same = n,ExecIf($["${CDR(disposition)}"="FAILED"]?NoCDR())
same = n,ExecIf($["${CDR(disposition)}"="ANSWERED" &&
"${CDR(billsec)}"="0"]?NoCDR())
However I have found that this does not always work.
David
On Fri, Oct 12, 2018 at 8:58 AM Fernando F. <dig...@gm...> wrote:
> Well that sucks... lol
> It is what it is... :P
>
> Thank You,
>
> Fernando Fuentes
> Texas Weather <http://www.txweather.org>
>
>
>
> On Fri, Oct 12, 2018 at 7:18 AM Michael Keuter <li...@mk...>
> wrote:
>
>> You cannot change that.
>> That is because the handling oft CDRs was changed in Asterisk 12. Plesse
>> read the changelog and update files for Asterisk for more info.
>>
>> For group- and parallel calls this looks not very nice :-(.
>>
>> Am 12. Oktober 2018 13:56:57 MESZ schrieb "Fernando F." <
>> dig...@gm...>:
>>>
>>> Team,
>>>
>>> How can I stop the CDR to log each channel is opening IE: Same call is
>>> been logged on the CDR log 3 times, one for each of the phones that ring in
>>> my house.
>>>
>>> Thank You,
>>>
>>> Fernando Fuentes
>>> Texas Weather <http://www.txweather.org>
>>>
>>>
>> --
>> Sent via a tiny mobile device.
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>
>> Donations to support AstLinux are graciously accepted via PayPal to
>> pa...@kr....
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
|
|
From: Fernando F. <dig...@gm...> - 2018-10-12 12:58:36
|
Well that sucks... lol It is what it is... :P Thank You, Fernando Fuentes Texas Weather <http://www.txweather.org> On Fri, Oct 12, 2018 at 7:18 AM Michael Keuter <li...@mk...> wrote: > You cannot change that. > That is because the handling oft CDRs was changed in Asterisk 12. Plesse > read the changelog and update files for Asterisk for more info. > > For group- and parallel calls this looks not very nice :-(. > > Am 12. Oktober 2018 13:56:57 MESZ schrieb "Fernando F." < > dig...@gm...>: >> >> Team, >> >> How can I stop the CDR to log each channel is opening IE: Same call is >> been logged on the CDR log 3 times, one for each of the phones that ring in >> my house. >> >> Thank You, >> >> Fernando Fuentes >> Texas Weather <http://www.txweather.org> >> >> > -- > Sent via a tiny mobile device. > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Michael K. <li...@mk...> - 2018-10-12 12:17:52
|
You cannot change that. That is because the handling oft CDRs was changed in Asterisk 12. Plesse read the changelog and update files for Asterisk for more info. For group- and parallel calls this looks not very nice :-(. Am 12. Oktober 2018 13:56:57 MESZ schrieb "Fernando F." <dig...@gm...>: >Team, > >How can I stop the CDR to log each channel is opening IE: Same call is >been >logged on the CDR log 3 times, one for each of the phones that ring in >my >house. > >Thank You, > >Fernando Fuentes >Texas Weather <http://www.txweather.org> -- Sent via a tiny mobile device. |
|
From: Fernando F. <dig...@gm...> - 2018-10-12 11:57:16
|
Team, How can I stop the CDR to log each channel is opening IE: Same call is been logged on the CDR log 3 times, one for each of the phones that ring in my house. Thank You, Fernando Fuentes Texas Weather <http://www.txweather.org> |
|
From: Michael K. <mic...@ip...> - 2018-10-12 07:24:58
|
And the other question is what I set the WAN Failover Tab -> Connection Type: to? DHCP? Regards Michael Knill From: Michael Knill <mic...@ip...> Reply-To: AstLinux List <ast...@li...> Date: Friday, 12 October 2018 at 6:20 pm To: AstLinux List <ast...@li...> Subject: [Astlinux-users] WAN Failover and PPPoE Hi Group As per the WAN Failover page, I tried to configure the backup interface for PPPoE as follows. Note primary WAN is static address on eth0: Network Tab -> Failover Interface -> eth2 user.conf PPPOEUSER="username" PPPOEPASS="password" PPPOEIF="eth2" EXT2IF="ppp0" However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF. WAN Failover would also not start with an error of ‘daemon.err wan-failover: ERROR Primary interface gateway not found, will restart on a network change.’ Any ideas? Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2018-10-12 07:20:13
|
Hi Group As per the WAN Failover page, I tried to configure the backup interface for PPPoE as follows. Note primary WAN is static address on eth0: Network Tab -> Failover Interface -> eth2 user.conf PPPOEUSER="username" PPPOEPASS="password" PPPOEIF="eth2" EXT2IF="ppp0" However after doing this, it allocated ppp0 as the default route even though it was showing as EXT2IF and eth0 as EXTIF. WAN Failover would also not start with an error of ‘daemon.err wan-failover: ERROR Primary interface gateway not found, will restart on a network change.’ Any ideas? Regards Michael Knill |
|
From: Fernando F. <dig...@gm...> - 2018-10-12 00:27:37
|
Thanks Lonnie. On Thu, Oct 11, 2018, at 5:47 PM, Lonnie Abelbeck wrote: > fop2-2.31.17 is the latest version we have tagged. > > Upgrade Add-On FOP2 Package > https://doc.astlinux-project.org/userdoc:tt_asterisk-fop2-upgrade > > Lonnie > > > > > On Oct 11, 2018, at 1:04 PM, Fernando Fuentes <dig...@gm...> wrote: > > > > Team, > > > > Where di FOP2 go in the latest release? > > > > Sorry I been disconnected for a long time and just now I upgraded :D > > > > Thanks again! > > > > Regards, > > > > -- > > Fernando Fuentes > > ffu...@da... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... -- Fernando Fuentes ffu...@da... |
|
From: Lonnie A. <li...@lo...> - 2018-10-11 22:47:21
|
fop2-2.31.17 is the latest version we have tagged. Upgrade Add-On FOP2 Package https://doc.astlinux-project.org/userdoc:tt_asterisk-fop2-upgrade Lonnie > On Oct 11, 2018, at 1:04 PM, Fernando Fuentes <dig...@gm...> wrote: > > Team, > > Where di FOP2 go in the latest release? > > Sorry I been disconnected for a long time and just now I upgraded :D > > Thanks again! > > Regards, > > -- > Fernando Fuentes > ffu...@da... |
|
From: Fernando F. <dig...@gm...> - 2018-10-11 18:04:27
|
Team, Where di FOP2 go in the latest release? Sorry I been disconnected for a long time and just now I upgraded :D Thanks again! Regards, -- Fernando Fuentes ffu...@da... |
|
From: Fernando F. <dig...@gm...> - 2018-10-11 03:24:03
|
Thanks Lonnie. It actually is. But my actually was the way I migrated :) Now I am fighting why I get no audio over the damn kvm bridge. Thanks! -- Fernando Fuentes ffu...@tx... http://www.txweather.org -- Fernando Fuentes ffu...@da... On Wed, Oct 10, 2018, at 10:03 PM, lists wrote: > > I seem to recall the conversion was automatic, asterisk calls the > conversion program.> > Be sure not to mess with the symlinks AstLinux uses for astdb. > > Lonnie > > On Oct 10, 2018, at 9:58 PM, Fernando F. > <dig...@gm...> wrote:>> Found the tool to do it and all my DB has migrated. >> for anybody out there stuck like I was... use: >> >> astdb2sqlite3 path/to/astdb >> >> Thank You, >> >> Fernando Fuentes >> Texas Weather[1] >> >> _______________________________________________ >> Astlinux-users mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-users >> >> Donations to support AstLinux are graciously accepted via PayPal to >> pa...@kr....> > _________________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... Links: 1. http://www.txweather.org |
|
From: lists <li...@lo...> - 2018-10-11 03:03:50
|
I seem to recall the conversion was automatic, asterisk calls the conversion program. Be sure not to mess with the symlinks AstLinux uses for astdb. Lonnie > On Oct 10, 2018, at 9:58 PM, Fernando F. <dig...@gm...> wrote: > > Found the tool to do it and all my DB has migrated. > for anybody out there stuck like I was... use: > > astdb2sqlite3 path/to/astdb > > Thank You, > > Fernando Fuentes > Texas Weather > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: Fernando F. <dig...@gm...> - 2018-10-11 02:58:59
|
Found the tool to do it and all my DB has migrated. for anybody out there stuck like I was... use: astdb2sqlite3 path/to/astdb Thank You, Fernando Fuentes Texas Weather <http://www.txweather.org> |
|
From: Fernando F. <dig...@gm...> - 2018-10-11 02:01:50
|
Team, Its been a while :D I finally migrated from.... gulp..... 1.2 to ast 1.3 LOL. Yes I was still on asterisk 1.8 :P Is there a way to migrate my asterisk db to my new system? Thanks! -- Fernando Fuentes ffu...@da... |
|
From: David K. <da...@ke...> - 2018-10-10 03:12:00
|
HI Lonnie, Thanks. I'll take another look and test it. But my initial testing with that did not work and checking the documentation the way I understood it the fwmark is set on the outbound encrypted packets, not on packets going through the tunnel. But it would be simpler if that worked so worth another try. Thanks David On Tue, Oct 9, 2018 at 10:47 PM Lonnie Abelbeck <li...@lo...> wrote: > Hi David, > > Great stuff (as usual), though I'm thinking it may be simpler to not use > iptables, but something like: > -- > wg set "$INTERFACE" fwmark $table > -- > which marks the wireguard packets, and use that in "ip rule ..." logic, > just examples ... > > -- > ip $proto route add "$1" dev "$INTERFACE" table $table > ip $proto rule add not fwmark $table table $table > -- > > The above snippets are taken from Jason's wg-quick linux bash script ... > not easy to read but there are some gems in there: > https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick/linux.bash#n175 > > Jason uses the UDP port 51820 as the default "fwmark" and "table" value. > > Lonnie > > > > > On Oct 9, 2018, at 3:54 PM, David Kerr <Da...@Ke...> wrote: > > > > I have been wanting to get access to my PBX over my failover tunnel for > some time now but didn't know how to get it done (when failover was not > active -- works when astlinux is in failover mode). This thread prompted > me to try and get it setup, inspired by Lonnie pointing out fwmark. > Unfortunately what I thought would be a quick exercise took several hours > to get going. First a diagram... > > > > [RemoteDev] > > | public internet > > --------------------------------------- > > | eth0 | eth0 > > [failover] wg0 --------- wg0 [astlinux] > > 172.23.x.2 172.23.x.1 | eth1 192.168.x.1 > > -------------------------- > > | private LAN > > [internal system] 192.168.x.y > > > > > > failover could be astlinux or any linux that can act as a router/gateway > > failover is connected to public internet through its eth0 interface > > failover is connected to astlinux over wireguard. > > astlinux is connected to public internet through its eth0 interface > > astlinux is connected to failover over wireguard. > > astlinux is connected to a private LAN 192.168.x.0/24 > > > > Desired behavior is to allow [RemoteDev] to access [astlinux] (ssh or > https) or [internal system] connecting through either astlinux eth0 or > failover eth0. For this to work [failover] must NAT inbound ssh or https > over to [astlinux] or [internal system]. That part is easy enough and if > failover is active everything works fine as return traffic is routed back > over wireguard. But I want it to work even if failover is not active. > > > > First, the wireguard feature to set fwmark on the interface does nothing > to help. I tried. And the documentation ( > https://www.wireguard.com/netns/) states that this sets a mark on > outbound traffic to the wireguard UDP port. In other words the already > encrypted packets going out through eth0 port 51820. Actual packets > flowing in/out of the tunnel are not marked. But the principle of using > fwmark is sound, we just need another way of marking the packets. > > > > This is what worked for me... on the [astlinux] system... > > > > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark > > iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-xmark 0x4/0x4 > > iptables -t mangle -A PREROUTING -i wg0 -j CONNMARK --save-mark > > iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark > > ip route flush table 300 > > ip route add table 300 default dev wg0 via 172.23.x.2 > > ip rule add from 192.168.x.0/24 fwmark 0x4/0x4 table 300 priority 1000 > > > > Explanation... > > • We are setting a firewall mark on all inbound traffic from wg0. > fwmark is a 32-bit unsigned and can be treated as a value or a 32-bit > field. I have chosen to treat it as a 32-bit field and using mask only set > bit 2, this means I can use other bits for other purposes in > iptables/netfilter/route if I want. You can pick any bit or simply use a > integer value. Whatever you do needs to be consistent and be aware of any > other uses of fwmark in your firewall. > > • We must save this fwmark with the CONNMARK extension, so that we > can reattach the mark on related traffic. fwmarks do not attach to the IP > packet, they exist in the context of this system's kernel only. So > connection tracking is required to keep track of it. > > • PREROUTING chain is called for all inbound traffic from all > interfaces. So replies from LAN through eth1 will come here too and this > is where we need to restore the fwmark on returning packets using the > CONNMARK connection tracking. I do that first before setting mark on wg0 > traffic. > > • That works for traffic passing through [astlinux] to the > internal LAN. But for traffic to astlinux (e.g. the web interface) the > replies originate on the astlinux box itself and therefore do not pass > through PREROUTING. Therefore we must restore the fwmark on the OUTPUT > chain so that locally generated packets are tagged if required before we > get to routing. > https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES > > The above tags packets that need to be routed back through the wireguard > tunnel. Now have to mess with the routing tables to act on the marks. > > • Picking any free ip2route table (I randomly choose 300) delete > anything currently on that table. > > • Add a default route for that table to send all traffic through > the wireguard tunnel > > • Add an ip rule to select which packets should be routed through > this table based on the fwmark. Critical in this step is to only select > packets originating from the internal LAN -- ie, we are only interested in > outbound packets. if we don't do that then inbound packets from wg0 will > also get selected and we don't want that... because we did not duplicate > the content of the main routing table into this new table so there are no > routes to local destinations. > > The above rules can be set on POST_UP in the astlinux wireguard script. > And deleted in the POST_DOWN (or PRE_DOWN, should not matter). Though > beware that if you reload the firewall, without also restarting wireguard, > then the above would get deleted. > > > > What might this look like in wireguard.script POST_UP section.... > > > > # Setup routing table for traffic originating on $interface so that > > # we can set rules to route replies to that traffic over $interface > > # assume /etc/rc.conf read and interface="$2" > > if [ -n "$WAN_FAILOVER_SECONDARY_GW" ]; then > > echo "WireGuard: set iptables and ip route table > $WG0_TUNNEL_ROUTE_TABLE for $interface to reply to inbound traffic via > $WAN_FAILOVER_SECONDARY_GW" > > WG0_TUNNEL_ROUTE_TABLE="300" > > INTNET=$(netcalc $INTIP $INTNM | sed -n -r -e 's/^Network *: > *([0-9\.\/]+).*$/\1/p') > > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark > > iptables -t mangle -A PREROUTING -i $interface -j MARK --set-xmark > 0x4/0x4 > > iptables -t mangle -A PREROUTING -i $interface -j CONNMARK --save-mark > > iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark > > ip route flush table $WG0_TUNNEL_ROUTE_TABLE > > ip route add table $WG0_TUNNEL_ROUTE_TABLE default dev $interface via > $WAN_FAILOVER_SECONDARY_GW > > ip rule add from $INTNET fwmark 0x4/0x4 table $WG0_TUNNEL_ROUTE_TABLE > priority 1000 > > fi > > > > Don't forget to delete on POST_DOWN. > > > > IPv6 is left as homework exercise for the reader. > > > > Enjoy !! > > > > David > > > > On Sat, Oct 6, 2018 at 7:54 PM Lonnie Abelbeck < > li...@lo...> wrote: > > Yes, is all comes down to the routing at PBX2. > > > > Consider this ... the PC has IP 1.2.3.4, so the NAT forward will have a > SRC address of 1.2.3.4 when received by 172.29.253.2 on PBX2. If the > routing on PBX2 routes 1.2.3.4 back through the wireguard tunnel then it > will work as you want. On the other-hand if PBX2 routes 1.2.3.4 over it's > EXT interface then it will not work as you want. > > > > Probably the most elegant solution for routing on PBX2 is "policy > routing" using "ip rule ..." where traffic through the wireguard tunnel > could have a "fwmark" and add routing rules based on whether the packet > traversed the wireguard tunnel. I have only played with this ... all the > hooks are currently available using /mnt/kd/wireguard.script > > > https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#optional_action_script > > > > but if you are not familiar with policy-based routing in Linux, this > takes some research to get a handle on. > > > > Alternatively, if your public PC's are always off a know subnet, you > could add a static destination route on PBX2 to your PC's via the wireguard > tunnel. > > > > Lonnie > > > > > > > > > On Oct 6, 2018, at 6:11 PM, Michael Knill < > mic...@ip...> wrote: > > > > > > Sorry Lonnie I am a little confused. > > > The setup is as follows: > > > > > > PC -- [internet] -- PBX1 -- [WG VPN] -- PBX2 > > > > > > I can ping the private Wireguard PBX2 address (172.29.253.2) from PBX1 > (172.29.253.2) > > > So I want to NAT PBX1 EXTIF on a particular port to PBX2 WG IP > 172.29.253.2. > > > I have set up the NAT_FOREIGN_NETWORK for the entire private address > space. > > > > > > Thanks > > > > > > Regards > > > Michael Knill > > > > > > On 7/10/18, 12:01 am, "Lonnie Abelbeck" <li...@lo...> > wrote: > > > > > > > > > > > >> On Oct 5, 2018, at 10:29 PM, Michael Knill < > mic...@ip...> wrote: > > >> > > >> Hi Group > > >> > > >> Im wanting to set up a NAT rule from NAT EXT to a Wireguard VPN > endpoint. Is this possible? > > >> It does not seem to work with NAT EXT -> LAN. > > >> If not, is there a custom rule I can try? > > >> > > >> Basically I want to SSH to the VPN endpoint directly, via the transit > DR server. > > >> > > >> Thanks so much. > > > > > > Hi Michael, short answer is yes, but depending on the routing. > > > > > > Start with a diagram ... > > > > > > public_1 -- pbx1 [ wg_1_ip ] -- wireguard -- [ wg_2_ip ] pbx2 -- > public_2 > > > > > > > > > My understanding is you want to SSH to wg_1_ip using public_2 ? > Correct me if I mis-understood. > > > > > > Yes, a "NAT EXT -> LAN" on public_2 to wg_1_ip will work *only if* > the SSH return path at pbx1 goes through the wireguard vpn. > > > > > > I have personally tried this when pbx1 was on failover using > wireguard over LTE/4G, as such all pbx1 traffic was routed over wireguard, > as such a "NAT EXT -> LAN" on public_2 to wg_1_ip worked since the SSH > return packets passed over wireguard to pbx2. > > > > > > Tip -> Similar, but if a "NAT EXT -> LAN" on public_2 to a LAN IP > on pbx1 you would need to set NAT_FOREIGN_NETWORK on pbx2 of the pbx1 LAN > so it is NAT'ed on pbx2. > > > > > > Lonnie > > > > > > > > > > > > > > > _______________________________________________ > > > Astlinux-users mailing list > > > Ast...@li... > > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > > > > > > > > > _______________________________________________ > > > Astlinux-users mailing list > > > Ast...@li... > > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Lonnie A. <li...@lo...> - 2018-10-10 02:47:46
|
Hi David, Great stuff (as usual), though I'm thinking it may be simpler to not use iptables, but something like: -- wg set "$INTERFACE" fwmark $table -- which marks the wireguard packets, and use that in "ip rule ..." logic, just examples ... -- ip $proto route add "$1" dev "$INTERFACE" table $table ip $proto rule add not fwmark $table table $table -- The above snippets are taken from Jason's wg-quick linux bash script ... not easy to read but there are some gems in there: https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick/linux.bash#n175 Jason uses the UDP port 51820 as the default "fwmark" and "table" value. Lonnie > On Oct 9, 2018, at 3:54 PM, David Kerr <Da...@Ke...> wrote: > > I have been wanting to get access to my PBX over my failover tunnel for some time now but didn't know how to get it done (when failover was not active -- works when astlinux is in failover mode). This thread prompted me to try and get it setup, inspired by Lonnie pointing out fwmark. Unfortunately what I thought would be a quick exercise took several hours to get going. First a diagram... > > [RemoteDev] > | public internet > --------------------------------------- > | eth0 | eth0 > [failover] wg0 --------- wg0 [astlinux] > 172.23.x.2 172.23.x.1 | eth1 192.168.x.1 > -------------------------- > | private LAN > [internal system] 192.168.x.y > > > failover could be astlinux or any linux that can act as a router/gateway > failover is connected to public internet through its eth0 interface > failover is connected to astlinux over wireguard. > astlinux is connected to public internet through its eth0 interface > astlinux is connected to failover over wireguard. > astlinux is connected to a private LAN 192.168.x.0/24 > > Desired behavior is to allow [RemoteDev] to access [astlinux] (ssh or https) or [internal system] connecting through either astlinux eth0 or failover eth0. For this to work [failover] must NAT inbound ssh or https over to [astlinux] or [internal system]. That part is easy enough and if failover is active everything works fine as return traffic is routed back over wireguard. But I want it to work even if failover is not active. > > First, the wireguard feature to set fwmark on the interface does nothing to help. I tried. And the documentation (https://www.wireguard.com/netns/) states that this sets a mark on outbound traffic to the wireguard UDP port. In other words the already encrypted packets going out through eth0 port 51820. Actual packets flowing in/out of the tunnel are not marked. But the principle of using fwmark is sound, we just need another way of marking the packets. > > This is what worked for me... on the [astlinux] system... > > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark > iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-xmark 0x4/0x4 > iptables -t mangle -A PREROUTING -i wg0 -j CONNMARK --save-mark > iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark > ip route flush table 300 > ip route add table 300 default dev wg0 via 172.23.x.2 > ip rule add from 192.168.x.0/24 fwmark 0x4/0x4 table 300 priority 1000 > > Explanation... > • We are setting a firewall mark on all inbound traffic from wg0. fwmark is a 32-bit unsigned and can be treated as a value or a 32-bit field. I have chosen to treat it as a 32-bit field and using mask only set bit 2, this means I can use other bits for other purposes in iptables/netfilter/route if I want. You can pick any bit or simply use a integer value. Whatever you do needs to be consistent and be aware of any other uses of fwmark in your firewall. > • We must save this fwmark with the CONNMARK extension, so that we can reattach the mark on related traffic. fwmarks do not attach to the IP packet, they exist in the context of this system's kernel only. So connection tracking is required to keep track of it. > • PREROUTING chain is called for all inbound traffic from all interfaces. So replies from LAN through eth1 will come here too and this is where we need to restore the fwmark on returning packets using the CONNMARK connection tracking. I do that first before setting mark on wg0 traffic. > • That works for traffic passing through [astlinux] to the internal LAN. But for traffic to astlinux (e.g. the web interface) the replies originate on the astlinux box itself and therefore do not pass through PREROUTING. Therefore we must restore the fwmark on the OUTPUT chain so that locally generated packets are tagged if required before we get to routing. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES > The above tags packets that need to be routed back through the wireguard tunnel. Now have to mess with the routing tables to act on the marks. > • Picking any free ip2route table (I randomly choose 300) delete anything currently on that table. > • Add a default route for that table to send all traffic through the wireguard tunnel > • Add an ip rule to select which packets should be routed through this table based on the fwmark. Critical in this step is to only select packets originating from the internal LAN -- ie, we are only interested in outbound packets. if we don't do that then inbound packets from wg0 will also get selected and we don't want that... because we did not duplicate the content of the main routing table into this new table so there are no routes to local destinations. > The above rules can be set on POST_UP in the astlinux wireguard script. And deleted in the POST_DOWN (or PRE_DOWN, should not matter). Though beware that if you reload the firewall, without also restarting wireguard, then the above would get deleted. > > What might this look like in wireguard.script POST_UP section.... > > # Setup routing table for traffic originating on $interface so that > # we can set rules to route replies to that traffic over $interface > # assume /etc/rc.conf read and interface="$2" > if [ -n "$WAN_FAILOVER_SECONDARY_GW" ]; then > echo "WireGuard: set iptables and ip route table $WG0_TUNNEL_ROUTE_TABLE for $interface to reply to inbound traffic via $WAN_FAILOVER_SECONDARY_GW" > WG0_TUNNEL_ROUTE_TABLE="300" > INTNET=$(netcalc $INTIP $INTNM | sed -n -r -e 's/^Network *: *([0-9\.\/]+).*$/\1/p') > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark > iptables -t mangle -A PREROUTING -i $interface -j MARK --set-xmark 0x4/0x4 > iptables -t mangle -A PREROUTING -i $interface -j CONNMARK --save-mark > iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark > ip route flush table $WG0_TUNNEL_ROUTE_TABLE > ip route add table $WG0_TUNNEL_ROUTE_TABLE default dev $interface via $WAN_FAILOVER_SECONDARY_GW > ip rule add from $INTNET fwmark 0x4/0x4 table $WG0_TUNNEL_ROUTE_TABLE priority 1000 > fi > > Don't forget to delete on POST_DOWN. > > IPv6 is left as homework exercise for the reader. > > Enjoy !! > > David > > On Sat, Oct 6, 2018 at 7:54 PM Lonnie Abelbeck <li...@lo...> wrote: > Yes, is all comes down to the routing at PBX2. > > Consider this ... the PC has IP 1.2.3.4, so the NAT forward will have a SRC address of 1.2.3.4 when received by 172.29.253.2 on PBX2. If the routing on PBX2 routes 1.2.3.4 back through the wireguard tunnel then it will work as you want. On the other-hand if PBX2 routes 1.2.3.4 over it's EXT interface then it will not work as you want. > > Probably the most elegant solution for routing on PBX2 is "policy routing" using "ip rule ..." where traffic through the wireguard tunnel could have a "fwmark" and add routing rules based on whether the packet traversed the wireguard tunnel. I have only played with this ... all the hooks are currently available using /mnt/kd/wireguard.script > https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#optional_action_script > > but if you are not familiar with policy-based routing in Linux, this takes some research to get a handle on. > > Alternatively, if your public PC's are always off a know subnet, you could add a static destination route on PBX2 to your PC's via the wireguard tunnel. > > Lonnie > > > > > On Oct 6, 2018, at 6:11 PM, Michael Knill <mic...@ip...> wrote: > > > > Sorry Lonnie I am a little confused. > > The setup is as follows: > > > > PC -- [internet] -- PBX1 -- [WG VPN] -- PBX2 > > > > I can ping the private Wireguard PBX2 address (172.29.253.2) from PBX1 (172.29.253.2) > > So I want to NAT PBX1 EXTIF on a particular port to PBX2 WG IP 172.29.253.2. > > I have set up the NAT_FOREIGN_NETWORK for the entire private address space. > > > > Thanks > > > > Regards > > Michael Knill > > > > On 7/10/18, 12:01 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > > > > > > >> On Oct 5, 2018, at 10:29 PM, Michael Knill <mic...@ip...> wrote: > >> > >> Hi Group > >> > >> Im wanting to set up a NAT rule from NAT EXT to a Wireguard VPN endpoint. Is this possible? > >> It does not seem to work with NAT EXT -> LAN. > >> If not, is there a custom rule I can try? > >> > >> Basically I want to SSH to the VPN endpoint directly, via the transit DR server. > >> > >> Thanks so much. > > > > Hi Michael, short answer is yes, but depending on the routing. > > > > Start with a diagram ... > > > > public_1 -- pbx1 [ wg_1_ip ] -- wireguard -- [ wg_2_ip ] pbx2 -- public_2 > > > > > > My understanding is you want to SSH to wg_1_ip using public_2 ? Correct me if I mis-understood. > > > > Yes, a "NAT EXT -> LAN" on public_2 to wg_1_ip will work *only if* the SSH return path at pbx1 goes through the wireguard vpn. > > > > I have personally tried this when pbx1 was on failover using wireguard over LTE/4G, as such all pbx1 traffic was routed over wireguard, as such a "NAT EXT -> LAN" on public_2 to wg_1_ip worked since the SSH return packets passed over wireguard to pbx2. > > > > Tip -> Similar, but if a "NAT EXT -> LAN" on public_2 to a LAN IP on pbx1 you would need to set NAT_FOREIGN_NETWORK on pbx2 of the pbx1 LAN so it is NAT'ed on pbx2. > > > > Lonnie > > > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... |
|
From: David K. <da...@ke...> - 2018-10-09 22:32:09
|
Hi Michael, For the purpose of this exercise I made no assumptions on how the wireguard tunnel is routed as that is irrelevant and the beauty of using a wireguard tunnel. That said on my personal system I have eth0 connected to comcast and eth2 connected to 4G/LTE and the wireguard tunnel can go over either. To avoid driving traffic over 4G/LTE I actually only move the wireguard tunnel to eth2 during WAN failover. That involves its own set of routing table instructions. David. On Tue, Oct 9, 2018 at 5:44 PM Michael Knill < mic...@ip...> wrote: > Hi David > > > > Just confirming, is failover connected to eth1, not eth0 as you have noted > below? If so, are you forcing Wireguard out eth1? > > > > I set up all my systems so that the Wiregaurd VPN goes out the active WAN > connection. Handy for failover fall back in that it does not disconnect any > calls and it does not use any 4G (little that it may be). > > In your case, would this not mean that it would work on either WAN > connection? > > > > Regards > > Michael Knill > > > > *From: *David Kerr <da...@ke...> > *Reply-To: *AstLinux List <ast...@li...> > *Date: *Wednesday, 10 October 2018 at 8:28 am > *To: *AstLinux List <ast...@li...> > *Subject: *Re: [Astlinux-users] Access to VPN endpoint from external > > > > I have been wanting to get access to my PBX over my failover tunnel for > some time now but didn't know how to get it done (when failover was not > active -- works when astlinux is in failover mode). This thread prompted > me to try and get it setup, inspired by Lonnie pointing out fwmark. > Unfortunately what I thought would be a quick exercise took several hours > to get going. First a diagram... > > > > [RemoteDev] > > | public internet > > --------------------------------------- > > | eth0 | eth0 > > [failover] wg0 --------- wg0 [astlinux] > > 172.23.x.2 172.23.x.1 | eth1 192.168.x.1 > > -------------------------- > > | private LAN > > [internal system] 192.168.x.y > > > > > > failover could be astlinux or any linux that can act as a router/gateway > > failover is connected to public internet through its eth0 interface > > failover is connected to astlinux over wireguard. > > astlinux is connected to public internet through its eth0 interface > > astlinux is connected to failover over wireguard. > > astlinux is connected to a private LAN 192.168.x.0/24 > > > > Desired behavior is to allow [RemoteDev] to access [astlinux] (ssh or > https) or [internal system] connecting through either astlinux eth0 or > failover eth0. For this to work [failover] must NAT inbound ssh or https > over to [astlinux] or [internal system]. That part is easy enough and if > failover is active everything works fine as return traffic is routed back > over wireguard. But I want it to work even if failover is not active. > > > > First, the wireguard feature to set fwmark on the interface does nothing > to help. I tried. And the documentation ( > https://www.wireguard.com/netns/) states that this sets a mark on > outbound traffic to the wireguard UDP port. In other words the already > encrypted packets going out through eth0 port 51820. Actual packets > flowing in/out of the tunnel are not marked. But the principle of using > fwmark is sound, we just need another way of marking the packets. > > > > This is what worked for me... on the [astlinux] system... > > > > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark > > iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-xmark 0x4/0x4 > > iptables -t mangle -A PREROUTING -i wg0 -j CONNMARK --save-mark > > iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark > > ip route flush table 300 > > ip route add table 300 default dev wg0 via 172.23.x.2 > > ip rule add from 192.168.x.0/24 fwmark 0x4/0x4 table 300 priority 1000 > > > > Explanation... > > - We are setting a firewall mark on all inbound traffic from wg0. > fwmark is a 32-bit unsigned and can be treated as a value or a 32-bit > field. I have chosen to treat it as a 32-bit field and using mask only set > bit 2, this means I can use other bits for other purposes in > iptables/netfilter/route if I want. You can pick any bit or simply use a > integer value. Whatever you do needs to be consistent and be aware of any > other uses of fwmark in your firewall. > - We must save this fwmark with the CONNMARK extension, so that we can > reattach the mark on related traffic. fwmarks do not attach to the IP > packet, they exist in the context of this system's kernel only. So > connection tracking is required to keep track of it. > - PREROUTING chain is called for all inbound traffic from all > interfaces. So replies from LAN through eth1 will come here too and this > is where we need to restore the fwmark on returning packets using the > CONNMARK connection tracking. I do that first before setting mark on wg0 > traffic. > - That works for traffic passing through [astlinux] to the internal > LAN. But for traffic to astlinux (e.g. the web interface) the replies > originate on the astlinux box itself and therefore do not pass through > PREROUTING. Therefore we must restore the fwmark on the OUTPUT chain so > that locally generated packets are tagged if required before we get to > routing. > https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES > > The above tags packets that need to be routed back through the wireguard > tunnel. Now have to mess with the routing tables to act on the marks. > > - Picking any free ip2route table (I randomly choose 300) delete > anything currently on that table. > - Add a default route for that table to send all traffic through the > wireguard tunnel > - Add an ip rule to select which packets should be routed through this > table based on the fwmark. Critical in this step is to only select packets > originating from the internal LAN -- ie, we are only interested in outbound > packets. if we don't do that then inbound packets from wg0 will also get > selected and we don't want that... because we did not duplicate the content > of the main routing table into this new table so there are no routes to > local destinations. > > The above rules can be set on POST_UP in the astlinux wireguard script. > And deleted in the POST_DOWN (or PRE_DOWN, should not matter). Though > beware that if you reload the firewall, without also restarting wireguard, > then the above would get deleted. > > > > What might this look like in wireguard.script POST_UP section.... > > > > # Setup routing table for traffic originating on $interface so that > > # we can set rules to route replies to that traffic over $interface > > # assume /etc/rc.conf read and interface="$2" > > if [ -n "$WAN_FAILOVER_SECONDARY_GW" ]; then > > echo "WireGuard: set iptables and ip route table $WG0_TUNNEL_ROUTE_TABLE > for $interface to reply to inbound traffic via $WAN_FAILOVER_SECONDARY_GW" > > WG0_TUNNEL_ROUTE_TABLE="300" > > INTNET=$(netcalc $INTIP $INTNM | sed -n -r -e 's/^Network *: > *([0-9\.\/]+).*$/\1/p') > > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark > > iptables -t mangle -A PREROUTING -i $interface -j MARK --set-xmark > 0x4/0x4 > > iptables -t mangle -A PREROUTING -i $interface -j CONNMARK --save-mark > > iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark > > ip route flush table $WG0_TUNNEL_ROUTE_TABLE > > ip route add table $WG0_TUNNEL_ROUTE_TABLE default dev $interface via > $WAN_FAILOVER_SECONDARY_GW > > ip rule add from $INTNET fwmark 0x4/0x4 table $WG0_TUNNEL_ROUTE_TABLE > priority 1000 > > fi > > > > Don't forget to delete on POST_DOWN. > > > > IPv6 is left as homework exercise for the reader. > > > > Enjoy !! > > > > David > > > > On Sat, Oct 6, 2018 at 7:54 PM Lonnie Abelbeck <li...@lo...> > wrote: > > Yes, is all comes down to the routing at PBX2. > > Consider this ... the PC has IP 1.2.3.4, so the NAT forward will have a > SRC address of 1.2.3.4 when received by 172.29.253.2 on PBX2. If the > routing on PBX2 routes 1.2.3.4 back through the wireguard tunnel then it > will work as you want. On the other-hand if PBX2 routes 1.2.3.4 over it's > EXT interface then it will not work as you want. > > Probably the most elegant solution for routing on PBX2 is "policy routing" > using "ip rule ..." where traffic through the wireguard tunnel could have a > "fwmark" and add routing rules based on whether the packet traversed the > wireguard tunnel. I have only played with this ... all the hooks are > currently available using /mnt/kd/wireguard.script > > https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#optional_action_script > > but if you are not familiar with policy-based routing in Linux, this takes > some research to get a handle on. > > Alternatively, if your public PC's are always off a know subnet, you could > add a static destination route on PBX2 to your PC's via the wireguard > tunnel. > > Lonnie > > > > > On Oct 6, 2018, at 6:11 PM, Michael Knill < > mic...@ip...> wrote: > > > > Sorry Lonnie I am a little confused. > > The setup is as follows: > > > > PC -- [internet] -- PBX1 -- [WG VPN] -- PBX2 > > > > I can ping the private Wireguard PBX2 address (172.29.253.2) from PBX1 > (172.29.253.2) > > So I want to NAT PBX1 EXTIF on a particular port to PBX2 WG IP > 172.29.253.2. > > I have set up the NAT_FOREIGN_NETWORK for the entire private address > space. > > > > Thanks > > > > Regards > > Michael Knill > > > > On 7/10/18, 12:01 am, "Lonnie Abelbeck" <li...@lo...> > wrote: > > > > > > > >> On Oct 5, 2018, at 10:29 PM, Michael Knill < > mic...@ip...> wrote: > >> > >> Hi Group > >> > >> Im wanting to set up a NAT rule from NAT EXT to a Wireguard VPN > endpoint. Is this possible? > >> It does not seem to work with NAT EXT -> LAN. > >> If not, is there a custom rule I can try? > >> > >> Basically I want to SSH to the VPN endpoint directly, via the transit > DR server. > >> > >> Thanks so much. > > > > Hi Michael, short answer is yes, but depending on the routing. > > > > Start with a diagram ... > > > > public_1 -- pbx1 [ wg_1_ip ] -- wireguard -- [ wg_2_ip ] pbx2 -- > public_2 > > > > > > My understanding is you want to SSH to wg_1_ip using public_2 ? > Correct me if I mis-understood. > > > > Yes, a "NAT EXT -> LAN" on public_2 to wg_1_ip will work *only if* > the SSH return path at pbx1 goes through the wireguard vpn. > > > > I have personally tried this when pbx1 was on failover using > wireguard over LTE/4G, as such all pbx1 traffic was routed over wireguard, > as such a "NAT EXT -> LAN" on public_2 to wg_1_ip worked since the SSH > return packets passed over wireguard to pbx2. > > > > Tip -> Similar, but if a "NAT EXT -> LAN" on public_2 to a LAN IP on > pbx1 you would need to set NAT_FOREIGN_NETWORK on pbx2 of the pbx1 LAN so > it is NAT'ed on pbx2. > > > > Lonnie > > > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... |
|
From: Michael K. <mic...@ip...> - 2018-10-09 21:44:48
|
Hi David
Just confirming, is failover connected to eth1, not eth0 as you have noted below? If so, are you forcing Wireguard out eth1?
I set up all my systems so that the Wiregaurd VPN goes out the active WAN connection. Handy for failover fall back in that it does not disconnect any calls and it does not use any 4G (little that it may be).
In your case, would this not mean that it would work on either WAN connection?
Regards
Michael Knill
From: David Kerr <da...@ke...>
Reply-To: AstLinux List <ast...@li...>
Date: Wednesday, 10 October 2018 at 8:28 am
To: AstLinux List <ast...@li...>
Subject: Re: [Astlinux-users] Access to VPN endpoint from external
I have been wanting to get access to my PBX over my failover tunnel for some time now but didn't know how to get it done (when failover was not active -- works when astlinux is in failover mode). This thread prompted me to try and get it setup, inspired by Lonnie pointing out fwmark. Unfortunately what I thought would be a quick exercise took several hours to get going. First a diagram...
[RemoteDev]
| public internet
---------------------------------------
| eth0 | eth0
[failover] wg0 --------- wg0 [astlinux]
172.23.x.2 172.23.x.1 | eth1 192.168.x.1
--------------------------
| private LAN
[internal system] 192.168.x.y
failover could be astlinux or any linux that can act as a router/gateway
failover is connected to public internet through its eth0 interface
failover is connected to astlinux over wireguard.
astlinux is connected to public internet through its eth0 interface
astlinux is connected to failover over wireguard.
astlinux is connected to a private LAN 192.168.x.0/24
Desired behavior is to allow [RemoteDev] to access [astlinux] (ssh or https) or [internal system] connecting through either astlinux eth0 or failover eth0. For this to work [failover] must NAT inbound ssh or https over to [astlinux] or [internal system]. That part is easy enough and if failover is active everything works fine as return traffic is routed back over wireguard. But I want it to work even if failover is not active.
First, the wireguard feature to set fwmark on the interface does nothing to help. I tried. And the documentation (https://www.wireguard.com/netns/) states that this sets a mark on outbound traffic to the wireguard UDP port. In other words the already encrypted packets going out through eth0 port 51820. Actual packets flowing in/out of the tunnel are not marked. But the principle of using fwmark is sound, we just need another way of marking the packets.
This is what worked for me... on the [astlinux] system...
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-xmark 0x4/0x4
iptables -t mangle -A PREROUTING -i wg0 -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
ip route flush table 300
ip route add table 300 default dev wg0 via 172.23.x.2
ip rule add from 192.168.x.0/24 fwmark 0x4/0x4 table 300 priority 1000
Explanation...
* We are setting a firewall mark on all inbound traffic from wg0. fwmark is a 32-bit unsigned and can be treated as a value or a 32-bit field. I have chosen to treat it as a 32-bit field and using mask only set bit 2, this means I can use other bits for other purposes in iptables/netfilter/route if I want. You can pick any bit or simply use a integer value. Whatever you do needs to be consistent and be aware of any other uses of fwmark in your firewall.
* We must save this fwmark with the CONNMARK extension, so that we can reattach the mark on related traffic. fwmarks do not attach to the IP packet, they exist in the context of this system's kernel only. So connection tracking is required to keep track of it.
* PREROUTING chain is called for all inbound traffic from all interfaces. So replies from LAN through eth1 will come here too and this is where we need to restore the fwmark on returning packets using the CONNMARK connection tracking. I do that first before setting mark on wg0 traffic.
* That works for traffic passing through [astlinux] to the internal LAN. But for traffic to astlinux (e.g. the web interface) the replies originate on the astlinux box itself and therefore do not pass through PREROUTING. Therefore we must restore the fwmark on the OUTPUT chain so that locally generated packets are tagged if required before we get to routing. https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES
The above tags packets that need to be routed back through the wireguard tunnel. Now have to mess with the routing tables to act on the marks.
* Picking any free ip2route table (I randomly choose 300) delete anything currently on that table.
* Add a default route for that table to send all traffic through the wireguard tunnel
* Add an ip rule to select which packets should be routed through this table based on the fwmark. Critical in this step is to only select packets originating from the internal LAN -- ie, we are only interested in outbound packets. if we don't do that then inbound packets from wg0 will also get selected and we don't want that... because we did not duplicate the content of the main routing table into this new table so there are no routes to local destinations.
The above rules can be set on POST_UP in the astlinux wireguard script. And deleted in the POST_DOWN (or PRE_DOWN, should not matter). Though beware that if you reload the firewall, without also restarting wireguard, then the above would get deleted.
What might this look like in wireguard.script POST_UP section....
# Setup routing table for traffic originating on $interface so that
# we can set rules to route replies to that traffic over $interface
# assume /etc/rc.conf read and interface="$2"
if [ -n "$WAN_FAILOVER_SECONDARY_GW" ]; then
echo "WireGuard: set iptables and ip route table $WG0_TUNNEL_ROUTE_TABLE for $interface to reply to inbound traffic via $WAN_FAILOVER_SECONDARY_GW"
WG0_TUNNEL_ROUTE_TABLE="300"
INTNET=$(netcalc $INTIP $INTNM | sed -n -r -e 's/^Network *: *([0-9\.\/]+).*$/\1/p')
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i $interface -j MARK --set-xmark 0x4/0x4
iptables -t mangle -A PREROUTING -i $interface -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
ip route flush table $WG0_TUNNEL_ROUTE_TABLE
ip route add table $WG0_TUNNEL_ROUTE_TABLE default dev $interface via $WAN_FAILOVER_SECONDARY_GW
ip rule add from $INTNET fwmark 0x4/0x4 table $WG0_TUNNEL_ROUTE_TABLE priority 1000
fi
Don't forget to delete on POST_DOWN.
IPv6 is left as homework exercise for the reader.
Enjoy !!
David
On Sat, Oct 6, 2018 at 7:54 PM Lonnie Abelbeck <li...@lo...<mailto:li...@lo...>> wrote:
Yes, is all comes down to the routing at PBX2.
Consider this ... the PC has IP 1.2.3.4, so the NAT forward will have a SRC address of 1.2.3.4 when received by 172.29.253.2 on PBX2. If the routing on PBX2 routes 1.2.3.4 back through the wireguard tunnel then it will work as you want. On the other-hand if PBX2 routes 1.2.3.4 over it's EXT interface then it will not work as you want.
Probably the most elegant solution for routing on PBX2 is "policy routing" using "ip rule ..." where traffic through the wireguard tunnel could have a "fwmark" and add routing rules based on whether the packet traversed the wireguard tunnel. I have only played with this ... all the hooks are currently available using /mnt/kd/wireguard.script
https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn#optional_action_script
but if you are not familiar with policy-based routing in Linux, this takes some research to get a handle on.
Alternatively, if your public PC's are always off a know subnet, you could add a static destination route on PBX2 to your PC's via the wireguard tunnel.
Lonnie
> On Oct 6, 2018, at 6:11 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>
> Sorry Lonnie I am a little confused.
> The setup is as follows:
>
> PC -- [internet] -- PBX1 -- [WG VPN] -- PBX2
>
> I can ping the private Wireguard PBX2 address (172.29.253.2) from PBX1 (172.29.253.2)
> So I want to NAT PBX1 EXTIF on a particular port to PBX2 WG IP 172.29.253.2.
> I have set up the NAT_FOREIGN_NETWORK for the entire private address space.
>
> Thanks
>
> Regards
> Michael Knill
>
> On 7/10/18, 12:01 am, "Lonnie Abelbeck" <li...@lo...<mailto:li...@lo...>> wrote:
>
>
>
>> On Oct 5, 2018, at 10:29 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>>
>> Hi Group
>>
>> Im wanting to set up a NAT rule from NAT EXT to a Wireguard VPN endpoint. Is this possible?
>> It does not seem to work with NAT EXT -> LAN.
>> If not, is there a custom rule I can try?
>>
>> Basically I want to SSH to the VPN endpoint directly, via the transit DR server.
>>
>> Thanks so much.
>
> Hi Michael, short answer is yes, but depending on the routing.
>
> Start with a diagram ...
>
> public_1 -- pbx1 [ wg_1_ip ] -- wireguard -- [ wg_2_ip ] pbx2 -- public_2
>
>
> My understanding is you want to SSH to wg_1_ip using public_2 ? Correct me if I mis-understood.
>
> Yes, a "NAT EXT -> LAN" on public_2 to wg_1_ip will work *only if* the SSH return path at pbx1 goes through the wireguard vpn.
>
> I have personally tried this when pbx1 was on failover using wireguard over LTE/4G, as such all pbx1 traffic was routed over wireguard, as such a "NAT EXT -> LAN" on public_2 to wg_1_ip worked since the SSH return packets passed over wireguard to pbx2.
>
> Tip -> Similar, but if a "NAT EXT -> LAN" on public_2 to a LAN IP on pbx1 you would need to set NAT_FOREIGN_NETWORK on pbx2 of the pbx1 LAN so it is NAT'ed on pbx2.
>
> Lonnie
>
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...<mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...<mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
_______________________________________________
Astlinux-users mailing list
Ast...@li...<mailto:Ast...@li...>
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
|
63 messages has been excluded from this view by a project administrator.
