# Outbound Proxy settings

**URL:** <https://community.graylog.org/t/outbound-proxy-settings/906>\
**Category:** Graylog Add-ons\
**Created:** [April 24, 2017, 12:16pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906 "2017-04-24T12:16:28Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![SnazzyBootMan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/snazzybootman/32/8392_2.png) [@SnazzyBootMan](https://community.graylog.org/u/SnazzyBootMan)\
**Post date:** [April 24, 2017, 12:16pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/1 "2017-04-24T12:16:28Z")

</div>

So I have a few problems with the AWS Plugin and configuring an outbound proxy.

I have upgraded to GrayLog 2.2.3 (from 2.1.3) with AWS plugin 1.3.2 and have enabled the proxy setting in the configuration that read the server.conf file line http\_proxy\_uri.

After some figuring out of the actual URLs the AWS plugin is using and the permission required I seem to be connecting to the Kineses flowlog streams I created from the AWS Plugin documentation.

Now I can see in the server.log that the plugin is encountering a parse error when trying to ingest the flowlogs from an AWS ELB:

```
[27]: index [graylog_5], type [message], id [8e95caa1-28e6-11e7-a325-06831b6fd7b7], message [MapperParsingException[failed to parse [protocol]]; nested: NumberFormatException[For input string: "TCP"];]
[28]: index [graylog_5], type [message], id [8e95caa2-28e6-11e7-a325-06831b6fd7b7], message [MapperParsingException[failed to parse [protocol]]; nested: NumberFormatException[For input string: "ICMP"];]

```

I haven’t modified the ELB logging format so I would have expected the Plugin to be able to parse that data. Has anyone got an tips that might help resolve this issue?

---

<div class="post-metadata">

**Author:** ![jochen](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jochen/32/8_2.png) [@jochen](https://community.graylog.org/u/jochen)\
**Post date:** [April 24, 2017, 12:32pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/2 "2017-04-24T12:32:14Z")

</div>

You have to make sure that the `protocol` message field is always a string.

You can use a custom Elasticsearch index mapping for this purpose: [http://docs.graylog.org/en/2.2/pages/configuration/elasticsearch.html#custom-index-mappings](http://docs.graylog.org/en/2.2/pages/configuration/elasticsearch.html#custom-index-mappings)

---

<div class="post-metadata">

**Author:** ![SnazzyBootMan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/snazzybootman/32/8392_2.png) [@SnazzyBootMan](https://community.graylog.org/u/SnazzyBootMan)\
**Post date:** [April 24, 2017, 1:36pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/3 "2017-04-24T13:36:01Z")

</div>

Hi @jochen,

Thanks for that so “current write-active index is graylog\_5” and if I do this:

```
 {
  "template": "graylog_*",
  "mappings" : {
    "message" : {
       "properties" : {
        "protocol" : {
          "type" : "string"
        }
      }
    }
  }
}

curl -X PUT -d @'graylog-custom-mapping.json' 'http://localhost:9200/_template/graylog-custom-mapping?pretty'

```

So from the documentation that looks like it will only effect new indexes and not the current index. When I look at the mapping for ‘graylog\_5’ it has not changed so how to move forward?

---

<div class="post-metadata">

**Author:** ![jochen](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jochen/32/8_2.png) [@jochen](https://community.graylog.org/u/jochen)\
**Post date:** [April 24, 2017, 1:49pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/4 "2017-04-24T13:49:28Z")

</div>

> [@SnazzyBootMan](#):
>
> So from the documentation that looks like it will only effect new indexes and not the current index.

This is correct.

> [@SnazzyBootMan](#):
>
> When I look at the mapping for ‘graylog\_5’ it has not changed so how to move forward?

You can manually trigger an index rotation in the web interface on the System → Index Sets page.

---

<div class="post-metadata">

**Author:** ![SnazzyBootMan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/snazzybootman/32/8392_2.png) [@SnazzyBootMan](https://community.graylog.org/u/SnazzyBootMan)\
**Post date:** [April 24, 2017, 3:02pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/5 "2017-04-24T15:02:28Z")

</div>

Thanks @jochen - rolling the index did indeed pick up the new mapping plus some extra aws properties.

---

<div class="post-metadata">

**Author:** ![SnazzyBootMan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/snazzybootman/32/8392_2.png) [@SnazzyBootMan](https://community.graylog.org/u/SnazzyBootMan)\
**Post date:** [April 24, 2017, 3:10pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/6 "2017-04-24T15:10:28Z")

</div>

@jochen - just as an after thought do we have a way of finding out exactly which AWS permissions the plugin actually needs?

I have added some very permissive IAMs policies but would like to tighten them. I could do it the old fashioned way and reduce to nil then add them up as the log complains about them but…

---

<div class="post-metadata">

**Author:** ![jochen](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jochen/32/8_2.png) [@jochen](https://community.graylog.org/u/jochen)\
**Post date:** [April 24, 2017, 3:35pm UTC](https://community.graylog.org/t/outbound-proxy-settings/906/7 "2017-04-24T15:35:22Z")

</div>

The required IAM permissions are listed in the plugin’s README file:

> <https://github.com/Graylog2/graylog-plugin-aws/blob/1.3.2/README.md>

---

<div class="post-metadata">

**Author:** ![SnazzyBootMan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/snazzybootman/32/8392_2.png) [@SnazzyBootMan](https://community.graylog.org/u/SnazzyBootMan)\
**Post date:** [April 25, 2017, 9:55am UTC](https://community.graylog.org/t/outbound-proxy-settings/906/8 "2017-04-25T09:55:06Z")

</div>

Thanks @jochen - I hadn’t got that far down the guide.