| Title: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server |
| Notice: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server |
| Moderator: | CPEEDY::KENNEDY |
| Created: | Fri Dec 18 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4319 |
| Total number of notes: | 18478 |
<<< NOTED::NOTES$9:[NOTES$LIBRARY]PWDOSWINV5.NOTE;2 >>>
-< PATHWORKS V5 for DOS and Windows >-
================================================================================
Note 7347.0 Firewalling NetBIOS-over-IP Problem 1 reply
GEC013::ZIGLER "Tom Zigler DTN 435-7979" 28 lines 4-MAR-1997 10:18
--------------------------------------------------------------------------------
We have Windows NT/95 clients on the inside of an AltaVista Digital
UNIX Firewall with a Windows NT V3.51 server and PATHWORKS for OpenVMS
V5.0A server both on the outside of the firewall. We are running the
TCP/IP protocol exclusively.
We defined a Start-of-Connection packet filter in the firewall that
enables a Windows NT/95 client to make an outbound initiated connection
to either server on port 139/TCP but permits only the corresponding
inbound connection as an ACKed response. In other words, a reverse
inbound initiated TCP connection from either server is not allowed by
the firewall.
The Windows NT/95 client can successfully connect to a share point
offered on the Windows NT server but NOT to the PATHWORKS OpenVMS
server.
A sniffer analysis of the Windows NT/95 to PATHWORKS NetBIOS-over-IP
attempted connection to port 139/TCP reveals that this server performs
a reverse inbound intiated connection back to the client - ugh!
Can anyone explain why this difference exists? Is there any way around
this problem?
Please advise.
\Thanks in Advance
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4196.1 | it's a license probe | CPEEDY::wells.lkg.dec.com::wells | Phil Wells | Thu Mar 13 1997 14:07 | 14 |
The PATHWORKS server (and the license server, but that's a different questions) probe the client for a license after the first protocol message (SmbNegProt). If the client doesn't have a license (or if the connect fails, etc.) then the PW License Registrar allocates a server based license. So, if the PW server had some server based licenses available, I think you would have been able to connect. Back connects are also to port 139 and to a fixed NetBIOS name. How intelligent is this filter? Phil | |||||