Move max_mss to config.cfg (#1015)

* Move max_mss to config.cfg

* Add docs about max_mss

* Update troubleshooting.md

config.cfg

@@ -18,6 +18,16 @@ vpn_network_ipv6: 'fd9d:bc11:4020::/48'
 wireguard_enabled: true
 wireguard_port: 51820
 
+# MSS is the TCP Max Segment Size
+# Setting the 'max_mss' Ansible variable can solve some issues related to packet fragmentation
+# This appears to be necessary on (at least) Google Cloud,
+# however, some routers also require a change to this parameter
+# See also:
+# - https://github.com/trailofbits/algo/issues/216
+# - https://github.com/trailofbits/algo/issues?utf8=%E2%9C%93&q=is%3Aissue%20mtu
+# - https://serverfault.com/questions/601143/ssh-not-working-over-ipsec-tunnel-strongswan
+#max_mss: 1316
+
 server_name: "{{ ansible_ssh_host }}"
 IP_subject_alt_name: "{{ ansible_ssh_host }}"
 

docs/troubleshooting.md

@@ -196,7 +196,9 @@ You're trying to connect Ubuntu or Debian to the Algo server through the Network
 
 ### Various websites appear to be offline through the VPN
 
-This issue appears intermittently due to issues with MTU size. If you experience this issue, we recommend [filing an issue](https://github.com/trailofbits/algo/issues/new) for assistance. Advanced users can troubleshoot the correct MTU size by retrying `ping` with the "don't fragment" bit set, then decreasing packet size until it works. This will determine the correct MTU size for your network, which you then need to update on your network adapter.
+This issue appears intermittently due to issues with MTU size. Different networks may require the MTU within a specific range to correctly pass traffic. We made an effort to set the MTU to the most conservative, most compatible size by default but problems may still occur.
+
+Advanced users can troubleshoot the correct MTU size by retrying `ping` with the "don't fragment" bit set, then decreasing packet size until it works. This will determine the correct MTU size for your network, which you then need to update on your network adapter.
 
 E.g., On Linux (client -- Ubuntu 18.04), connect to your IPsec tunnel then use the following commands to determine the correct MTU size:
 ```
@@ -209,6 +211,8 @@ Then, set the MTU size on your network adapter (wlan0 or eth0):
 $ sudo ifconfig wlan0 mtu 1438
 ```
 
+You can also set the `max_mss` variable to a new value in config.cfg, and then redeploy your server rather than reconfigure the current one in-place.
+
 ### "Error 809" or IKE_AUTH requests that never make it to the server
 
 On Windows, this issue may manifest with an error message that says "The network connection between your computer and the VPN server could not be established because the remote server is not responding... This is Error 809." On other operating systems, you may try to debug the issue by capturing packets with tcpdump and notice that, while IKE_SA_INIT request and responses are exchanged between the client and server, IKE_AUTH requests never make it to the server.

roles/vpn/templates/rules.v4.j2

@@ -11,14 +11,6 @@
 :POSTROUTING ACCEPT [0:0]
 
 {% if max_mss is defined %}
-# MSS is the TCP Max Segment Size
-# Setting the 'max_mss' Ansible variable can solve some issues related to packet fragmentation
-# This appears to be necessary on (at least) Google Cloud,
-# however, some routers also require a change to this parameter
-# See also:
-# - https://github.com/trailofbits/algo/issues/216
-# - https://github.com/trailofbits/algo/issues?utf8=%E2%9C%93&q=is%3Aissue%20mtu
-# - https://serverfault.com/questions/601143/ssh-not-working-over-ipsec-tunnel-strongswan
 -A FORWARD -s {{ vpn_network }}{% if wireguard_enabled %},{{ wireguard_vpn_network }}{% endif %} -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss {{ max_mss }}
 {% endif %}