BulletVPN's adoption of WireGuard with ChaCha20 encryption provides a robust and modern security posture. Unlike AES-based implementations, ChaCha20, coupled with Poly1305 for authentication, offers comparable security with improved performance on platforms lacking dedicated AES-NI instruction sets. This is particularly beneficial for embedded devices and older CPUs where AES acceleration is absent.
To configure WireGuard with BulletVPN using ChaCha20, the following steps are typically involved. First, generate your private and public keys using wg genkey | tee privatekey | wg pubkey > publickey. Replace privatekey and publickey with your desired filenames. Then, exchange your public key with BulletVPN. This is usually done through the BulletVPN control panel.
Next, configure your wg0.conf file (or the appropriate interface name). A sample configuration looks like this:
[Interface]
PrivateKey = <YourPrivateKey>
Address = <YourAssignedIP>/32
DNS = <BulletVPN DNS Server 1>, <BulletVPN DNS Server 2>
[Peer]
PublicKey = <BulletVPNPublicKey>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <BulletVPNServerAddress>:<Port>
PersistentKeepalive = 25
Ensure <YourPrivateKey>, <YourAssignedIP>, <BulletVPN DNS Server 1>, <BulletVPN DNS Server 2>, <BulletVPNPublicKey>, <BulletVPNServerAddress>, and <Port> are replaced with the correct values provided by BulletVPN. AllowedIPs of 0.0.0.0/0, ::/0 route all traffic through the VPN. PersistentKeepalive prevents NAT timeouts. The encryption in use is negotiated automatically as ChaCha20-Poly1305 when both sides support it.
Proper routing is critical to ensure all traffic is tunneled through the BulletVPN WireGuard interface. After activating the wg0 interface with wg-quick up wg0, verify the routing table using ip route. A default route pointing to the WireGuard interface (e.g., dev wg0) should be present.
DNS leak prevention is equally important. The DNS parameter in the wg0.conf file should point to BulletVPN's DNS servers. To further prevent leaks, consider configuring your system to only use these DNS servers when the WireGuard interface is active. This can be achieved through resolvconf or similar tools, ensuring that no DNS requests are sent outside the encrypted tunnel. A post-up script can modify /etc/resolv.conf and a pre-down script restores it.
The firewall must be configured to allow traffic through the WireGuard interface and block traffic that might bypass the VPN. A basic iptables configuration might look like this:
# Allow outbound traffic through WireGuard
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -j ACCEPT
# Block all other outbound traffic
iptables -A OUTPUT -j DROP
# Masquerade traffic
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
These rules allow all outbound traffic through the wg0 interface, forward traffic through it, and masquerade the traffic to hide your internal IP address. The DROP rule prevents traffic from leaking through other interfaces if the WireGuard connection fails. Adapt these rules to your specific firewall (e.g., nftables or ufw).
While ChaCha20 offers strong security, its performance characteristics differ from AES. On CPUs with AES-NI support, AES generally outperforms ChaCha20. However, on CPUs lacking AES-NI, ChaCha20 can provide significantly better performance due to its simpler instruction set. This makes BulletVPN's ChaCha20 implementation particularly suitable for mobile devices, routers, and older computers. Benchmarking tools like openssl speed chacha20 can be used to evaluate performance on your specific hardware.
To verify that WireGuard is using ChaCha20 and that your configuration is correct, use the wg show command. This command displays the current WireGuard configuration, including the negotiated encryption algorithms. You should see "ChaCha20-Poly1305" listed as the encryption algorithm in use.
Additionally, use a packet capture tool like tcpdump or Wireshark to inspect the traffic on the WireGuard interface. The captured packets should be encrypted, and you should not be able to discern any plaintext data. DNS leak tests available online can also verify that your DNS requests are being routed through the VPN.