Yes the data goes over proto 50, but if NAT is detected the proto 50 is
encapsulated into a udp port 4500 packet
Sent from my phone
> On Aug 31, 2018, at 11:16, John Crisp wrote:
>
>> On 31/08/18 01:18, Paul Wouters wrote:
>> If there is no NAT you need to open protocol 50 ESP (not port,
On 31/08/18 01:18, Paul Wouters wrote:
> If there is no NAT you need to open protocol 50 ESP (not port, protocol)
>
Thanks Paul
OK.. I know I have that open on the server firewall but can't
remember seeing an option on the cloud providers one.
Is that because the negotiation is over
If there is no NAT you need to open protocol 50 ESP (not port, protocol)
Sent from my phone
> On Aug 30, 2018, at 18:59, John Crisp wrote:
>
>> On 28/08/18 21:56, Paul Wouters wrote:
>>
>>
>> could this be due to a RELATED iptables rules that only allows replies ?
>>
>
>
> Just found it.
On 28/08/18 21:56, Paul Wouters wrote:
>
> could this be due to a RELATED iptables rules that only allows replies ?
>
Just found it. I have a Firewall on the hosting at vultr where the two
VMs are. It has the following basic firewall rules and each server has
the same rule set applied (they
On Tue, 24 Jul 2018, John Crisp wrote:
Well, I swapped the dummy adaptor for a proper interface with the
virt_io driver just to be sure. However, ping was working even with the
dummy adaptor, so logically the networking was actually functioning.
You can ping happily from Libre -> Endian as
On 20/07/18 01:43, John Crisp wrote:
> I'm sure i have had this before, and I found a solution, but beating my
> head against a wall.
>
> I have a Endian <-> Libre 3.23 v2 ipsec tunnel
>
> It uses certificates and the tunnel comes up fine.
>
Well, I swapped the dummy adaptor for a proper
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
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 -
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
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
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
11 matches
Mail list logo
