As long as your LAN has internet connectivity the gateway should be able to just reach your server on WAN. Typically outbound ports are open as well so firewall shouldn’t be an issue.
No Chirpstack changes, firewall shouldn’t be an issue but would be the first thing to investigate if the setup fails, no NAT is required - the gateway reaches out to the server not vice-versa.
This is the real question here.
You should have all interfaces that are exposed to the internet secured with encryption and authentication. The only two interfaces you should need exposed are the webUI/grpc and MQTT/the gateway bridge (depending on whether you are using MQTT forwarder or UDP forwarder on your gateway).
The webUI already has authentication but not encryption, so you need to add a reverse-proxy in front that terminates TLS and passes unencrypted traffic to Chirpstack.
The MQTT/gateway bridge has neither authentication nor encryption by default. I’ll assume you are using the MQTT forwarder, as UDP is harder to secure. So for this you can either use Chirpstacks built in TLS features to secure the MQTT broker: Mosquitto TLS configuration - ChirpStack open-source LoRaWAN® Network Server documentation. Or you can also just go the reverse-proxy route to terminate TLS with a password file on your mosquitto to require user login. I’d recommend just using either NGINX + certbot or Traefik to handle all the TLS for the UI/MQTT, makes it easier because they can generate certificate and renew them automatically. Here’s a good thread about it: How to Secure MQTT Messages on ChirpStack to Prevent Unauthorized Access? - #14 by bastienvty
Not sure on this one. It gets a little tricky because only one server can respond to the uplinks/joins, which mean the other server would need to share all of the keys so it can decrypt the traffic. There probably would be a way but I am not sure if it is included in base Chirpstack.