a simple way is to define your package server as preferred server even if it is your core itself. For this server you define a network scope for which this server should be the preferred server. If you have only one server, put in your whole IP range.
Then you have to define read credentials which the client then uses to connect to the share. No need for null shares or domain users, just a user that has read access to the package share. You can set this up under "Distribution - Content Replication / Preferred servers".
I did set up my core server as a preferred server (though I seem to get wacky, inconsistent results with different pieces of landesk, eg. HII, software distribution, etc depending on whether I name the preferred/core server by short name, FQDN, or IP)
I ended up finding a sort-of solution, though one that is going to require I do a lot of extra work.
For the settings on the scheduled tasks from which I was pushing the software, it worked when I set it to "execute from share" rather than "download and execute". Works most of the time, but a lot of my packages are built using batch scripts etc that make the assumption that the installation media will be downloaded.
The easiest / shortest version around distributing to non-domained devices is this -- use HTTP shares.
UNC is a huge pain in regards to authentication (and even if you give the devices credentials to log on to the share, Windows may decide to go "No!" due to security policies & such) ... HTTP removes that pain.
Also, that avoids Null-session shares.
You would need to enable the BROWSE option on the share while the Core calculates the MD5 hashes of the files.
If you're using PPS'es (Preferred Package Servers), you actually can turn off BROWSE (as long as the directory structure & files exist), as the client will be requesting specific files anyway, and as long as they exist, you're golden.