Re: DNS woes..

Hi Ace:

This message is written from a Win2K Pro PC, sitting behind a SOHO3
firewall which separates me from the corporate AD domain, fileservers,
exchange and every other Windows resource I use, such as My Documents
hosted on a central server, not my own HD.

I am able to log into the domain, which requires Kerberos. I don't
know enough about LDAP to know if it's used in this process; here is
my realtime netstat -na data (IP scheme edited):

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1037 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1043 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1044 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1176 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2189 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3439 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3441 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4488 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4562 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4888 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4892 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4895 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4899 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6515 0.0.0.0:0 LISTENING
TCP 172.16.128.2:139 0.0.0.0:0 LISTENING
TCP 172.16.128.2:4477 0.0.0.0:0 LISTENING
TCP 172.16.128.2:4477 192.168.128.80:139 ESTABLISHED
TCP 172.16.128.2:4488 192.168.4.63:445 ESTABLISHED
TCP 172.16.128.2:4562 192.168.128.71:445 ESTABLISHED
TCP 172.16.128.2:4888 192.168.128.44:1026 ESTABLISHED
TCP 172.16.128.2:4892 192.168.128.208:1417 ESTABLISHED
TCP 172.16.128.2:4895 192.168.128.44:1026 ESTABLISHED
TCP 172.16.128.2:4899 192.168.128.208:1417 ESTABLISHED
TCP 172.16.128.2:4901 192.168.128.52:139 TIME_WAIT
TCP 172.16.128.2:4905 192.168.128.52:135 TIME_WAIT
TCP 172.16.128.2:4906 192.168.128.52:1026 TIME_WAIT
TCP 172.16.128.2:4911 192.168.128.52:135 TIME_WAIT
TCP 172.16.128.2:4912 192.168.128.52:1026 TIME_WAIT
TCP 172.16.128.2:4914 192.168.128.52:389 TIME_WAIT
TCP 172.16.128.2:4915 192.168.128.52:389 TIME_WAIT
TCP 172.16.128.2:4916 192.168.128.52:445 TIME_WAIT
TCP 172.16.128.2:4921 192.168.128.52:389 TIME_WAIT
TCP 172.16.128.2:4923 192.168.128.52:389 TIME_WAIT
TCP 172.16.128..5:1146 0.0.0.0:0 LISTENING
TCP 172.16.128..5:2080 0.0.0.0:0 LISTENING
TCP 172.16.128..5:2428 0.0.0.0:0 LISTENING
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:1026 *:*
UDP 0.0.0.0:1042 *:*
UDP 0.0.0.0:1333 *:*
UDP 0.0.0.0:4889 *:*
UDP 0.0.0.0:4890 *:*
UDP 0.0.0.0:4896 *:*
UDP 0.0.0.0:4897 *:*
UDP 0.0.0.0:6514 *:*
UDP 0.0.0.0:6515 *:*
UDP 0.0.0.0:59152 *:*
UDP 127.0.0.1:4493 *:*
UDP 127.0.0.1:4652 *:*
UDP 127.0.0.1:4904 *:*
UDP 172.16.128.2:137 *:*
UDP 172.16.128.2:138 *:*


"Ace Fekay [MVP]" <PleaseSubstituteMyFirstName&LastNameHere@hotmail.com> wrote in message news:<ezLl9iXPDHA.1552@TK2MSFTNGP10.phx.gbl>...
> In news:363c6009.0306272142.190c7f6b@posting.google.com,
> wailakig <wailaki@batnet.com> posted his concerns then I replied down below:
> > Especially when you have PPPoE-type DSL, MTU issues are common.
> >
> > If continuous pings over VPN are OK, .... AND ...
> >
> > If the problem is with IPSec traffic being slow or failing to connect
> > on some parts of Windows networking with IPSec, esp outlook/exchange,
> >
> > sometimes enabling fragments on the SonicWALLs VPN-Summary screen can
> > help alot. And the separate fragments checkbox on the screen where
> > you set the WAN MTU.
> >
> > The exact same issues occur on non-VPN traffic through the box. Let's
> > ssay you have a Win2K AD LAN, and a workstations which is part of the
> > domain, logged in, etc. then you create a valid IP setup where that
> > workstation now sits using a different IP address, behind a
> > NAT-enabled SW. If you then log out of your domain, and have a very
> > slow time logging back into that domain, here is how you can work
> > around that:
> >
> > on Access - Rules, find the allow outbound rule:
> >
> > allow default (or 'any' in the new fw) from LAN to *
> > this applies to WAN and DMZ unless custom rules override it.
> >
> > edit the rule and enable fragments. Boom. Domain login in 4 seconds
> > again. I was able to try this experiment, by accident, using a second
> > PC and WAN HTTPS admin session. As the first PC slugged its way
> > through 'applying blah settings' messages, durings its 20 minute
> > bootup, it snapped into the domain as soon as the aforementioned rule
> > w/ support for fragments was saved.
> >
> > late -- JL
> >
>
>
> So JL,
>
> You're saying that you got LDAP and RPC to work across a Sonicwall NAT by
> enabling fragmentation?
>
> NAT cannot translate LDAP and Kerberos traffic.
>
> Curious, do you have references to any docs you can refer us to read up on
> why this works?
>
>
> --
> Regards,
> Ace
>
> Please direct all replies to the newsgroup so all can benefit.
>
> Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
> Microsoft Windows MVP - Active Directory