6. In that case, simply change "10.0.8.0/24" to "10.0.8.4/32". For explanation sake, .0/24 means "everything connected to this network", whereas ".4/32" means "only this specific machine", so does ".3/32", ".2/32", ".5/32", and so on.
7. If you've followed Vultr's post, you might consider changing the /etc/hostname.wg0 file to just this one liner: !/usr/local/bin/wg-quick up wg0 On 2023年08月13日 16:57, SOUBHEEK NATH wrote: > Hello Lain, > > I appreciate your feedback and the time you took to provide it. > > 1. I set up OpenBSD 7.3 on a Raspberry Pi 4B with 4GB of RAM, which is > running from a USB drive. > 2. This is not a production environment, it is solely for educational > purposes. > 3. The router is currently using its default settings and three other > devices are connected to it. > 4. The wireless router is currently using its default settings to > assign IP addresses to three other devices that are connected to it. > You are correct, with this setup and pf rule, the wireguard VPN > server is accessible from within the local area network. However, I > believe that in the future, I can use the same setup and pf rule to > remotely access the server's ports exclusively through the wireguard > VPN from outside the network. > 5. Your configuration is functioning correctly, allowing only devices > within the wireguard network to access ports 22 and 80, while > blocking access for others. > 6. However, I cannot allow only one device with the IP address 10.0.8.4. > All devices in the wireguard network are able to access ports 22 and > 80. > I have attempted to use the following pf rule: > > set skip on lo > > block return # block stateless traffic > pass # establish keep-state > > # By default, do not permit remote connections to X11 > block return in on ! lo0 proto tcp to port 6000:6010 > > # Port build user does not need network > > pass in quick on wg0 proto tcp from 10.0.8.4 to any port {22, 80} > block in quick on egress proto tcp from any to any port {22, 80} > > block return out log proto {tcp udp} user _pbuild > > pass in on egress proto tcp from any to any port 22 > > pass out on egress inet from (wg0:network) nat-to (bwfm0:0) > > Based on my understanding of the OpenBSD PF-Packet filtering document > (https://www.openbsd.org/faq/pf/filter.html), the intention of this > pf rule is to allow only the IP address 10.0.8.4 to access ports 22 > and 80. However, currently both machines with IP addresses 10.0.8.2 > and 10.0.8.3 are able to access ports 22 and 80. > > 7. I have already falsified the private and public keys when submitting > this question. > I attempted to include 'Address = 10.0.8.1/32' in the wireguard > [Interface] block earlier as you suggested, but encountered an error. > > $ doas sh /etc/netstart wg0 > Line unrecognized: `Address=10.0.8.1/24' > Configuration parsing error > > I've gone through this link while setting up wireguard: > https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/ > Despite its absence, wireguard is functioning properly. > > 8. I greatly appreciate your suggestion regarding the PreShareKey in > wireguard configuration. It would be a valuable addition to my > knowledge and will benefit me in the future. > > Thanks again. > -- > Soubheek Nath > Fifth Estate > Kolkata, India > soubheekn...@gmail.com > > On Sun, Aug 13, 2023 at 7:04 AM lain. <l...@fair.moe> wrote: > > > > I failed to come up with reasons for using a preshared key, so I've let > > ChatGPT generate reasons for me: > > > > Certainly! WireGuard's use of a preshared key (PSK) adds an additional > > layer of symmetric encryption to the standard asymmetric encryption. Here's > > a brief explanation of the advantage: > > > > 1. **Symmetric vs. Asymmetric Encryption**: WireGuard primarily uses > > asymmetric encryption, where each party has a pair of keys (public and > > private). Symmetric encryption, on the other hand, utilizes the same key > > for both encryption and decryption. By adding a PSK, WireGuard incorporates > > both types of encryption. > > > > 2. **Additional Security Layer**: The PSK is mixed into the encryption > > process along with the standard public and private keys. Even if an > > attacker could somehow compromise the asymmetric part (though practically > > very difficult), they would still need the PSK to decrypt the communication. > > > > 3. **Protection Against Quantum Attacks**: Though still theoretical at this > > point, quantum computers could eventually break the Diffie-Hellman key > > exchange used in many encryption protocols. By using a PSK, WireGuard adds > > protection against this potential future vulnerability. > > > > 4. **Simplicity**: WireGuard's design is intended to be simple and easy to > > implement. The use of a PSK aligns with this philosophy by providing a > > straightforward way to bolster security. > > > > Here's an example of how you would generate and implement a preshared key > > in WireGuard: > > > > Generate the PSK: > > ```bash > > wg genpsk > > ``` > > > > You would then add the generated key to both the client and server > > configurations: > > > > Server's `wg0.conf`: > > ```ini > > [Peer] > > PublicKey = CLIENT_PUBLIC_KEY > > PresharedKey = GENERATED_PRESHARED_KEY > > AllowedIPs = CLIENT_IP/32 > > ``` > > > > Client's `wg0.conf`: > > ```ini > > [Peer] > > PublicKey = SERVER_PUBLIC_KEY > > PresharedKey = GENERATED_PRESHARED_KEY > > AllowedIPs = 0.0.0.0/0 > > Endpoint = SERVER_IP:PORT > > ``` > > > > In summary, adding a PSK provides an extra layer of security that > > complements the existing asymmetric encryption, protects against potential > > quantum attacks, and adheres to WireGuard's principles of simplicity and > > effectiveness. > > > > On 2023年08月13日 10:22, lain. wrote: > > > First off, unless you faked your private and public keys, please change > > > them as soon as possible. > > > You've just made yourself volunerable to cyber attacks! > > > > > > If I understand you correctly, you want to be able to SSH and HTTP only > > > over WireGuard, right? > > > In that case, on your WireGuard server: > > > > > > # Block access to SSH and HTTP from everyone except for your WireGuard > > > network > > > pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80} > > > block in quick on egress proto tcp from any to any port {22, 80} > > > > > > From your specifications, it's not quite clear whether your network is > > > accessible from the outside or not, whether you're using a dynamic IP or > > > static IP, how your router is configured, and all else, because > > > requirements change depending on these details. > > > If you're using a dynamic IP, and both your server and clienbts are > > > within the same network, there's a good chance that this setup is > > > unnecessary, given that using a WireGuard VPN makes sense if the server > > > is remote and normally accessible from the outside, and you want to make > > > it only accessible from the inside. > > > > > > As for your WireGuard config, you might want to add the Address to your > > > "[Interface]" block like this for example: > > > Address = 10.0.8.1/24 > > > > > > Not necessarily required to get it working, but would still add an extra > > > layer of security if you generate a preshared key on each peer, then on > > > both your server and peers: > > > [Peer] > > > ... > > > PreSharedKey = (output) > > > ... > > > > > > To generate the preshared key (only do this on your peers): > > > wg genpsk > preshared.key > > > > > > On 2023年08月12日 20:30, SOUBHEEK NATH wrote: > > > > Dear OpenBSD Mailing List Community, > > > > > > > > I hope this email finds you well. I am writing to seek your expertise > > > > and guidance regarding a Wireguard VPN configuration and pf rules on my > > > > OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using > > > > the provided interface configuration, and the VPN is operational as > > > > intended. However, I have encountered a challenge while attempting to > > > > implement pf rules to restrict access to SSH login and port number 80 > > > > based on specific IP addresses. > > > > > > > > Below is the pf rule settings I have applied: > > > > > > > > set skip on lo > > > > block return # block stateless traffic > > > > pass # establish keep-state > > > > > > > > # By default, do not permit remote connections to X11 > > > > block return in on ! lo0 proto tcp to port 6000:6010 > > > > > > > > # Port build user does not need network > > > > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0 > > > > port ssh > > > > block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80 > > > > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0 > > > > port 80 > > > > block return out log proto {tcp udp} user _pbuild > > > > > > > > pass in on egress proto tcp from any to any port 22 > > > > > > > > pass out on egress inet from (wg0:network) nat-to (bwfm0:0) > > > > > > > > The objective of these rules is to restrict SSH login and access to port > > > > 80 exclusively for the machine with the IP address 192.168.0.229 when > > > > the OpenBSD system is connected to the bwfm0 network interface. While > > > > the rule for SSH login and IP address 192.168.0.229 is functioning as > > > > expected, I have encountered an issue with the rule pertaining to port > > > > 80 and IP address 10.0.8.2, which is allocated by Wireguard (wg0) > > > > during active Wireguard connections. > > > > > > > > The problem arises when attempting to enforce the restriction on port 80 > > > > with IP address 10.0.8.2. Despite the pf rule in place, it seems that > > > > Wireguard is overriding the restriction. For instance, devices with > > > > assigned IP addresses such as 10.0.8.3 or 10.0.8.4, which are within > > > > the Wireguard network, can access both SSH login and port 80, contrary > > > > to the intended restriction. > > > > > > > > I am providing the Wireguard configuration below for your reference: > > > > > > > > [Interface] > > > > ListenPort = 51820 > > > > PrivateKey = oPernzzF+Kl499z2TMU6wDdrDpnDN6/e630Q= > > > > > > > > [Peer] > > > > PublicKey = yyhY5Blx+PxCHu/wK7QgrXHQ34RmTi//zynVA= > > > > AllowedIPs = 10.0.8.2/32 > > > > PersistentKeepalive = 25 > > > > > > > > [Peer] > > > > PublicKey = dQO6ACctkgepDtWxGrHuGFdvaO9qfrL4mmjA= > > > > AllowedIPs = 10.0.8.3/32 > > > > PersistentKeepalive = 25 > > > > > > > > I would greatly appreciate your insights, suggestions, and expertise in > > > > resolving this issue. Your assistance will be invaluable in helping me > > > > achieve the desired access restrictions while maintaining the > > > > functionality of the Wireguard VPN. > > > > > > > > Thank you for your time and consideration. > > > > -- > > > > Soubheek Nath > > > > Fifth Estate > > > > Kolkata, India > > > > soubheekn...@gmail.com > > > > > > > > > > -- > > > lain. > > > > > > Did you know that? > > > 90% of all emails sent on a daily basis are being sent in plain text, and > > > it's super easy to intercept emails as they flow over the internet? > > > Never send passwords, tokens, personal information, or other volunerable > > > information without proper PGP encryption! > > > > > > If you're writing your emails unencrypted, please consider sending PGP > > > encrypted emails for security reasons. > > > You can find my PGP public key at: https://fair.moe/lain.asc > > > > > > Every good email client is able to send encrypted emails. > > > If yours can't, then you should consider switching to a secure email > > > client, because yours just sucks. > > > > > > My recommendations are Claws Mail or NeoMutt. > > > For instructions on how to encrypt your emails: > > > https://unixsheikh.com/tutorials/gnupg-tutorial.html > > > > -- > > lain. > > > > Did you know that? > > 90% of all emails sent on a daily basis are being sent in plain text, and > > it's super easy to intercept emails as they flow over the internet? > > Never send passwords, tokens, personal information, or other volunerable > > information without proper PGP encryption! > > > > If you're writing your emails unencrypted, please consider sending PGP > > encrypted emails for security reasons. > > You can find my PGP public key at: https://fair.moe/lain.asc > > > > Every good email client is able to send encrypted emails. > > If yours can't, then you should consider switching to a secure email > > client, because yours just sucks. > > > > My recommendations are Claws Mail or NeoMutt. > > For instructions on how to encrypt your emails: > > https://unixsheikh.com/tutorials/gnupg-tutorial.html >