This needs to potentially occur outside the container if run without --privilege correct?

Ive bene trying to make this patch but have two issues. When adding using sudo the on_connect.sh fails as it needs a password

We trust you have received the usual lecture from the local System
 Administrator. It usually boils down to these three things:

     #1) Respect the privacy of others.
     #2) Think before you type.
     #3) With great power comes great responsibility.

 sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
 sudo: a password is required

and when trying to remove the sudo command (hey, im desperate LOL)

DNAT: Could not determine whether revision 2 is supported, assuming it is.
DNAT: Could not determine whether revision 2 is supported, assuming it is.
Fatal: can't open lock file /run/xtables.lock: Permission denied

Ive tried added --privileged to my docker-compose etc.

Any ideas, or better still, any way to get this pulled so it doesn't need an amateur like me hacking around!?

@917huB check the sudoers file that's included with the patch. Make sure that it's being applied as well with the correct permissions. It's set as is:
Defaults:nobody !requiretty
nobody ALL = NOPASSWD: /sbin/iptables

so as long as you're running /sbin/iptables as user nobody it shouldn't require a password. Even if you're not coming from a tty.

So either the sudoers isn't there or you're not running as nobody.

@doug-w thank you, it was an oversight on the permissions.

Traffic is now being passed from internet > Google Cloud VPS > on-premise hosted web server fine now. I am however unable to access the internet from the on-prem web server host through the VPS (curl ifconfig.co for example). I'm out of my depth here with iptables and would be grateful of any pointers that might accelerate my learning. Thanks again for your support.