On 20/07/18 15:08, Paul Wouters wrote:
> Not too much to add but in the past I know that dummy interfaces could eat
> packets.
>
As a further follow up two things seemed to affect it.
One was the use of a 'dummy0' address. As the machine was on a VM I gave
it a 'Private' adaptor, which it then d
Not too much to add but in the past I know that dummy interfaces could eat
packets.
Paul
Sent from my phone
> On Jul 20, 2018, at 07:17, John Crisp wrote:
>
>> On 20/07/18 11:36, John Crisp wrote:
>>
>> I have reason to suspect that this may be the cause of my problems.
>>
>
> Hmmm - maybe
On 20/07/18 11:36, John Crisp wrote:
>
> I have reason to suspect that this may be the cause of my problems.
>
Hmmm - maybe not, because logically it is working because once I ping
from Libre -> Endian I can then ping from Endian -> Libre indicating
that the underlying networking is functioning.
Hello list,
i ugpraded the libreswan packages to 3.25 from the Libreswan repositories, as
there seemed to be a revamped _updown.netkey script in the package...
but it still fails with a wrong route target while trying to route it.
Is this supposed to fail? Is the routing command really supposed
On 20/07/18 09:51, Roberto Suárez Soto wrote:
> El 20/07/18 a las 01:43, John Crisp escribió:
>> However, once up I can only ping from the Libre end -> Endian.
>>
>> Once a ping has been sent, magically I can ping from the Endian back to
>> Libre
>
> I've seen this happen when the firewall at o
El 20/07/18 a las 01:43, John Crisp escribió:
> However, once up I can only ping from the Libre end -> Endian.
>
> Once a ping has been sent, magically I can ping from the Endian back to
> Libre
I've seen this happen when the firewall at one end ("Libre", in this
case) doesn't allow incoming I
