# HaProxy -\> Dovecot via ProxyProtocol: IPv4 address not parsed correctly

**URL:** <https://discourse.crowdsec.net/t/haproxy-dovecot-via-proxyprotocol-ipv4-address-not-parsed-correctly/1103>\
**Category:** Uncategorized\
**Created:** [January 13, 2023, 3:30pm UTC](https://discourse.crowdsec.net/t/haproxy-dovecot-via-proxyprotocol-ipv4-address-not-parsed-correctly/1103 "2023-01-13T15:30:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![astronaut](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/astronaut/32/509_2.png) [@astronaut](https://discourse.crowdsec.net/u/astronaut)\
**Post date:** [January 13, 2023, 3:30pm UTC](https://discourse.crowdsec.net/t/haproxy-dovecot-via-proxyprotocol-ipv4-address-not-parsed-correctly/1103/1 "2023-01-13T15:30:16Z")

</div>

Hi,

while testing dovecot-spam, I found out that in my setup, IPv6 addresses from which failed login attempts originate do get blocked, but IPv4 addresses don’t.

I have HAProxy set up as a reverse proxy. HAProxy forwards IMAP ports to Dovecot via [ProxyProtocol](https://www.haproxy.com/de/blog/haproxy/proxy-protocol/), so that the original IP address is transmitted to Dovecot (and not the IP address of the server proxy is running on). I don’t know if this is related to the behavior.

When an login attempt from an IPv4 address fails, Dovecot logs the following message:

> Jan 13 14:53:45 imap-login: Info: Disconnected (auth failed, 2 attempts in 4 secs): user=[xxx@xxx.xx](mailto:xxx@xxx.xx), method=PLAIN, rip=::ffff:xxx.xxx.xxx.xxx, lip=::ffff:xxx.xxx.xxx.xxx, TLS, session=

Via `cscli explain`, I found out that the parser wrongly detects the IP address

```auto
create evt.Meta.source_ip : ::ffff:xxx.xxx.xxx.xxx

```

which then subsequently gets banned, with no effect, presumably because `::ffff:xxx.xxx.xxx.xxx` isn’t a valid IPv4 address.

Has anybody observed a similar behavior? Is my interpretation correct? Any ideas how to adapt the parser to catch this behavior?

Thank you

---

<div class="post-metadata">

**Author:** ![astronaut](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/astronaut/32/509_2.png) [@astronaut](https://discourse.crowdsec.net/u/astronaut)\
**Post date:** [January 13, 2023, 3:51pm UTC](https://discourse.crowdsec.net/t/haproxy-dovecot-via-proxyprotocol-ipv4-address-not-parsed-correctly/1103/2 "2023-01-13T15:51:40Z")

</div>

Solved it (at least for me). In dovecot-logs.yaml, I changed the line

```auto
      pattern: "%{WORD:protocol}-login: %{DATA:dovecot_login_message}: user=<%{DATA:dovecot_user}>.*, rip=%{IP:dovecot_remote_ip}, lip=%{IP:dovecot_local_ip}"

```

to

```auto
      pattern: "%{WORD:protocol}-login: %{DATA:dovecot_login_message}: user=<%{DATA:dovecot_user}>.*, rip=??(::ffff:)%{IP:dovecot_remote_ip}, lip=%{IP:dovecot_local_ip}"

```

---

<div class="post-metadata">

**Author:** ![astronaut](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/astronaut/32/509_2.png) [@astronaut](https://discourse.crowdsec.net/u/astronaut)\
**Post date:** [January 13, 2023, 9:34pm UTC](https://discourse.crowdsec.net/t/haproxy-dovecot-via-proxyprotocol-ipv4-address-not-parsed-correctly/1103/3 "2023-01-13T21:34:27Z")

</div>

> [@astronaut](#):
>
> dovecot-logs.yaml

There it is again, this feeling of both being stupid and having learned something… The approach above breaks IPv6 detection. I think I have something better now:

```auto
pattern: "%{WORD:protocol}-login: %{DATA:dovecot_login_message}: user=<%{DATA:dovecot_user}>.*, rip=(::ffff:)?%{IP:dovecot_remote_ip}, lip=(::ffff:)?%{IP:dovecot_local_ip}"

```

Seems to be working. Fingers crossed.

---

<div class="post-metadata">

**Author:** ![iiAmLoz](https://dub1.discourse-cdn.com/flex013/user_avatar/discourse.crowdsec.net/iiamloz/32/386_2.png) [@iiAmLoz](https://discourse.crowdsec.net/u/iiAmLoz)\
**Post date:** [January 17, 2023, 9:32am UTC](https://discourse.crowdsec.net/t/haproxy-dovecot-via-proxyprotocol-ipv4-address-not-parsed-correctly/1103/4 "2023-01-17T09:32:52Z")

</div>

This was opened on github and issue is kind of resolved [here](https://github.com/crowdsecurity/hub/issues/634)
