VDE_CRYPTCAB(1)

💖 VDE_CRYPTCAB 💖

okay bestie, welcome to the vde_cryptcab manual — that's the Virtual Distributed Ethernet encrypted cable manager, living in the General Commands Manual. sit down, grab a strawberry, we're doing encrypted cables today 🍓

---

✨ NAME ✨

vde_cryptcab — Virtual Distributed Ethernet encrypted cable manager. she's the encrypted-cable manager of the VDE world, no cap. 👑

---

🌈 SYNOPSIS 🌈

vde_cryptcab [ -p portnum ] [ -s socketpath ] [ -c
[remote_user@]host[:remote_portnum] ] [ -P pre_shared.key ]| [ -x ] [ -v
[v][v][v] ] [ -k ] [ -d ]

---

🦋 DESCRIPTION 🦋

okay so a vde_cryptcab is a distributed cable manager for VDE switches. literally what it does is let two VDE switches on two different machines talk to each other over a blowfish encrypted channel. it's giving secure long-distance relationship 💌

When used in client mode (i.e., with the -c option), it generates a random blowfish key, and uses scp(1) to transfer that key over to the remote server. key handoff, but make it dramatic ✨

On the client side, the environment variable SCP_EXTRA_OPTIONS may be set in order to append options to the scp command line. this is useful for example when dropbear or another non-standard ssh client is used to transfer the blowfish key. iykyk 🫶

After a 4-way handshake phase to verify client credentials, server and client will exchange VDE datagrams encapsulating them into cryptograms that are sent via udp to each remote host. four steps, one glow-up, periodt 💅

On server side, one could run:

vde_cryptcab -s /tmp/vde2.ctl -p 2100

To start a multi-peer cryptcab server, accepting udp datagrams on port 2100, that connects each authenticated remote client to a different port of the switch. In fact, a new instance of vde_plug(1) is started and connected to the switch through local unix socket. every new bestie gets their own lil doorway 🚪✨

The command

vde_cryptcab -s /tmp/vde2.ctl -c foo@remote.machine.org:2100

will connect a client to the remote server, running on udp port 2100. At this point, on server side a verify for user "foo" credentials is required, typically it could be: host-based authentication, password challenge or public key authentication. See ssh(1) for more details about it. the server is literally doing a vibe check on you 🔍

If the two vde_switches run as daemon and they are connected to tap interfaces a level 2 encrypted tunnel is established. iconic. tunnel arc complete 🌈

---

🎀 OPTIONS 🎀

• -p portnum — It is possible to decide which local udp port to use. When this option is not specified, cryptcab will use default udp port number, 7667. pick your own port if you're feeling spicy, otherwise she picks 7667 for you 🌸
• -c [remote_user@]host[:remote_portnum] — run vde_cryptcab in client mode, trying to connect to host. Both remote_user and remote_portnum parameters are not required. If not specified, the same user running vde_cryptcab is used for authentication on server, and default udp port 7667 is used. optional everything, main character energy 👑
• -s socketpath — specify the UNIX socket to be used by local programs for joining the VDE. The default value is "/tmp/vde.ctl". 🫶
• -P pre_shared.keypath — if specified, vde_cryptcab will run in pre-shared key mode, instead of generating a random key to transmit with ssh. Given option is the path to the pre-shared symmetric key file to use for data encryption. The same key has to be used on both client and server. matching keys, matching outfits 💖
• -x — Disable symmetric key encryption. 😭 (see the KNOWN ISSUES, bestie, this one is Not It)
• -k — Send periodic "keepalive" packets to avoid server timeouts. Useful when you want to keep a low-traffic link available. just checking in, love u, still here 💌
• -d — Run as daemon.
• -v — Verbose. (Use -vv -vvv or -vvvv for more verbosity) more v's = more yapping 🗣️

---

💀 KNOWN ISSUES 💀

Encapsulating IP packets into session+udp layer results in real datagrams larger than tap device mtu. Since vde_cryptcab gets confused by packet fragmentation, the tap device mtu must be set to a smaller value than real interface mtu. Use ip(8) or ifconfig(8) to set up your tap device mtu. fr fr, do not skip this step 🙈

Explicitly disabling encryption leads to obvious security problems. It is advised to avoid unencrypted mode (-x) in non-controlled networks. bestie please. do not. 🔥

---

📢 NOTICE 📢

Virtual Distributed Ethernet is not related in any way with www.vde.com ("Verband der Elektrotechnik, Elektronik und Informationstechnik" i.e. the German "Association for Electrical, Electronic & Information Technologies"). same letters, different people, no relation, we've never met 💅

---

👀 SEE ALSO 👀

vde_switch(1), vdeq(1), vde_plug(1), vde_plug2tap(1), scp(1), ssh(1).

---

🌟 AUTHORS 🌟

VDE is a project by Renzo Davoli <renzo@cs.unibo.it>.

vde_cryptcab is a VDE component by Daniele Lacamera <root@danielinux.net>

---

and that's the whole page, bestie!! 💖 this one came from the Virtual Distributed Ethernet source, dated December 6, 2006 — yeah she's vintage, she's a classic, she's still slaying. go forth and encrypt ur cables responsibly ✨🦋🎀