Hello,
> You could share the source document (eg. open-office draw)
> and authoritative improvements could be made .. ;)
See attached DIA file.
DIA can be found here:
http://dia-installer.de/
It`s a layerd dia, objects are grouped:
View -> Show Layers
Objects -> Group/Ungroup
Should someone add
Hello,
So there is agreement now, thanks.
Attachment 5a final.
I will send the source file in the next message as the list
does not allow over 40kb message body.
Thanks,
Pippin--
Check out the vibrant tech community on on
Hi,
On Wed, Jun 14, 2017 at 05:08:57AM -0400, Pippin1st via Openvpn-users wrote:
> Ok, modified attached diagram 3a, looking at SERVER side,
Talked on IRC with Antonio, and 3a is actually more precise than 4a.
4a is good, 3a ist better (since there really is no "box" between
openvpn and the "tu
Hi,
On Wed, Jun 14, 2017 at 05:25:37PM -0400, Pippin1st wrote:
> That`s how the picture looked in my mind the first time and made the
> first diagram. Then changed it twice to correct the order of
> comp/frag/enc. and traffic NOT passing routing & iptables
> from OpenVPN to tun and back.
>
> Atta
On Wed, Jun 14, 2017 at 05:25:37PM -0400, Pippin1st via Openvpn-users wrote:
> 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
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
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
On Tue, Jun 13, 2017 at 06:26:45PM -0400, Pippin1st 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 OpenVPN
>
> > What you
> 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 OpenVPN
> What you are saying above is correct and it is about point 1).
> My argument was
> On 14 Jun 2017, at 02:07, Pippin1st wrote:
>
> >> One thing I would like to highlight is that it seems that packets going
> >> from the App to tun0 are then re-entering routing/iptables before reaching
> >> OpenVPN.
> >> This should not happen because packets entering tun0 are then directly
>
Hello,
Thanks to all for taking the time to educate.
> At least the order of encryption/decryption and
> compression/decompression makes no sense.
> Compression should be always done before encryption!
>> it"s actually even weirder when you read the sources:
>> 1) compress
>> 2) fragment
>> 3) e
Hi Antonio,
On 13/06/17 16:58, Antonio Quartulli wrote:
On 13 Jun 2017, at 18:49, Pippin1st via Openvpn-users
wrote:
Hello,
I`m trying to draw a picture where one can see how packets are flowing in a
routed tun setup.
Using the Gigabit article from JJK and various iptables/routing article
> On 13 Jun 2017, at 18:49, Pippin1st via Openvpn-users
> wrote:
>
> Hello,
>
> I`m trying to draw a picture where one can see how packets are flowing in a
> routed tun setup.
>
> Using the Gigabit article from JJK and various iptables/routing articles i
> come to attached picture.
> Since
Hi,
On 13/06/17 14:09, Mathias Jeschke wrote:
Hi Greetz Pippin,
Pippin1st wrote:
So, my first question is, how close am I?
Actually, that's a very nice update to my original picture!
At least the order of encryption/decryption and
compression/decompression makes no sense.
it's actually ev
Hi Greetz Pippin,
Pippin1st wrote:
> So, my first question is, how close am I?
At least the order of encryption/decryption and
compression/decompression makes no sense.
Compression should be always done before encryption!
Regarding ICMP: Yes, PMTUD relies on ICMP, thus blocking ICMP is
general
Hello,
I`m trying to draw a picture where one can see how packets are flowing in a
routed tun setup.
Using the Gigabit article from JJK and various iptables/routing articles i come
to attached picture.
Since last time i spend time on this picture i added tcpip stack squares today.
So, my first
23 matches
Mail list logo
