I think you are doing good the commands... but the sslstrip technique doesn't depend only on your side. It depends of a lot of factors... if the "victim" is using bookmarks using always
https://whateverpage there is nothing to do. He/she is going to ask directly always for an encrypted page.
If the "victim" is asking for pages using
whateverpage.com without putting before https, he is going to ask for the http page. Even if the site has HSTS activated (which is going to receive the http request and will redirect it to https page version), you can do sslstrip because there is a request for an http page... only one, but enough for sslstrip. It is going to show the page in plain to the "victim" and it will do the ssl connection to the real site.
So many people say "HSTS is the solution to sslstrip". And this is NOT TRUE. I did sslstrip a lot of times testing access to pages with HSTS and it works... they key as I said is the victim must do the http (without "s") initial request.
Another decisive factor is that not everypage can be sslstripped if you use common browsers... I mean, if you use Chrome, Firefox or Internet Explorer for example... these browsers have an internal list of known ssl sites. That sites (like twitter or facebook for example) will never be sslstripped because the browser knows that ALWAYS must look for them using https even if the user did the "bad way request" putting
facebook.com without specifying the https:// before. I guess these sites pay to the browser's companies to be in that list.
I suggest to you try against not very known ssl pages because in that way there are less possibilities to crash in your tests against a site which is in that browser internal lists.
There are more advanced techniques to do sslstrip even to pages in that lists... like Delorean attack, etc... but are more complicated.