diff --git a/opnsense/readme.md b/opnsense/readme.md
index 109d4f4..719d9ee 100644
--- a/opnsense/readme.md
+++ b/opnsense/readme.md
@@ -155,6 +155,49 @@ its on by default
 ---
 ---
 
+<details>
+<summary><h1>Web GUI access from WAN side</h1></summary>
+
+For example in cases where the only thing under protection of opnsense
+are some VMs on a hypervisor, but managment is easier done from the host.<br>
+Or if the risk is acceptabale,hoping random port, long password for a non-root user,
+and maybe some IP restrictios will be enough.
+
+- `pfctl -d` disables firewall and allows immediate web gui access on the WAN IP.<br>
+  A restart of opnsense will always re-enable packet filtering
+- Disable `Block private networks` in `Interfaces: [WAN]`.
+- Set up a firewall rule that allows WAN traffic in `Firewall: Rules: WAN`<br>
+  Add new rule; everything is left default except the `Destination`
+  is set to `This Firewall`.<br>
+  Can also enable `Log packets that are handled by this rule` if use of this rule
+  should be visible in `Firewall: Log Files: Live View`.
+- Turn on `Disable reply-to` in `Firewall: Settings: Advanced`,<br>
+  otherwise connections made from the same network will not get through.<br>
+  Some [read on this.](https://forum.opnsense.org/index.php?topic=15900.0)
+- Reboot.<br>
+  Afterwards opnsense should be accessible on WAN IP, without the need for `pfctl -d`.
+
+For some harderining of security.
+
+* Change the default web gui port in `System: Settings: Administration`.<br>
+  From `443` to something random in range of 1024-65k, something like 32179.<br>
+  Afterwards to access opnsense the port must be added to the url `<IP>:32179`
+* Turn off `HTTP Redirect` in `System: Settings: Administration`.<br>
+  This only allows https encrypted communication.
+* Create a new user; add to administrators; disable `root` user
+  in `System: Access: Users`.<br>
+  Brute forcing username and password is more difficult than brute force
+  password for a known user `root`.
+* Adjust the firewall WAN rule to be more restrictive.<br>
+  Instead of `source` being `any`, setting a specific single machine IP.<br>
+  Either right in the rule with `Single host or Network` and `192.168.1.200/32`,<br>
+  or setting up an alias in `Firewall: Aliases`, setting IP in the `Content` field
+
+</details>
+
+---
+---
+
 <details>
 <summary><h1>Port fowarding and NAT reflection(hairpin/loopback)</h1></summary>
 
@@ -319,11 +362,14 @@ Assuming you are not in the country from which these run their test.
 <details>
 <summary><h1>Monitoring</h1></summary>
 
-### current live view of connections
+### live view of connections
 
 Firewall: Log Files: Live View<br>
-The filter and autorefresh on/off allow to investigate traffic
+Great tool to investigate settings and behavior with it's filter
+and autorefresh on/off and up to 20k last entries
 
+* checking out a specific firewall rule latest use<br>
+  `label` `contains` `some string from the rules description`<br>
 * targeting specific ip on the LAN, for example docker host<br>
   `dst` `is` `192.168.19.200`<br> 
   or ip address of a reverse proxy in docker, for me it was `10.36.44.8`
@@ -336,8 +382,6 @@ The filter and autorefresh on/off allow to investigate traffic
   - IN on WAN interface means traffic is coming in to 
   - OUT on LAN means its leaving firewall and heading to LAN 
   - OUT on WAN means its leaving firewall and heading to the WAN side
-* 
-
 
 </details>