[Openvpn-users] Packet flow and ICMP/MTU question

[Jan Just Keijser]

Hi,

Hi Greetz Pippin,

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 even weirder when you read the sources:

1) compress
2) fragment
3) encrypt

and then in reverse on the receiving end, of course.

Compression should be always done before encryption!
Regarding ICMP: Yes, PMTUD relies on ICMP, thus blocking ICMP is
generally a bad idea - why do you have this in place?

uhm, as Pippin stated, his firewall/router does this for him, whether he likes it or not; however, OpenVPN itself does not need
PMTUD if you tweak it manually and *with* openvpn you can use ICMP again over the tunnel itself!


HTH,

JJK

[Antonio Quartulli]

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 question is, how close am I?

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 delivered to OpenVPN.

(not sure how this could be fixed in the diagram)

Cheers,

--
Antonio Quartulli

[Jan Just Keijser]

Hi Antonio,

Post by Antonio Quartulli

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 question is, how close am I?

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 delivered to OpenVPN.
(not sure how this could be fixed in the diagram)

I believe the diagram is correct - packets sent by an application to
tun0 *ARE* processed using iptables before reaching OpenVPN - if you set
a rule
iptables -I INPUT -i tun+ -j DROP
then no packets would enter the tunnel....

JJK

[Antonio Quartulli]

Post by Antonio Quartulli
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
delivered to OpenVPN.
(not sure how this could be fixed in the diagram)
Antonio Quartulli

Post by Jan Just Keijser
I believe the diagram is correct - packets sent by an application to
tun0 *ARE* processed using iptables before reaching OpenVPN - if you set
a rule
iptables -I INPUT -i tun+ -j DROP
then no packets would enter the tunnel....

Hmm, i think so too because putting rules in the forward chain
one can control inter-client traffic...
When pinging from client to client running tcpdump, one can see packets
http://backreference.org/2010/05/02/controlling-client-to-client-connections-in-openvpn/
Also, using the iptables owner module one can make an very effective
"kill switch" for traffic trying to get out where it should not.

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 about point 2): once packets have entered tun0, they directly go to the OpenVPN process (which is attached to tun0), without being processed by routing/iptables again.


Cheers,


--
Antonio Quartulli

[Antonio Quartulli]

Post by Antonio Quartulli
in your diagram, on the sending side, packets cross the
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 about point 2): once packets have entered tun0,
they directly go to the OpenVPN process (which is attached to tun0),
without being processed by routing/iptables again.

Aah ok, so rules are applied from OpenVPN > to > tun.
So, in the example of the owner module and my previous link
to backreference OpenVPN itself is also Apps,
there i was confused.
Thanks for clearing that up.
Please see attached image, i think it`s correct *enough* now.

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.




Cheers,

[Jan Just Keijser]

Hi Pippin,

Hello,

Post by Antonio Quartulli
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 at SERVER side,
-A FORWARD -s 10.180.0.4 -d 10.180.0.11 -j ACCEPT
-A FORWARD -s 10.180.0.11 -d 10.180.0.4 -j ACCEPT
-I INPUT -i tun+ -j DROP
would still apply.
And reading the backreference article,

Post by Antonio Quartulli
"You see each packet twice (but note the decremented TTL),
meaning that it really goes out and then back into tun0"

seems to confirm. In diagram 3a traffic would first
come out then go back in.
Hope it`s more correct now or still missing something ?:)

for client-to-server traffic this looks correct ; client-to-client
traffic is another matter.

HTH,

JJK

[David Sommerseth]

Post by Jan Just Keijser
Hi Pippin,

Hello,

Post by Antonio Quartulli
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 at SERVER side,
-A FORWARD -s 10.180.0.4 -d 10.180.0.11 -j ACCEPT
-A FORWARD -s 10.180.0.11 -d 10.180.0.4 -j ACCEPT
-I INPUT -i tun+ -j DROP
would still apply.
And reading the backreference article,

Post by Antonio Quartulli
"You see each packet twice (but note the decremented TTL),
meaning that it really goes out and then back into tun0"

seems to confirm. In diagram 3a traffic would first
come out then go back in.
Hope it`s more correct now or still missing something ?:)

This looks correct to me. You can actually think of "OpenVPN" and the
tun/tap device as one entity. A tun/tap adapter may only be used by a
single process. OpenVPN have a file descriptor to its tun/tap adapter
which it reads from and writes to. That data is sent to the kernel's
networking stack. This might be clearer if you consider the server or
client having more eth devices, or consider how --redirect-gateway would
interact.

Post by Jan Just Keijser
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; and IIRC, OpenVPN
treats multicast as unicast traffic).

And of course, the mysterious and well hidden packet filter in OpenVPN
is also somewhere after the decompression and before the compression.

[Gert Doering]

Hi,

Post by David Sommerseth

Post by Jan Just Keijser
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; and IIRC, OpenVPN
treats multicast as unicast traffic).

And unless "--client-to-client" is not set (which it isn't by default!).

Then the openvpn server will forward all client-to-client traffic towards
the tun/tap interface, only to have the other side send it back *after
firewall inspection*.

gert

[debbie10t]

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 improvements could be made .. ;)

[Antonio Quartulli]

Hello,

Post by Gert Doering
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 (and the other side
of the VPN) are processed "out on tunX", while packets coming from
the VPN are processed "in on tunX".

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.

Your previous picture was correct..

I clarified with Gert on IRC because he did not realize that my comments
were about your specific diagram, but he thought I was generally stating
how the big picture of OpenVPN works (including remote hosts etc..).

Cheers,

[Gert Doering]

Hi,

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.
Attached new diagram no.4

As far as I can see, this is factually correct and quite helpful in
understanding the packet flow through the full chain of "things involved"
- great work.

It's missing a small detail (which is not easy to add, admittedly) for
point-to-multipoint servers: there is a routing table *inside* the
openvpn process (iroute), which decides which client the packet should
receive. This happens between "read from tun" and "compress" (as
the compression algorithm is per-client).

gert

[Gert Doering]

Hi,

Post by Antonio Quartulli
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 firewalls, and by the routing.

Post by Antonio Quartulli
Basically the idea is that OpenVPN and the tun0 interface are directly attached,
so I/O between the two is direct.

While they are directly attached, there is full blast iptables inbound
and outbound on the tun0 side.

So it's actually *better* to imagine "the OpenVPN server" to be a black
box connected to a second network card of the "Linux server", named "tun0"
(and that actually explains routing/filtering/iroute-vs-route quite well).

gert

[Gert Doering]

Hi,

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 "tun0 thing" in the kernel, and iptables/routing are
really on the "app side" of the tun0).

Language can be confusing.

gert

[Gert Doering]

Hi,

Post by Antonio Quartulli
in your diagram, on the sending side, packets cross the
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 about point 2): once packets have entered tun0,
they directly go to the OpenVPN process (which is attached to tun0),
without being processed by routing/iptables again.

Aah ok, so rules are applied from OpenVPN > to > tun.

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 (and the other side
of the VPN) are processed "out on tunX", while packets coming from
the VPN are processed "in on tunX".

*Inside* OpenVPN, there's potentially a second set of firewall rules,
but those are "OpenVPN pf rules", not related (and not visible to)
host side iptables.

gert