On 4/12/18 10:26 am, Andrew Udvare wrote:
> On 03/12/2018 09:49, Michael Orlitzky wrote:
>> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>> iptables on server:
>>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>>> NEW -j ACCEPT
>>>
>> Is that only forwarding packets for new (i
On 4/12/18 10:26 am, Andrew Udvare wrote:
> On 03/12/2018 09:49, Michael Orlitzky wrote:
>> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>> iptables on server:
>>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>>> NEW -j ACCEPT
>>>
>> Is that only forwarding packets for new (i
On 03/12/2018 09:49, Michael Orlitzky wrote:
> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>
>> iptables on server:
>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>> NEW -j ACCEPT
>>
>
> Is that only forwarding packets for new (i.e. not existing) connections?
Not sure but
On 12/3/18 5:55 AM, Andrew Udvare wrote:
iptables on server:
-A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate NEW -j
ACCEPT
Is that only forwarding packets for new (i.e. not existing) connections?
Ours looks like,
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED
Very confused here, but I feel like I'm missing a route on either the client
side or the server side. Or it is a firewall rule but that doesn't seem likely.
My OpenVPN server/client config is almost identical to that on the wiki page:
https://wiki.gentoo.org/wiki/OpenVPN#Configuration
After con
5 matches
Mail list logo