WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me

NAT and Firewall Policy for new Helm File Service

Recently Helm released an update that added file sync capabilities. From the information on the app and on their site it appears they have partnered with NextCloud to offer dropbox or box-like functionality right on your Helm server.

There are two differences between the traffic flow for email and file sync. File sync traffic from your mobile device will go directly to your helm server to access file sync, instead of going to the AWS instance. Whereas Email traffic will still go to the AWS instance, and Helm tunnels the traffic over VPN back to your server.

Enough about the service, what about us geeks that have a real firewall, why is it not working for us? Well, it is important to understand where the helm server sits on your network and who is accessing the file sync service. In my case which I would think is the most common case the helm server sits on the same network as the clients. The firewall a Palo Alto Networks 220, in this case, is acting as the router, firewall, and DHCP server. So when the clients connect to the internet they traverse this firewall.

Where the problem lies is when the clients and the Helm server are on the same network. It appears that Helm has set up a DYN DNS style service so your server can update the Helm DNS record files.yourdomain.com with your public ISP IP address. This is great for clients that aren't on the same network or are coming from the internet. Where this breaks is for the clients on the same network as the Helm, when they go to the files.yourdomain.com they get NATed by the firewall and sent back inside to the Helm server. Because the Helm server is on the same network it will send the response directly back to the client from its private address. Because your client is expecting a response from the public address it initiated the connection to it will ignore the response from the server because it is coming from the Helm server's private address.

Don't worry this can be fixed,

It's called a U-Turn Nat and what it will do is perform 2 NATs on your internal client's traffic. The first NAT will be the destination NAT that is practically the same as the inbound NAT you will create. It looks at the traffics source interface and destination IP then performs a Destination NAT translating the traffic to the internal private address, and the more important second NAT the Source NAT. The Source NAT will translate the client's source address to the inside interface of the firewall. This will trick the Helm server into thinking the firewall was requesting the traffic and no the client forcing the traffic back to the firewall and then back to the client. This is the U-Turn part of the NAT.

Here are examples of how the NAT policies will look on the firewall. You must place the U-Turn NAT above the Inbound NAT because the U-Turn NAT is more specific.



The security policy can be a little tricky as well if you haven't configured rules for NATed servers before. When configuring firewall rules for NATed servers you need to configure the rule for the pre NATed address or Public address, but use the correct destination zone, in this case, the inside security zone.



Once all of that is set up you should be up and working with Helm's new file sync service.

Here are the Palo Alto Articles that talk to each of the configurations I made above.