[ previous ] [ next ] [ threads ]
 From:  KnightMB <knightmb at knightmb dot dyndns dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] FW: m0n0wall blocks incoming UDP 500
 Date:  Wed, 15 Mar 2006 08:56:52 -0600
The test involved two computers.  One located on the LAN in my office, 
the other computer located on the LAN of another location/office using a 
different ISP.

I used VNC to control the off site office computer, and I used my own 
workstations in my office to conduct the test.  First, I started with a 
simple port tool.  Basically, the port tool could listen on any port 
number (that was available) and using the same tool on another computer, 
you can connect to that port and do a simple text only data exchange 
(like a simple IM conversation).  The port tool works for both TCP/UDP, 
a great way to test a port connection between two computers.

I first killed the lsass.exe process on my workstation so I could grab 
port 500 UDP and have the port tool start listening on that port.  I had 
m0n0wall do a map of port 500 directly to my machine and a firewall rule 
to allow all UDP/TCP connections through.  I then took control of the 
off site office computer and used the port tool to try and connect to my 
WAN IP, which redirected back into my PC where is has the same port tool 
listening on port 500 UDP for data.  The off site computer was able to 
make a connection but no data could be exchanged, so I switched the 
tools to port 501 UDP, when into m0n0wall and changed the port mapping 
to port 501 now.  Tried the experiment again and got connected with no 
problems on port 501 UDP.  I was able to send simple text back and forth 
between the two computers, so 2 way data communication on port 501 UDP 
worked just fine.  I then switched back to port 500 and again, no data 
could pass.  I could establish a connection (according to the port 
tool), but when trying to send data (like hi, hello messages), they 
disappeared into the void, never came out on the other end.  I then 
switched the port tool to listen on port 500 TCP this time.  I had the 
off site computer try to connect to the same port 500, but this time TCP 
data stream.  The connection was a success and simple text messages back 
and forth verified that data could flow in both directions.  I then 
tried ports 502, 503, 504, 505 UDP to just see if maybe it was just my 
computer.  But every time, anything other than port 500 worked just fine 
in the test.  I then decided maybe my computer was the cause of the 
problem, so I used the port tool over my LAN and UDP 500 connections 
from one computer to another on the same LAN worked just fine.

I didn't have any trace or packet sniffing going.  Mainly, was just 
doing a quick experiment so I could say "mine works just fine", but 
turns out it didn't, LOL.  I wanted to do a more real world test of data 
exchange using programs and computers to get a quick yes or no if mine 
worked inbound on port 500 UDP.  So far, it's the only port I've seen 
that does this.  Granted, I didn't test all 65535 ports because I just 
don't have the time, hehe.  I don't have any spare m0n0wall boxes that I 
can do a good test on since the other one is in production and didn't 
want to mess with all the office traffic to test this beyond the simple 
port testing for two way data exchange.

Maybe the ISP was blocking it or maybe their ISP was blocking it, but my 
ISP doesn't have any block rules and the other one is just as open on 
port usages as well. It is strange that I have the same port 500 UDP 
behavior problem that he is also experiencing.


Manuel Kasper wrote:
> Could you post more details on how you conducted this test? Did
> you/could you use a packet sniffer to check which UDP packets
> actually appeared at m0n0wall's LAN and WAN interfaces (and provide
> us with trace files)?
> I've tried to reproduce this problem - without success. Result: UDP
> communication from/to port 500 worked fine between two machines on
> the WAN and LAN interfaces of a 1.21 m0n0wall in the default
> configuration - both outbound and (after adding an inbound NAT rule +
> firewall rule of course) inbound, and bidirectional in each case.
> - Manuel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch