Good question; it's the same one that came to my mind when presented with this situation. The likely answer is lack of planning, but poorly defined or changing requirements is a possibility. I'm not really sure; I wasn't involved in the planning or implementation of any of this. My initial suggestion was to get rid of NAT altogether which the network folks say isn't doable (probably that should read "easily doable", but I have few details about how this is designed).
Thanks for the mention of name resolution, I had overlooked that as a potential issue. Jeff On Mon, Mar 7, 2011 at 11:20 AM, Ben Scott <mailvor...@gmail.com> wrote: > On Mon, Mar 7, 2011 at 10:37 AM, Jeff Bunting <bunting.j...@gmail.com> > wrote: > > Having the problem described in KB article 301673 using SMB direct > hosting > > through a NAT device. > > Why in $DEITY's name are you running SMB across a NAT boundary? > > > The article suggests forcing SMB on NETBIOS over TCP to > > workaround this issue. Are there any known consequences of > > doing this? > > Well, you have to use NetBIOS, for starters. > > NetBIOS isn't particularly happy crossing NAT, either. You'll need > WINS for name resolution to work right. > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
