You may need to look into things on the windows systems. From http://technet.microsoft.com/en-us/library/cc755604(WS.10).aspx
Because UDP is a connectionless protocol and has no sequence numbers or flags, it has no mechanism for terminating and closing a connection. Therefore, the timeout for UDP connections is much shorter than that for TCP connections. The timeout for established but inactive UDP connections is 60 seconds. In other words, if an established UDP connection is inactive for 60 seconds, the state table entry for that connection is removed from the NAT Mapping Table. This behavior applies to UDP connections on all ports. There are some exceptions to the 60-second timeout for UDP connections. When a computer sends a multicast or broadcast message, Windows Firewall waits for up to 3 seconds for a unicast response. In essence, the state table entry for multicast or broadcast connections is maintained for up to 3 seconds; if the multicast or broadcast connection is inactive for 3 seconds (that is, there is no response), then the state table entry is deleted from the NAT Mapping Table. Dynamic Host Configuration Protocol (DHCP) multicast messages are a special case and are exempt from the 3-second timeout. On Thu, Dec 2, 2010 at 23:47, Joe Gedeon <[email protected]> wrote: > It's actually the other way around. The agent will talk to the server > via udp 1514 from a high port. When the server needs to talk to the > agent it uses the same path. State Tables will normally keep this > connection open to pass. Example below. > > Agent_001:31128 -> Server:1514 Normal check keep alive traffic. > Server:1514 -> Agent_001:31128 Server to agent communication for > active response or etc/shared/<files> > > Think of it when you request a webpage: > > Client:29635 -> Webserver:80 Request > Webserver:80 -> Client:29635 Content requested from webserver. > > On Thu, Dec 2, 2010 at 23:41, dan (ddp) <[email protected]> wrote: >> The OSSEC communications protocol is 2 way. The server talks to the >> client from a random port to 1514, and the server responds to that >> port. >> Traffic to and from the agent to port 1514 on the manager should be allowed. >> >> On Thu, Dec 2, 2010 at 11:14 PM, Aaron Bliss <[email protected]> wrote: >>> Hi all >>> I've noticed that in several Windows' clients firewall logs that the >>> ossec server is attempting to connect to the client on random UDP >>> ports. The clients are firewalled which is why I noticed the dropped >>> packets. The source port is always UDP 1514, so this points to ossec >>> related traffic (ossec even reported the dropped packets on the >>> client, see below for a sample). Any idea why the ossec server would >>> be attempting to talk to the client on a random UDP port? On those >>> same clients, I've noticed as well that they don't always execute an >>> active response that should have been initiated by the ossec server. >>> ossec.log file on the client doesn't show any errors, ossec-execd >>> process is running and all other ossec functions and communication >>> between the agent and server seem to be working. Any ideas? Is there >>> are necessary firewall rule/port that needs to be opened on the client >>> side? >>> >>> Aaron >>> >>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - - >>> - - - RECEIVE >>> >>> Received From: (box1) >>> 10.0.0.2->\Windows\system32\logfiles\firewall\pfirewall.log >>> Rule: 4151 fired (level 10) -> "Multiple Firewall drop events from same >>> source." >>> Portion of the log(s): >>> >>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - - >>> - - - RECEIVE >>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - - >>> - - - RECEIVE >>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - - >>> - - - RECEIVE >>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 181 - - - - >>> - - - RECEIVE >>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 181 - - - - >>> - - - RECEIVE >>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 181 - - - - >>> - - - RECEIVE >>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 173 - - - - >>> - - - RECEIVE >>> >> > > > > -- > Registered Linux User # 379282 > -- Registered Linux User # 379282
