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
