Your private node would still be a fully validating node (i.e. full node). That's a good thing.
As for having the private node connect to your public node, you have two choices:
-addnode=<ip>
Add a node to connect to and attempt to keep the connection open
-connect=<ip>
Connect only to the specified node(s)
What you were asking for is nr 2, but you might want to consider nr 1 instead because that gives your private node a bit more redundancy in case there's a problem with your public node (hardware problem, disk full, router misconfiguration...). But it will make a few outgoing connections to random internet nodes (slight security problem if you don't trust the bitcoin p2p protocol and it will cause a bit more bandwidth usage).
You might also consider these options:
-listen=0
Don't accept connections from outside (implied by -connect). (although if you don't port forward in your firewall, it doesn't matter.)
-whitebind=<addr>
Bind to given address and whitelist peers connecting to it. Use
[host]:port notation for IPv6
-whitelist=<netmask>
Whitelist peers connecting from the given netmask or IP address. Can be
specified multiple times. Whitelisted peers cannot be DoS banned and
their transactions are always relayed, even if they are already in the
mempool, useful e.g. for a gateway
upnp=0
to disable UPnP. If you're capable of doing your own firewall configuration, you don't want this increased attack surface. (This has/will become the default in recent versions.)
The whitelisting (4 and 5) will prevent your private node from accidentally banning your public node if something weird happens.
Public node configuration
You probably also want to have e.g. -whitelist=192.168.1.0/24
on your public node as well to never ban your private node.
If it's not running a wallet, use the option -disablewallet
[Do not load the wallet and disable wallet RPC calls]. Saves some resources and lowers the attack surface.