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
>
