TCP/IP Packet Filtering

[Jim Bohan]

I am trying to set up a cheap firewall on my web server which is a
win2k server machine. All I need to do is use IIS on port 80 and do
basic web surfing with IE6. So I used the TCP/IP Packet filtering
feature to PERMIT ONLY ports 80 and 53 (DNS) in both TCP and UDP.
After rebooting, I can serve up web pages via IIS but I can't surf via
IE6. I've done extensive research on this and looked up common port
defs and added PERMITS on ports 139, 137, 161, and 520. And added
PERMITS on IP Protocls 1 to 5, but still no luck.

I tried the exact same thing on a whole different network that happens
to be behind a cable/DSL router. The funny thing about that is I can
use ie6 to connect to a web server behind the router, but can't surf
on the general internet.

Any suggestions?

Thanks,

Thread7

 

[Joe Richards [MVP]]

The best way to learn what you did is to fire up a network sniffer and trace the
traffic on that machine when you go to surf. It should become fairly obvious
after a few glances at the trace.

You can use netmon from MS or go get Ethereal from www.ethereal.com.

 

[Jim Bohan]

Well I installed a network sniffer and this problem has become even
more of a mystery. I was almost sure that it had something to do with
UDP traffic because when I take off the PERMIT ONLY settings on UDP
but leave them on TCP and IP Protocol I can use IE6. But when I put
the PERMIT ONLY's back on UDP, my browsers (inclduing mozilla) don't
work again. They just time out.
So I figured the network sniffer would fine some port in UDP that I
needed to enable. But it didn't. When I successfully surf to a site,
there is absolutely no UDP traffic according to the sniffer - only TCP
traffic. (Remember I can surf on the internal network even with
PERMIT ONLY's set on UDP, but the general internet I cannot.) When I
can't connect to a site, there is absolutely no traffic whatsoever
according to the sniffer. It is like I didn't even have my browser
going. Arggh! I know there is an easy fix but I've tried it on
several different PC's/networks with the same results.

Thanks,

Thread7

 

[Joe Richards [MVP]]

Note that a network trace will show you all traffic even if the PC isn't using
it when you are using this type of filtering. It isn't like an external firewall
where the traffic will be blocked...

Another hint, look for DNS queries. Do you see responses. What does the machine
do with the response? Does it query again or does it go to that IP address?

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

 

[Steven L Umbach]

First when you are using dns to resolve and internet name you are using port 53 udp
"outbound" - not inbound. IP udp filtering is useless for using dns as you need to
configure the policy to allow the above 1024 ports for return traffic from the
external dns server to your computer which is not practical. For whatever reason IP
filtering on tcp knows when inbound traffic is from a response you initiated but it
does NOT for udp. I suggest that you leave just port 80 in your list for tcp and then
disable udp filtering and create an ipsec filtering policy instead through Local
Security Policy. Start with a mirrored block all IP policy for udp. Then add a
mirrored rule that permits traffic from your IP to any IP from any port to port 53
udp and you should be all set. By the way, opening port 139 tcp is a HUGE risk if you
have file and print sharing enabled on any computer. Ipsec policies take affect
almost immediately after being assigned or unassigned and do not require a
reboot. --- Steve

http://www.securityfocus.com/infocus/1559 --- about ipsec policies

 

[Joe Richards [MVP]]

Steve! I was walking him through the figure it out learning process man! Now you
gave him the fish.

Oh well.

joe

 

[Steven L Umbach]

So sorry Joe! [Steve hangs his head in shame] I guess the Holiday spirit overcame
me. Hopefully he still has learned.--- Steve

 

[Joe Richards [MVP]]

Yep, possibly this will promote learning anyway.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

So sorry Joe! [Steve hangs his head in shame] I guess the Holiday spirit overcame
me. Hopefully he still has learned.--- Steve

Steve! I was walking him through the figure it out learning process man! Now you
gave him the fish.

Oh well.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net



udp

to

IP

it

then

53

you

 

[Jim Bohan]

Joe,

Well he gave me the fish, but I did learn. I could find no
documentation telling me Steve's statement - "IP udp filtering is
useless for using dns as you need to configure the policy to allow the
above 1024 ports for return traffic from the external dns server to
your computer which is not practical." After hours trying to figure
out why the UDP traffic wasn't coming through I was at a dead end and
finally had to ask some "experts" such as yourselves. Great response
guys.

Thread7

 

[Steven L Umbach]

Hi Jim.

FYI. I have pasted a capture from Ethereal so you can see the sequence that
caused you grief. I modified the output screen to show unresolved source and
destination ports . I am not sure how good it will look in a paste but here
goes. This is an example on a capture just before I opened my web browser
which has a home page of Foxnews.com and my internal lan IP address is
192.168.1.105. Notice my computer using a source port of 3513 to a
destination port of 53 and the response of the dns server from port 53 back
to port 3513. It would be the port 3513 udp in this example that would be
blocked by the udp port filtering. Keep in mind that W2K dns client caches
recent dns queries including failures. So if you do any testing in the
future, always use the command " ipconfig /flushdns" to clear the dns client
cache first. --- Steve


Source Destination Protocol Src port Dst
port Info
192.168.1.105 202.12.27.33 DNS 3513 53
Standard query A www.foxnews.com

202.12.27.33 192.168.1.105 DNS 53 3513
Standard query response

 

[Joe Richards [MVP]]

First off note that UDP is connectionless. It is all fire and forget. No stream
as it were for the firewall to maintain state on.

Second... You would think everything was fine by looking at that part of the
trace unless you realized that the filter was making it so the OS didn't respond
to the 3513 inbound...

What you will notice is that even though a positive response came back, the
machine would ask a couple of more times for that address to be resolved and
depending on your configuration would start to broadcast or ask WINS for help.

Basically it would look like it was ignoring the IP address that the name was
being resolved to and that is EXACTLY what is happening.

joe