Doubts about iroute and packets travels

rogerl

hi,

I have an environment working fine using openvpn where I use the iroute parameter in CCD file to the subnets behind the openvpn clients learn to communicate between the hosts from subnet A to subnet B.

Ok... thats is working.. but what is the magic?

When I try to use tcpdump on tun0 to see the packages between the hosts, nothing is showed and the hosts are communicating!

I've tried to drop all packages with iptables and everything still working!!!

Where do packets travels??

Thanks

TinCanTech

See --client-to-client in the manual.

Pippin

Maybe this image helps understanding what's going on:

When using --client-to-client, packets do not leave the OpenVPN process, they are routed internally.
If you want to see or firewall the packets on the tun interface you need to NOT use --client-to-client.

TinCanTech

Nice diagram :mrgreen:

You could even possibly improve it:

--client-to-client would be a "short circuit" in the server just before --iroute
Technically, the client does not have any --iroute 😉
Also mbedTLS

Edit:
--tls-auth is actually not 2048bit, the HMAC uses only either 256 or 512 bits. (I forget which)
This means that the TLS auth file does not even need to be an exact match on both ends !

Pippin

Hi,

I'm aware about the tls-auth key but it really is 2048 bit (4x 512), more here:
https://community.openvpn.net/openvpn/wiki/327-changed-hex-bytes-in-the-static-key-the-key-still-connects-to-a-remote-peer-using-the-original-key

Above diagram is for a routed tun setup.
Edited the diagram above to include mbedTLS.

Yes, I thought about including client-to-client (and more) but I think it would only clutter the diagram to become unreadable.
Maybe draw different diagrams for different configurations.....

TinCanTech

Adding a --client-to-client stage seems like a reasonable improvement to an openvpn diagram, to me.
It is only one line and a legend entry .. but it is your diagram and was only a suggestion. 8-)

Pippin wrote I'm aware about the tls-auth key but it really is 2048 bit (4x 512)

HMAC really is not 2048bit even with SHA512 it is only 1024bit. The key material file is but that is all.

Example.

With --auth SHA1

Fri Feb 22 21:51:08 2019 us=998990 86.14.232.194:3644 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 22 21:51:08 2019 us=999013 86.14.232.194:3644 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
<snip>
Fri Feb 22 21:51:09 2019 us=240934 86.14.232.194:3644 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Feb 22 21:51:09 2019 us=240957 86.14.232.194:3644 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 22 21:51:09 2019 us=240973 86.14.232.194:3644 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Feb 22 21:51:09 2019 us=240989 86.14.232.194:3644 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication

Which is a total of 320bit for TLS auth HMAC I/O. (and only then if a direction is specified, otherwise 160bit)

--tls-auth: Add an additional layer of HMAC authentication on top of the TLS control channel
Your diagram specifies "tls-auth"

I am unsure about the rest of the wiki article you quote because it appears to be incorrect ..

For example, a TLS auth key file is not used by a cipher like blowfish.

Pippin

Ok, updated diagram:

For example, a TLS auth key file is not used by a cipher like blowfish.

From what I understand the cipher is not "intertwined" with tls-auth (or vice versa) because one can have an unencrypted tunnel (--cipher none) but still authenticate packets... ?
Maybe "additional layer of HMAC" is not the correct description?

TinCanTech

Pippin wrote From what I understand the cipher is not "intertwined" with tls-auth (or vice versa) because one can have an unencrypted tunnel (--cipher none) but still authenticate packets... ?

You did try right ?

Options error: Parameter tls_auth_file can only be specified in TLS-mode, i.e. where --tls-server or --tls-client is also specified.

😉

Pippin wrote Maybe "additional layer of HMAC" is not the correct description?

I think the description is accurate.