Connecting WinLogBeat to ElasticSearch - if I ship to LogStash, I get weird index creation. If I ship directly to ES, the connection is refused

[apatton-cnet (ap)]

So I have ElasticSearch already ingesting syslogs from my Sophos-XG firewall. I have a separate logstash filter config for this input, and it all works correctly. The index name is sophos-xg-##-##-####

I wanted to start shipping windows events. I followed the default config of shipping directly to ES, but the connection gets refused. I can see the packets coming in using TCPDump, and I can see the port is open using netstat, and ES is running with no errors, and the firewall is allowing port 9200. Logstash is able to interface with ES over port 9200 without issue, but Logstash is running on the same machine, a Centos 7 box, and winlogbeat is obviously running on another local windows machine

If I configure WinLogBeat to ship via Logstash, i get a winlogbeat index and i get documents but I also get multiple indexes created under sophos-xg-##-##-#### where the date is what I am assuming are dates from event log entries. The indexes themselves appear to be blank.

I think i would prefer to ship via logstash for the future for flexibility but I would need to figure out why these additional sophos indexes are getting created.

I would also be happy short term just to be able to start using my windows event log data, so if I can get it shipping directly to ES that would be swell too. Just not sure what I am doing wrong.

logstash beats.conf:

    input {
      beats {
        port => 5044
      }
    }
    output {
      elasticsearch {
        hosts => ["http://localhost:9200"]
        index => "%{[@metadata][beat]}-%{[@metadata][version]}"
      }
    }

logstash sophos.conf:

    input {
      tcp {
        port => 6000
        type => syslog
      }
      udp {
        port => 6000
        type => syslog
      }
    }

    filter {
      ....stuff...
    }

    output {
      elasticsearch {
        hosts => ["localhost:9200"]
        index => "sophos_xg-%{+YYYY.MM.dd}"
      }
    }