Controlling Outbound Ports

Hi -

Is there some way, most likely via some utility, to control the outbound
ports that are used to make a TCP connection for testing? I would like to be
able to do something like "localhost 53200 -> www.somewebsite.com -> 80".

We are having a problem where only XP and 2003 machines from our network are
unable to access a particular website. Vista and Macs do not have the
problem. We have noticed that the latter 2 operating systems use much higher
ephemeral ports than XP or 2003, so we suspect that the outbound ports are
being blocked somewhere beyond our firewall, but we need something more
conclusive.

Thanks.

"Baboon" <(E-Mail Removed)> wrote in message
news:1E57805F-89F1-4CCB-8806-(E-Mail Removed)...
> Is there some way, most likely via some utility, to control the outbound
> ports that are used to make a TCP connection for testing? I would like to
> be
> able to do something like "localhost 53200 -> www.somewebsite.com -> 80".
>
> We are having a problem where only XP and 2003 machines from our network
> are
> unable to access a particular website. Vista and Macs do not have the
> problem. We have noticed that the latter 2 operating systems use much
> higher
> ephemeral ports than XP or 2003, so we suspect that the outbound ports are
> being blocked somewhere beyond our firewall, but we need something more
> conclusive.

If this is a website then the outbound port is 80 unless otherwise
specified.

The Client Source Port is a random number usually, but not always, between
2500-5000. The Client Source Port is established by the Client and not the
"target", and therefore if this port was the problem the Client machine
would not get to any site at all, you would not simply see this with only
certain sites.

Most likely there is something in the Code of the pages of the Site that
isn't reacting well with the Version of IE on the XP/2003 machines. If the
Site uses Java (Java Applets, not simply JavaScript) the the version of the
JRE could matter as well and the version of the JRE is probably different on
Vista and certainly different on the MAC.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Thanks for the reply.

I really am just looking for a utility that might possibly exist to
troubleshoot this, but here's more info, though it's kind of beside the point:

I was referring to the ports that the client uses to connect to port 80 on
the server. Those ports on Windows XP, 2003, 2000 are typically something
like the range you refer to. On OSX and Vista, they are more like in the
49000 range or greater. Run netstat on all of those OSes and you will see
what I mean. Most likely that is why we are only having problems on XP to
this one site, for what ever reason.

Yes of course the client sets up these ports and if the connection is
successful, it receives packets back from the web server on those same ports.
Possibly something along the path is blocking the return packets based on
the port range and our network address, we don't know.

This doesn't affect just IE, also Firefox. Most importantly, I sat at an XP
machine and tried to access the website but couldn't. I then made a VPN
connection to another network from the same machine and was able to connect
to the site. I also did the opposite; I connected from home to the website
successfully, then made a VPN connection to our network and couldn't access
the site.

This problem clearly happens only from our network and only from XP
machines. Since it appears the lower port range used by XP along with some
other factor is what's causing the problem, we are being asked to try and
make a connection to port 80 on their web server using a higher client port
than what is typically used on XP, in order to confirm that it is in fact the
lower port range that makes the difference. This is why I need a utility
that allows me to control the client ports that can be used, at least for
testing.


"Phillip Windell" wrote:

> "Baboon" <(E-Mail Removed)> wrote in message
> news:1E57805F-89F1-4CCB-8806-(E-Mail Removed)...
> > Is there some way, most likely via some utility, to control the outbound
> > ports that are used to make a TCP connection for testing? I would like to
> > be
> > able to do something like "localhost 53200 -> www.somewebsite.com -> 80".
> >
> > We are having a problem where only XP and 2003 machines from our network
> > are
> > unable to access a particular website. Vista and Macs do not have the
> > problem. We have noticed that the latter 2 operating systems use much
> > higher
> > ephemeral ports than XP or 2003, so we suspect that the outbound ports are
> > being blocked somewhere beyond our firewall, but we need something more
> > conclusive.
>
> If this is a website then the outbound port is 80 unless otherwise
> specified.
>
> The Client Source Port is a random number usually, but not always, between
> 2500-5000. The Client Source Port is established by the Client and not the
> "target", and therefore if this port was the problem the Client machine
> would not get to any site at all, you would not simply see this with only
> certain sites.
>
> Most likely there is something in the Code of the pages of the Site that
> isn't reacting well with the Version of IE on the XP/2003 machines. If the
> Site uses Java (Java Applets, not simply JavaScript) the the version of the
> JRE could matter as well and the version of the JRE is probably different on
> Vista and certainly different on the MAC.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

"Baboon" <(E-Mail Removed)> wrote in message
news:F332820E-8982-4AD2-AA8E-(E-Mail Removed)...
> 49000 range or greater. Run netstat on all of those OSes and you will see
> what I mean. Most likely that is why we are only having problems on XP to
> this one site, for what ever reason.

I know what they are. It is exactly what I was saying. There is absolutely
no relationship to any particular site and the Client Source ports no matter
what number they are or range they fall into. Either all sites will
work,..or all sites won't work, there is no middle ground.

> Yes of course the client sets up these ports and if the connection is
> successful, it receives packets back from the web server on those same
> ports.

Not "if successful",...the "successful" comes after the fact. The Client
Source Port is already being used within the process that makes it
successful.

> Possibly something along the path is blocking the return packets based on
> the port range and our network address, we don't know.

I really, really doubt that. You also need to keep in mind that the Source
Port you see with those Clients is *only* between them and the Firewall
Device. They are *not* repeated between the Firewall and the Web Server.
The Firewall creates a "fresh" Session between it and the Web Server, so the
Web Server *never* even sees those numbers from a lower range that you are
talking about. A packet sniffer will show you that. In fact the Web Server
may not even directly communicate with your Firewall since there is a good
chance that there is a Firewall in front of the Web Server that you don't
even know about.

> lower port range that makes the difference. This is why I need a utility
> that allows me to control the client ports that can be used, at least for
> testing.

I don't believe there is such a utility,..but I could be wrong. It is
irrelevant anyway, the Source Port from XP is only between it and the
Firewall, not between the Firewall and the Web Server.

What are you using for a Firewall Device? All modern firewalls are supposed
to monitor the connection state to dynamically adjust to the Source
Ports,..and in fact,..use the Source Ports on both the Client side and the
External firewall side to "identify" and "maintain" the Session. There is
one session between the Client and the Firewall (IP#/CP#) and another
session between the Firewall and the Web Server (another IP#/CP#). The
Firewall then records both of these sets of identifiers into a NAT Table to
maintain the Session "end-to-end" between the Client and the Web Server.

If your Firewall is blocking anything it will show that in the logs. If
there is nothing in the logs then it is not blocking it.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

You need to turn off "Friendly error Messages" in IE's settings,..and then
post the exact text of the error when it fails.

We need to look at other differences between those XP machines and the Vista
machine that have nothing to do with the Client Source Ports.

You need to closely examine your firewall logs.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Thanks again.

I work for an organization with a fairly large network (we have an entire
class B network to ourselves). Unfortunately, I don't get my hands on any
network equipment since I don't work for the Network Services branch of IT.
Rather, I am a Windows consultant.

I can tell you that although I am in the habit of referring to our
"firewall", it's really just an ACL on our internet router and we have public
IP addresses on the internal network, so no NAT. I believe that means the
connections are simply passing through to the Internet routers. But you may
be correct that the Web server at the other end is behind a firewall, so the
packets are probably being blocked somewhere on the way out.

I misspoke slightly when I said XP machines only, as this also affects
Windows 2000 and 2003 as well. We have tried machines that are not part of
our organization from our network via VPN and we can recreate the problem.
So it's not a configuration problem. It's not a browser problem, nor a Java
or other application problem. *If I telnet to port 80 on the web server from
XP, the connection also fails.* By now it seems you should be convinced that
the lower port theory is at least a plausible one.

I think you are probably correct that a utility with the capability I'm
looking for doesn't exist. My role is only to help prove the lower port
theory; the Network people are working on solving the problem. Although I
don't expect help with that, if someone comes up with an idea, then great.

When (if) this gets solved, I'll definitely post back here to let folks
know.

"Phillip Windell" wrote:

> "Phillip Windell" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
> You need to turn off "Friendly error Messages" in IE's settings,..and then
> post the exact text of the error when it fails.
>
> We need to look at other differences between those XP machines and the Vista
> machine that have nothing to do with the Client Source Ports.
>
> You need to closely examine your firewall logs.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>
>

Hello,

Thank you for using newsgroup!

From your post, I'd like to thanks Phillip Windell for his kindly
information sharing. You may use firewall for example ISA to control
outbound ports or use TCP/IP filtering.
309798: How to configure TCP/IP filtering in Windows 2000
http://support.microsoft.com/kb/309798/en-us

Thanks & Regards,

Ken Zhao

Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security <http://www.microsoft.com/security>
================================================== ==
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ==
This posting is provided "AS IS" with no warranties, and confers no rights.





--------------------
| Thread-Topic: Controlling Outbound Ports
| thread-index: AcgEQ5DrXLGxBPsYSpOGZbnN8WJCxQ==
| X-WBNR-Posting-Host: 207.46.193.207
| From: =?Utf-8?B?QmFib29u?= <(E-Mail Removed)>
| Subject: Controlling Outbound Ports
| Date: Mon, 1 Oct 2007 08:56:02 -0700
| Lines: 14
| Message-ID: <1E57805F-89F1-4CCB-8806-(E-Mail Removed)>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929
| Newsgroups: microsoft.public.windows.server.networking
| Path: TK2MSFTNGHUB02.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl
microsoft.public.windows.server.networking:7760
| NNTP-Posting-Host: tk2msftsbfm01.phx.gbl 10.40.244.148
| X-Tomcat-NG: microsoft.public.windows.server.networking
|
| Hi -
|
| Is there some way, most likely via some utility, to control the outbound
| ports that are used to make a TCP connection for testing? I would like
to be
| able to do something like "localhost 53200 -> www.somewebsite.com -> 80".
|
| We are having a problem where only XP and 2003 machines from our network
are
| unable to access a particular website. Vista and Macs do not have the
| problem. We have noticed that the latter 2 operating systems use much
higher
| ephemeral ports than XP or 2003, so we suspect that the outbound ports
are
| being blocked somewhere beyond our firewall, but we need something more
| conclusive.
|
| Thanks.
|

""Ken Zhao [MSFT]"" <v-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> From your post, I'd like to thanks Phillip Windell for his kindly
> information sharing. You may use firewall for example ISA to control
> outbound ports or use TCP/IP filtering.
> 309798: How to configure TCP/IP filtering in Windows 2000
> http://support.microsoft.com/kb/309798/en-us

Hi Ken,

It is actually Client Source Ports that we are dealing with. ISA and TCP
Filtering will have nothing to do with controlling those. Those are
"uncontrollable".

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

"Baboon" <(E-Mail Removed)> wrote in message
news:8B4945A2-610D-4F75-86A2-(E-Mail Removed)...

> I can tell you that although I am in the habit of referring to our
> "firewall", it's really just an ACL on our internet router and we have
> public
> IP addresses on the internal network, so no NAT.

Yes that would be the case. Actually Cisco in their material even refers
to a Router as a Broadcast Firewall even when there is no ACLs. So if you
run ACLs, then it is a NAT-less Firewall to me :-)

This wouldn't happen to be U of I in Illinois would it?

> I believe that means the
> connections are simply passing through to the Internet routers. But you
> may
> be correct that the Web server at the other end is behind a firewall, so
> the
> packets are probably being blocked somewhere on the way out.

That could be,...but I really don't think the Source Ports are the problem.

> I misspoke slightly when I said XP machines only, as this also affects
> Windows 2000 and 2003 as well. We have tried machines that are not part
> of
> our organization from our network via VPN and we can recreate the problem.
> So it's not a configuration problem. It's not a browser problem, nor a
> Java
> or other application problem. *If I telnet to port 80 on the web server
> from
> XP, the connection also fails.* By now it seems you should be convinced
> that
> the lower port theory is at least a plausible one.

It isn't impossible, but *extremely* unlikely. The source ports are
considered "response traffic" to an already initiated connection. The
initial connection port (typically 80 for web sites) is what the Rule
Processing is based on and is what the whole thing of being "statefull" is
all about and would apply to ACL seven if NAT wasn't used. Maybe the Router
you have running the ACLs has a flaw in its "statefullness" and is causing
the problem. You need to setup logging at that Router and see if it is
stopping anything. The Source Ports would never be the problem if a device
operates according to Standards,...but if the Device has a flaw in its
OS,..that's another story.

> I think you are probably correct that a utility with the capability I'm
> looking for doesn't exist. My role is only to help prove the lower port
> theory; the Network people are working on solving the problem. Although I
> don't expect help with that, if someone comes up with an idea, then great.

What exactly are these "problem" web sites? It would be nice to not work in
the dark. it would also be useful to know the IP range of the workstations
having the problem.

> When (if) this gets solved, I'll definitely post back here to let folks
> know.

Sounds good.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

No, not the Univ of Ill., but close. We are a major higher ed institution.

There is only one website that we know of that is causing us this problem,
and it's www.springerlink.com. I can't give out the IP address range of our
machines in a public forum such as this.

Being that we are so disjointed here in our IT department, I didn't know
that there is a proxy server on our network that can be used if desired. If
I use the proxy, I am able to connect to the web site from XP. I know
nothing about the platform of the proxy, but it is accessed by typing a URL
as such:
http://proxy.xxxxx.edu/login?url=htt.../home/main.mpx

So we have a workaround, but nobody has solved the problem yet.

At this point, I am not asking for help (though it certainly is welcomed),
but I figure I have your interest so I'm just keeping you informed in that
case.

Thanks.

"Phillip Windell" wrote:

>
> "Baboon" <(E-Mail Removed)> wrote in message
> news:8B4945A2-610D-4F75-86A2-(E-Mail Removed)...
>
> > I can tell you that although I am in the habit of referring to our
> > "firewall", it's really just an ACL on our internet router and we have
> > public
> > IP addresses on the internal network, so no NAT.
>
> Yes that would be the case. Actually Cisco in their material even refers
> to a Router as a Broadcast Firewall even when there is no ACLs. So if you
> run ACLs, then it is a NAT-less Firewall to me :-)
>
> This wouldn't happen to be U of I in Illinois would it?
>
> > I believe that means the
> > connections are simply passing through to the Internet routers. But you
> > may
> > be correct that the Web server at the other end is behind a firewall, so
> > the
> > packets are probably being blocked somewhere on the way out.
>
> That could be,...but I really don't think the Source Ports are the problem.
>
> > I misspoke slightly when I said XP machines only, as this also affects
> > Windows 2000 and 2003 as well. We have tried machines that are not part
> > of
> > our organization from our network via VPN and we can recreate the problem.
> > So it's not a configuration problem. It's not a browser problem, nor a
> > Java
> > or other application problem. *If I telnet to port 80 on the web server
> > from
> > XP, the connection also fails.* By now it seems you should be convinced
> > that
> > the lower port theory is at least a plausible one.
>
> It isn't impossible, but *extremely* unlikely. The source ports are
> considered "response traffic" to an already initiated connection. The
> initial connection port (typically 80 for web sites) is what the Rule
> Processing is based on and is what the whole thing of being "statefull" is
> all about and would apply to ACL seven if NAT wasn't used. Maybe the Router
> you have running the ACLs has a flaw in its "statefullness" and is causing
> the problem. You need to setup logging at that Router and see if it is
> stopping anything. The Source Ports would never be the problem if a device
> operates according to Standards,...but if the Device has a flaw in its
> OS,..that's another story.
>
> > I think you are probably correct that a utility with the capability I'm
> > looking for doesn't exist. My role is only to help prove the lower port
> > theory; the Network people are working on solving the problem. Although I
> > don't expect help with that, if someone comes up with an idea, then great.
>
> What exactly are these "problem" web sites? It would be nice to not work in
> the dark. it would also be useful to know the IP range of the workstations
> having the problem.
>
> > When (if) this gets solved, I'll definitely post back here to let folks
> > know.
>
> Sounds good.
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/downlo...7/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
>
> Microsoft ISA Server Partners: Partner Hardware Solutions
> http://www.microsoft.com/forefront/e...epartners.mspx
> -----------------------------------------------------
>
>
>