Can't parse the destination address in an iis log

[relentless (Aaron Warner)]

I'm trying to start a what feels like simple parse of an iis log file. Initially I just stole an example grok filter from google and after puzzling over the parse errors for the a while decided to start fresh.
Its a default iis log.
I start the filter with %{TIMESTAMP_ISO8601:log_timestamp} and I can see this in logstash fine. Then the second part is the destination address which I use %{IPORHOST:site} and in logstash I see the error
failed to parse [site], caused by =>type illegal argument exception. invalid formation "10.20.30.100" is malformed at ".20.30.100"
Its really doing my head in, I've looked at the bunch of other examples and everyone else seems fine. Its like theres a config I'm missing that everyone else knows. This is using elk 5.0.0 btw.
config file is below

input {
beats {
port => 5044
type => "logs"
}
}
filter {
if [message] =~ "^#"{
drop {}
}
grok {
match => ["message", "%{TIMESTAMP_ISO8601:log_timestamp} %{IPORHOST:site}"]
}
}
output {
elasticsearch {
hosts => "localhost:9200"
user => xxxx
password => "xxxxxx"
manage_template => false
index => "%{[@metadata][beat]}-%{+YYYY.MM.dd}"
document_type => "%{[@metadata][type]}"
}
}

[warkolm (Mark Walkom)]

It'd help if you also provided a log sample.

[relentless (Aaron Warner)]

Ah yep sorry. Heres an example line
2016-10-27 02:00:46 10.20.30.100 POST /webservice.svc - 80 domain\user 10.20.30.101 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+InfoPath.3) http://hostname/folder/webpage.xap 200 0 0 257

I've run it through the grok debugger and can pull the data no problems.

[magnusbaeck (Magnus Bäck)]

This rather looks like an issue with the ES mappings. What are the mappings of your index? Specifically, what's the mapping of the site field?

[relentless (Aaron Warner)]

It does say I have a conflict for the site mapping. Though it could be because I've attempted so many different ways of doing the same thing have log entries with them now. I was able to get it to parse if I specifically used %{IPV4:site} rather than %{IPORHOST:site} but from what I can see in the default grok patterns its kinda of the same thing if its an ipv4 address.

I removed the offending indexes and have refreshed the fields which removed the conflict. So its just showing site as a string now.