Based on our analysis so far, we need to make some firewall changes.
Before we dive in, let's strategize.
Being SSH-based, only TCP port 22 needs to be allowed through the firewall.
The SFTP server is also the SSH server,
which means the client uses destination port 22 from inside to outside.
The solution should work fine across stateful firewalls and NAT devices too,
similar to classic FTP passive mode.
This will be a short clip,
as SFTP security from a network perspective is the easiest of all.
I'm currently logged into R3, the stateless firewall,
and the security policies are displayed.
From client to server, we permit TCP destination port 22,
which is the SSH well-known port.
We permit the return traffic by swapping the IP
addresses and using TCP source port 22.
Let's jump over to the SFTP client to test the policy.
I've written a security regression test script.
Let's check it out.
It's similar to the other SFTP scripts, with two minor changes.
First, I've disabled the debugging,
as we only care about whether the transfers succeed or not.
Next, I've added both put and get operations at the bottom,
testing bidirectional file transfer for completeness.
Let's execute the script.
Okay, no errors popped up, which is good.
Let's check the ACL match count on R3.
We see a handful of matches against our TCP 22 entries,
and no matches on our deny statement,
which suggests the network firewall didn't drop anything.
Just keep in mind that by permitting SFTP,
you are also permitting SSH,
so I suggest using specific ACLs that match source and destination IP addresses for additional policy control.