doc: guide user to disable hardware offload

Also update issue temaplte to block unpreapred reports.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -6,7 +6,7 @@ labels: ""
 assignees: ""
 ---
 
-<!-- [en] Please use English language, software translated message is allowed. -->
+<!-- [en] Please use English language, you may use machine translation here. -->
 <!-- [zh] 请使用英语，可以使用翻译软件 -->
 
 **Describe the bug**
@@ -31,9 +31,17 @@ Configuration file:
 **Target Machine (please complete the following information):**
 
 -   Architecture: [e.g. x86-64, aarch64]
--   Linux distribution: [e.g. Arch Linux, OpenWrt]
+-   Linux distribution and version: [e.g. Arch Linux (rolling), OpenWrt (v23.05.5)]
 -   Kernel version: [e.g. 5.15, 6.7.1]
 -   einat version: [e.g. 0.1.1]
 
 **Additional context**
 Add any other context about the problem here, e.g. network interface information, firewall(iptables/nftables) configuration.
+And connection test results of `nslookup aliyun.com 223.5.5.5`, `traceroute -T 223.5.5.5`, `ping -M do -s 1464 223.5.5.5`, etc. .
+
+Please elaborate what you have changed in detail for unchecked options below.
+
+-   [ ] I have read **README** and notes in **config.sample.toml**.
+-   [ ] I don't have any (hardware) offload/acceleration solutions enabled.
+-   [ ] I have a clean firewall or with only firewall rule of TCP MSS Clamping.
+-   [ ] I don't have any special/advanced routing rules other than the basic default routing.

README.md

@@ -122,6 +122,10 @@ see <https://github.com/EHfive/einat-ebpf/issues/19>. Though this only works for
 
 [TCP MSS clamping]: https://wiki.nftables.org/wiki-nftables/index.php/Mangling_packet_headers#Mangling_TCP_options
 
+> [!IMPORTANT]
+> Disable any hardware offload/acceleration solutions before trying out einat, especially on OpenWrt where "acceleration" solutions are commonly abused.
+> As hardware offload solution can't recognize NAT bindings created in einat, the incoming packets flowing over hardware firmware could be dropped due to some internal firewall policies.
+
 To test if this works, you can use tools below on internal network behind NAT. Notice you could only got "Full Cone" NAT if your external network is already "Full Cone" NAT or has a public IP.
 
 -   `stunclient` from [stuntman](https://github.com/jselbie/stunserver)

config.sample.toml

@@ -11,7 +11,7 @@ ipv6_hairpin_table_id = 4787
 # For ports not in specified ranges, einat would passthrough NAT if the traffic
 # is on interface's external address. You should exclude ports of services (
 # e.g. SSH, HTTP server) serving on NAT host's external address and expecting
-# inbound initiaed traffic from NAT port ranges specified here.
+# inbound initiated traffic from NAT port ranges specified here.
 tcp_ranges = ["20000-29999"]
 udp_ranges = ["20000-29999"]
 # Combined ICMP query ID ranges, must include `icmp_in_ranges` and `icmp_out_ranges`.

docs/guide/openwrt.md

@@ -7,6 +7,9 @@ So if the architecture of your router is not x86-64 or aarch64 or other actively
 
 The following is OpenWrt build configs required for `einat` to work.
 
+> [!IMPORTANT]
+> Disable any hardware offload/acceleration solutions before trying out einat.
+
 ## Build Configs
 
 Make sure to use latest OpenWrt release or OpenWrt on main branch.