gateway: more corrections

1 files changed, 35 insertions, 37 deletions

diff --git a/content/posts/openbsd-vpn-gateway/index.org b/content/posts/openbsd-vpn-gateway/index.org
index b958bb5..6879bba 100644
--- a/content/posts/openbsd-vpn-gateway/index.org
+++ b/content/posts/openbsd-vpn-gateway/index.org
@@ -201,11 +201,14 @@
 
    It should output an IP that belongs to our VPN provider.
 
-* sysctl
-  OpenVPN should have already reconfigured the our routing table to
-  send all of our traffic over the VPN connection, but how do we pass
-  incoming traffic through it?
+   We can also check =/var/log/daemon= to check that OpenVPN is
+   outputting logs.
+
+   OpenVPN should have already reconfigured the our routing table to
+   send all of our traffic over the VPN connection, but how do we pass
+   incoming traffic through it?
 
+* sysctl
   The first step is to allow the kernel to forward IP packets
   destined for other hosts. To set this option in the kernel we use
   the [[https://man.openbsd.org/man8/sysctl.8][=sysctl(8)=]] command.
@@ -216,7 +219,7 @@
 
   We're also going to want to make this option persistent, so it
   remains even after rebooting. To do this we add the option to our
-  [[https://man.openbsd.org/man5/sysctl.conf.5][=sysctl.conf(5)=]], which re-applies =sysctl= options on boot.
+  [[https://man.openbsd.org/man5/sysctl.conf.5][=sysctl.conf(5)=]].
 
   #+BEGIN_SRC shell
   doas sh -c 'echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf'
@@ -224,24 +227,18 @@
 
   This can of course also be done with a text editor like =vi= or
   =mg=.
-
-  Setting =net.inet.ip.forwarding= to =1= tells the kernel to
-  forward any packets it receives that aren't destined for any of its
-  interfaces according to its routing table and firewall rules.
-
 * PF Rules
   At this point, we're forwarding the incoming packets out the VPN
   tunnel, but they have no method to find their way back to us. This
-  is because when we're forwarding them, they still have their LAN
-  (Local Area Network) IP addresses (=192.168.0.X=) as the sender
-  address. In order for these to successfully traverse the internet,
-  they're going to need a WAN (Wide Area Network) address. That's
-  what you might call an external IP.
+  is because when we're forwarding them, they still have their [[https://en.wikipedia.org/wiki/Local_area_network][LAN]] IP
+  addresses (=192.168.0.X=) as the sender address. In order for these
+  to successfully traverse the internet, they're going to need a [[https://en.wikipedia.org/wiki/Wide_area_network][WAN]]
+  address. That's what you might call an external IP.
 
-  To accomplish this, we use something called a NAT (Network Address
-  Translation). This allows us to map many local (LAN), IP
-  addresses to a single external (WAN) IP address. We do this using
-  OpenBSD's firewall, PF.
+  To accomplish this, we use something called a [[https://en.wikipedia.org/wiki/Network_address_translation][NAT]] (Network Address
+  Translation). This allows us to map many local (LAN) IP addresses to
+  a single external (WAN) IP address. We do this using OpenBSD's
+  firewall, PF.
 
   This is what our new [[http://man.openbsd.org/man5/pf.conf.5][=pf.conf(5)=]] will look like.
 
@@ -272,7 +269,7 @@
   #+END_SRC
 
   Let's go through this line by line to see what's going
-  on. Something that's important to note with pf is that the last
+  on. Something that's important to note with PF is that the last
   matching rule determines the fate of a packet. This means that if a
   packet matches a =block= rule, but then matches a =pass= rule
   afterwards and is not blocked again, the packet is allowed through,
@@ -293,8 +290,8 @@
 
   - =block return in on ! lo0 proto tcp to port 6000:6010= This is a
     default rule, left in for security reasons. It stops other
-    machines from being able to reach our X Windows session, should we
-    be running one.
+    machines from being able to reach our X11 session, should we be
+    running one.
 
   - =block return out log proto {tcp udp} user _pbuild= This is
     another default rule, left in for security reasons. It stops the
@@ -303,26 +300,27 @@
 
   - =ext_if = "vio0"= We use this macro to set the external interface
     name. This is done so we only have to set the name of the
-    interface in one place, should we ever need to change it.
+    interface in one place.
 
-  - =vpn_if = "tun0"= This is similar to the rule above, except for
-    the VPN tunnel interface.
+  - =vpn_if = "tun0"= This is similar to the macro above, except it's
+    for the VPN tunnel interface.
 
   - =pass in on $ext_if= [[https://man.openbsd.org/OpenBSD-6.7/pf.conf.5#pass][Pass]] all traffic coming in on our external
     interface. This is how we receive traffic from the network.
 
   - =pass out on $ext_if from self= Pass all traffic /originating from
-    us/ out on our external interface, this will allow OpenVPN to
-    communicate with the VPN server without us having to worry about
-    accidentally passing forwarded traffic to the open internet
-    outside of the VPN connection, should OpenVPN ever fail. =self=
-    expands to all IPs belonging to interfaces on our host machine.
+    the VPN gateway/ out on our external interface. This will allow
+    OpenVPN to communicate with the VPN server, but will not allow
+    forwarded traffic out. Because of this, if the VPN connection ever
+    fails, forwarded traffic will be unable to leave the gateway. This
+    provides us with a sort of "kill switch". [[https://man.openbsd.org/OpenBSD-6.7/pf.conf.5#self][=self=]] expands to all
+    IPs belonging to interfaces on our host machine.
 
   - =match out on $vpn_if from $ext_if:network to any nat-to
     ($vpn_if)= This is a big rule, let's break it down into smaller pieces.
 
-    - =match= A [[https://man.openbsd.org/OpenBSD-6.7/pf.conf.5#match][match]] rule is usually used to either apply options to
-      a packet. It does not block or pass a packet itself, but lets pf
+    - =match= A [[https://man.openbsd.org/OpenBSD-6.7/pf.conf.5#match][match]] rule is usually used to apply options to a
+      packet. It does not block or pass a packet itself, but lets PF
       know how to handle a packet once it is blocked or passed. Unlike
       =block= or =pass= rules, a single packet can match many =match=
       rules, and have them all apply.
@@ -330,7 +328,7 @@
     - =out on $vpn_if from $ext_if:network to any= This tells the
       =match= command which packets it should apply the option to.
 
-      - =on $vpn_if= Packets going out on =$vpn_if=, which gets
+      - =out on $vpn_if= Packets going out on =$vpn_if=, which gets
         evaluated to =tun0=.
 
       - =from $ext_if:network= Packets coming from
@@ -345,16 +343,16 @@
       packets to the address on =$vpn_if=. In this case =$vpn_if=
       evaluates to =tun0=.
 
-      Notice that =($vpn_if)= is in parentheses. This tells pf to
+      Notice that =($vpn_if)= is in parentheses. This tells PF to
       re-evaluate the rule when the status of =$vpn_if=
       changes. Without this, if the VPN has to restart, and OpenVPN
       gets assigned a new IP, the entire firewall configuration would
       have to be manually reloaded. Even worse, if OpenVPN starts
-      after pf and there was no IP assigned to =tun0=, the rule set
-      would fail to load.
+      after PF and there was no IP assigned to =tun0=, the entire rule
+      set would fail to load.
 
       With the parentheses, this rule will get updated as =tun0= get
-      updated. This way pf is always using the IP address currently
+      updated. This way PF is always using the IP address currently
       assigned to the interface, even if it changes.
 
       You might be wondering why we only apply the NAT on outbound