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, proto
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 500/450
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. I
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 ha
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 soon
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 interface
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.
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
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.
However, once up I can only ping from the Libre end -> Endian.
Once a ping has been sent, magically I ca
12 matches
Mail list logo