Firewall iss or Network issue or Server issue

Specifically, since NETBIOS isn't routable, I am guessing that when you try to make the connection via FQDN, netbios is being blocked at the layer 3 device. What have you got in the middle?

Either that, or it is a DNS zone issue.

If this is the case, you may have replication problems between sites. Check the FRS logs.

ChiefIT,
DNS seems to be fine.  This is a University.  DNS is done centrally.  The University helpdesk checked DNS and seemed to be fine.

There is QIP which does the public DNS and then there is Active Directory DNS.  

I did a NSlookup on the IP and on the FQDN and they all match....

both computers look at the same DNS server.  There are 3 DNS server actually...  I don't manage any of them.  

I can ping and telnet to all of the ports

\\FQDN  doesn't work or takes like 10 min to come up.

\\shortname works quickly...

Anything in the hosts file?

no..  just the standard loop back..  

let me ask.  when you just use the short name, does it just query Active Directory? NetBios?

and if you use the FQDN it goes to the dns server?

How many protocols do you have bound to the adaptor?

It spams the LAN with netbios. Fqdn goes to DNS.

netbios seems to work from a computer within the same network>>  
ip address doesn't work
fqdn doesn't work.

from a VPN tunnel, the IP address DOES work but short name doesn't (expected) and FQDN doesn't.

TCP/IP is bound and Client for MS Networks, File and Printer Sharing..  

When the tunnel is established, can you contact a useful DNS server? (this I have seen before)

when I do an IPconfig/all it pulls the same DNS servers that my clients do.

everything goes to 3 dns servers.  all clients University wide and all VPN tunnels.

Can you run an actual nslookup?

Yes, it first tries to query my ISP DNS, then it goes to the tunnel DNS and resolves.

That was not the answer I was expecting. Hmm. What type f VPN?

SSL VPN.   University system...   uses Juniper

one of the other admins here was thinking something in AD.  or on the NIC for the server itself.  

I am doubting it is the nic. I would be more likely to think it was the stack.
ssl VPN... Might be the ruleset for interesting traffic.

but doesn't explain the pc that is in the same network having the issue.

As there is a lot of guessing, I would take the time and effort to perform a network capture (e.g. with WireShark), to see what's wrong with normal FQDN queries.

Not sure how WireShark works.  I will look into it..  

I downloaded wireshark.  let me mess with it to capture some data..  

Capture filter (not display filter! It's defined in the settings for the network card capture dialog) should be set to
port 53 or port 135 or port 137
to be sure to capture all relevant data, and not to much other traffic.

how about relevant to the destination only?  I will connect to the VPN, then launch the software and try to connect to the server..???

That way you won't see what other IPs are involved in name resolution process.

new information

it seems to work now if you use the IP address.  if you use the FQDN it tries to login to the server using the credentials I am logged into the laptop with.  (this won't work)  it doesn't prompt me for a login box to type my credentials.

when I use the IP address, it prompts me within 5 seconds...

.

That would be windows making your life easier. Same domain names?

completely different..  

I am at a loss... Machine vpns in from outside subnet, connects. DNS resolves through the tunnel, and shortnames and fqdn don't work. IP address does. That sounds right?
Is it possible to connect with a different application via ip and fqdn?

there are no other applications on this server.  it is just a file server..  

so the summary is..  

On campus within the same firewall:
shortname works
FQDN works but takes 10 min for it to pop up.

Off campus through VPN:
Short name doesn't work
FQDN doesn't work
IP address works..

And from outside the network, VPN established, DNS resolves "hostname" to "ipaddress". If you take that ip address, and pop it into the run dialogue, \\ipaddress\c$, or whatever, it works, but \\hostname\c$ doesn't?. Is the machine nat'd accross the firewall? I could see what you are saying not working if the NAT is wrong, or if it resolves to the internal ip, but is nat'd to a different ip.

When I establish an IP address from the tunnel I do get another IP address from the tunnel range.
Your describing above is the case.  ipaddress works, hostname doesn't..  

The tunnel if firewall to firewall.  You still type in the public IP address of the server to access it.  Just need to have the tunnel active or it won't connect..   not that it does now..

we have other tunnels set up the same way and it works fine.    security team here on campus thought it maybe the server.  I don't see how.. I think it is their tunnel or something with the network routing..

The tunnel is firewall to firewall? You have a site-to-site VPN, then?

yes, site to site.

With split tunneling?

Yes

That doesn't make any sense. Have your network guys check their routing and rules. Have them verify them against other sites, if you have them.

That doesn't make any sense. Have your network guys check their routing and rules. Have them verify them against other sites, if you have them.

they said they have.  but who knows.  this is why I have been trying to troubleshoot myself..  some of the network guys are good, some are not..  

Speaking as a good network guy, with a 105 site wan, something isn't right...

ports to be aware of:

File sharing:
445/TCP SMB over TCP
137/TCP WINS/Netbios Broadcast ports
138/UDP Netbios datagram port
139/UDP Netbios datagram port (used for Netbios over SMB and Netbios over WINS)

Authentication through kerberose: (too many to list)
http://www.erdc.hpc.mil/hardSoft/Kerberos/ports

Remote procedure call:
135/TCP

DNS port:
53/TCP.

from the site  you can not contact the other try a port query to see if DNS is reachable from one site to another. However, It appears like a problem with authentication whenever you use a DNS connection. You may have a ONE-WAY trust relationship between one site and the other. OR, site DNS transfers are not working from one site to the other. This means the DNS records of one site are not on the other. So, when you query on the side that can't contact the remote site, the DNS host A records are not there and  your query goes to outside servers. Are these sites trusted sites of one another? Are the DNS zone transfers making it from one site to the other? These are questions you might ask yourself.

If Netbios works, ((//servername/share)), then DNS connections certainly work if not blocked or if it is trusted.

If not, you may look and see if your DNS port allows communications on the DNS port (of the site you can not contact)

Not sure if this will help..

here is a WireShark log from the time I typed in \\FQDN until it finally connected.  almost 10 minutes later...

sorry..  with the file in EXCEL
lefty.zip

Which ip is which?

You have a spanning tree loop going on. Only two retransmissions, though...

Nothing went on in that capture. From start to end no more than 4 seconds have passed. First packet is 440 seconds (0:07:20) after start of capture. Either the problematic packets are not send via that interface, or the capture filter was too restricitive.

the server we are trying to connect to is 136.142.142.216
the server the software is on is 136.142.142.217  (source)

sorry.

it was an open capture.  I can see everything in there...


7      10.023558      Cisco_8d:70:e9      Spanning-tree-(for-bridges)_00      STP      Conf. Root = 2239/00:d0:04:6a:80:00  Cost = 8  Port = 0x8029
8      10.118324      136.142.142.217      136.142.142.216      ICMP      Echo (ping) request
9      10.118428      136.142.142.216      136.142.142.217      ICMP      Echo (ping) reply
10      10.118559      136.142.142.217      136.142.142.216      TCP      4476 > microsoft-ds [SYN] Seq=0 Win=65535 Len=0 MSS=1460
11      10.118699      136.142.142.217      136.142.142.216      ICMP      Echo (ping) request
12      10.118879      136.142.142.216      136.142.142.217      TCP      microsoft-ds > 4476 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
13      10.118908      136.142.142.217      136.142.142.216      TCP      4476 > microsoft-ds [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
14      10.118978      136.142.142.216      136.142.142.217      ICMP      Echo (ping) reply
15      10.119083      136.142.142.217      136.142.142.216      SMB      Negotiate Protocol Request
16      10.11964      136.142.142.216      136.142.142.217      SMB      Negotiate Protocol Response
17      10.120343      136.142.142.217      136.142.142.216      SMB      Session Setup AndX Request, NTLMSSP_NEGOTIATE
18      10.120826      136.142.142.216      136.142.142.217      SMB      Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED
19      10.121157      136.142.142.217      136.142.142.216      SMB      Session Setup AndX Request, NTLMSSP_AUTH, User: \
20      10.122018      136.142.142.216      136.142.142.217      SMB      Session Setup AndX Response
21      10.122274      136.142.142.217      136.142.142.216      SMB      Tree Connect AndX Request, Path: \\OCD-DATA.OCD.PITT.EDU\IPC$
22      10.122777      136.142.142.216      136.142.142.217      SMB      Tree Connect AndX Response
23      10.123028      136.142.142.217      136.142.142.216      SMB      Trans2 Request, GET_DFS_REFERRAL, File: \ocd-data.ocd.pitt.edu\.
24      10.123202      136.142.142.216      136.142.142.217      SMB      Trans2 Response, GET_DFS_REFERRAL, Error: STATUS_NO_SUCH_DEVICE
25      10.123869      136.142.142.217      136.142.142.216      SMB      Session Setup AndX Request, NTLMSSP_NEGOTIATE
26      10.124193      136.142.142.216      136.142.142.217      SMB      Session Setup AndX Response, NTLMSSP_CHALLENGE, Error: STATUS_MORE_PROCESSING_REQUIRED
27      10.124424      136.142.142.217      136.142.142.216      SMB      Session Setup AndX Request, NTLMSSP_AUTH, User: OCD\Administrator
28      10.249701      136.142.142.216      136.142.142.217      TCP      microsoft-ds > 4476 [ACK] Seq=1298 Ack=1574 Win=65535 Len=0

right around line 521 is where it finally connects...

@qlemo: Scroll up.
@lefty431: You have my bet as to what is causing this. Even with only two retransmissions, I am guessing that you have 75 or 80 percent spanning tree in that capture.

so no ideas?

I am going to post the log from the VPN tunnel to the destination..  maybe that will help.. I am just going to past the stuff right in there..

Is there more than one path between the client and server?

meaning file share?

layer 2. That much spanning tree is a big problem.

what is the spanning tree?

It is a layer 2 protocol that breaks switching loops.

hmm..  is there a way to update the WireShark capture?  I tried zipping it and it wouldnt let me,  I figured it would be easier to read...

Not sure. Maybe just attach a new file?

here is the capture from the vpn tunnel.

at first it didn't work at all.   then I used the IP address and got a prompt....


leftyfromvpn.xls

Silly me :-(
 
 In the last capture are a lot of login errors for JIM-IPC\jim using NTLM. The last attempt works. This is really strange, as long as you did not re-enter your password ...

About Spanning Tree: Yes, I reckon this is a real problem here. Multicasts to check for STP are ok every now and then, but the captured stuff looks like a multilink not configured correctly (as Cisco is detecting loops). If loops are detected, packets might (will) be discarded silently, as they are expected to come on more than one network port. NetBIOS has to time out then to resend requests. Might fit here.
 

I didn't not enter anything, nor did I get prompted to.  Vista is trying to use the credentials that I am logged into the laptop with.

Conneting with NetBIOS works right away.

meaning if I click on \\netbios name it connects in about 2 seconds. (from a computer in the same filewall)  If I try to connect with that same computer using the \\FQDN it doesn't work.  IP address does work.

form the VPN tunnel it is a different story I suspect maybe related in some way.

from the tunnel I can get it to work with an IP address about 80% of the time.  using the FQDN it usually doesn't work and we all know the short name isn't going to work...

@qlemo: It's the only thing I can think of. I am guessing that with the tunnel established, there is some problem with vlan trunking, and it is trying to prune excessivly.

anything I can test on the server?  if I can't rule out the Univeristies equipment, I can rule out mine..  

Your server would have nothing to do with STP. It is a layer 2 protocol.

I would hand that packet cap to your cisco guy, and ask him to look into the spanning tree.

Cisco guy..   Now that's funny.....

:)
Well, who ever it is that is responsible for the cisco switches.

Can someone tell me what happens when you do

\\servername
vs.
\\servername.domainname.edu

?

http://articles.techrepublic.com.com/5100-10878_11-5034239.html
This explains netbios, and a bit of DNS. Shortnames are netbios, fqdn are dns.

After the server is identified, the actual data is moved via CIFS, which is an updated SMB.

so if there were a routing issue, how can I narrow down to DNS vs. Netbios?

It's not a routing issue. Not really. The issue, I suspect, is that STP is pruning too much. Are your vlans trunked?

good question..  I will find out.  they should be...

""so if there were a routing issue, how can I narrow down to DNS vs. Netbios?""

Use NSlookup to troubleshoot DNS issues. NSLookup is strictly a DNS troubleshooting utility.

Many folks don't realize this, but Ping is a multi-protocol troubleshooting utility.

Ping xxx.xxx.xxx.xxx can help troubleshoot ARP
Ping servername helps troubleshoot netbios
Ping servername.domainname helps troubleshoot DNS.

This is the same idea with UNC paths: (UNC stands for Universal Naming Convention for a reason)
//xxx.xxx.xxx.xxx/share is mapping by an IP
//servername/share is mapping by the netbios name
//servername.domain.name/share is mapping by DNS

Your current issue is with DNS: The FQDN doesn't work all the time. So, either your client's preferred DNS servers are not the School's DNS servers or you have a configured Host file on the client:
I wrote an article on how to simplify the troubleshooting of DNS for Experts Exchange:

The article is called "DNS TROUBLESHOOTING MADE EASY"
http://beta.experts-exchange.com/articles/Networking/Protocols/DNS/DNS-TROUBLESHOOTING-MADE-EASY.html

If you go to the articles section of EE, then you will be able to find and open the article.

1) Check your preferred DNS server list on the client:
2) Check your host file to make sure it is NOT configured with anything except the loopback address
3) Flush your DNS cache by going to the command prompt and typing IPconfig /flushDNS

Then, lets see if you have these issues with DNS.

Used NSlookup and everything resolved correctly.
able to Ping domain name and ip address.  resolves correctly.
flushed DNS on both servers and check the host file.

It seems to work a little better.  Still takes about 5 minutes for it to connect with an IP address for FQDN.  but short name works in seconds...

saw something on a blog about the NVidia network card drivers..  so looking into that, however I have no idea how to even troubleshoot a driver outside of just upgrading it.

the server does have 4 network ports in it so I configured one of the other ports on a different IP address with a different DNS name.

same thing. it connect.

yesturday I took the 3rd network port and configured it to a different VLAN.  from that vlan I tried to connect and it had the same issue.

from the server I am having problems with I tried to connect to a data server and it connected with FQDN, IP and short name within seconds.

so it seems to only be when connecting to THIS server.  

I have a rebuild scheduled on Friday but I want to rule EVERY thing else out.  

anything in the OS you know of I can check?  

I can't think of anything.

Going to upgrade to 2008 server.  See if that does anything.  Then rebuild.

Did it help?

Hello?

No nothing..  stil the same thing.. I even put a second computer in the same vlan as this and tried to connect to that and that doesn't work either.  The University doesn't want to admit there is an issue and they just point fingers back and forth at each other.

So, I was right, and it is a network problem.

I guess if your going for right and wrong.  yeah..  :-)

:)
You really shoudl find someone to look at those STP problems... There is a loop, and that is no good.

I think this has to do with the server's preferred DNS server.

Can you provide a IPconfig /all of the problem child server?

Also run a DCdiag /verbose and look for errors on that server. Further, look in event logs for DNS issues. Post any discrepancies with the IPconfig for us and we should be able to correct the issue.

Those two things would go a long way to troubleshooting this issue before a rebuild.

I will look into it tonight and see what I can come up with.  The University 3 DNS servers.  No one else is reporting an issue that I know of..

I will look and let you know..

Cisco looked at the network, microsoft looked at the server.  it is a network issues with spanning tree.  they are replacing the equipment this weekend.  thanks for all that helped.