On 14/06/17 22:25, Pippin1st via Openvpn-users wrote:
Then changed it twice to correct the order of
comp/frag/enc. and traffic NOT passing routing & iptables
from OpenVPN to tun and back.
Attached new diagram no.4
You could share the source document (eg. open-office draw)
and authoritative
Hello,
> When thinking about firewalls (and routing, for that matter), imagine
> OpenVPN as a black box sitting on a "second network card" connected
> to the linux machine.
> So there's iptables on the tun interface connecting "linux networking"
> and "openvpn black box" - packets towards openvpn
Hi,
On Wed, Jun 14, 2017 at 12:52:05PM +0200, David Sommerseth wrote:
> > for client-to-server traffic this looks correct ; client-to-client
> > traffic is another matter.
>
> Yes, good point. But that traffic never hits the tun/tap interface
> (unless the destination IP is a broadcast address;
Hi,
On Wed, Jun 14, 2017 at 02:50:28PM +0800, Antonio Quartulli wrote:
> Same I said would apply to packets coming in: when going from OpenVPN to tun0
> they would not be subject to routing/iptables.
Huh? Of course everything OpenVPN sends towards the host is seen
as "INPUT on tun0" by the firew
Hi,
On Tue, Jun 13, 2017 at 06:26:45PM -0400, Pippin1st via Openvpn-users wrote:
> > in your diagram, on the sending side, packets cross the
> > routing/iptables block twice before getting to OpenVPN:
> > 1) once while going from the app to the tun0 interface
> > 2) once while going from tun0 to O
On Thursday, 15 June 2017 12:42:53 AM AEST Selva Nair wrote:
> On Wed, Jun 14, 2017 at 9:32 AM, Steven Haigh wrote:
> > script-security 2
> > client-connect /etc/openvpn/yubikey-auth-tokens
> > auth-user-pass-verify /etc/openvpn/yubikey-auth-tokens via-file
> > client-cert-not-required
Hello,
> for client-to-server traffic this looks correct ;
> client-to-client traffic is another matter.
Yes, that i knew, --client-to-client is internal to OpenVPN.
I found this out when i was testing throughput in a client to
client setup on pfSense some time ago and then finding
the backrefere
On 14/06/17 12:25, Jan Just Keijser wrote:
> Hi Pippin,
>
> On 14/06/17 11:08, Pippin1st wrote:
>>
>> Hello,
>>
>> > Same I said would apply to packets coming in: when going from
>> > OpenVPN to tun0 they would not be subject to routing/iptables.
>> > Basically the idea is that OpenVPN and the tun
Hi Pippin,
On 14/06/17 11:08, Pippin1st wrote:
Hello,
> Same I said would apply to packets coming in: when going from
> OpenVPN to tun0 they would not be subject to routing/iptables.
> Basically the idea is that OpenVPN and the tun0 interface are
> directly attached, so I/O between the two is
Hello,
> Same I said would apply to packets coming in: when going from
> OpenVPN to tun0 they would not be subject to routing/iptables.
> Basically the idea is that OpenVPN and the tun0 interface are
> directly attached, so I/O between the two is direct.
Ok, modified attached diagram 3a, looking
10 matches
Mail list logo
