[Firehol-support] First request via https is filtered out

Tsaousis, Costa costa at tsaousis.gr
Thu Mar 12 14:15:05 GMT 2015


Hi Bernhard,

I think this has nothing to do with firehol.
The logs you posted are

1. ACK+FIN packets which are signaling the connection has closed.
2. RST packets which are signaling the server that the client is
willing to restart the socket.

Both of the packets are dropped by FireHOL because the connection
tracker does not see them as part of an established connection.
ACK+FIN is normal, and should not alarm you (the connection tracker
cleared the entry already when this was received).
RST is a side effect of the problem you are facing. It will go away if
you solve the issue.

My guess is that you have an issue with your server.

Can you tcpdump the traffic to see what is happening?

You should see:

1. client->server SYN
2. server->client SYN ACK
3. client->server ACK

My guess is that step 2 is not performed by your server.

Costa



On Thu, Mar 12, 2015 at 3:08 PM, Bernhard J. M. Grün
<bernhard.gruen at gmail.com> wrote:
> Hi all,
>
> I have a strange behaviour for a https connection. The first connection is
> filtered out. This happens only if that IP wasn't active for some amount of
> time. If the IP makes a second connection try it succeeds and following
> connections from that IP succeed too. But if I wait some time (about 30
> minutes?) the first new connection fails again.
> The local IP of the machine is 192.168.151.1. The client connections come
> from 192.168.106.150 and .100.
> The server on 192.168.151.1 is an nginx reverse proxy. The client is a java
> http client. But I think that doesn't matter really.
>
> This is the output in syslog from FireHOL 2.0.1:
> 2015-03-12 13:10:09 gw kernel:[9017606.989276] IN-DMZ:IN=eth2 OUT=
> MAC=aa:00:00:bf:c2:3b:aa:00:00:37:16:55:08:00 SRC=192.168.106.100
> DST=192.168.151.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=53683 DF PROTO=TCP
> SPT=45014 DPT=443 WINDOW=623 RES=0x00 ACK FIN URGP=0
> 2015-03-12 13:10:09 gw kernel:[9017606.989386] OUT-DMZ:IN= OUT=eth2
> SRC=192.168.151.1 DST=192.168.106.100 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0
> DF PROTO=TCP SPT=443 DPT=45014 WINDOW=0 RES=0x00 RST URGP=0
>
>
> 2015-03-12 13:18:59 gw kernel:[9018136.955393] IN-DMZ:IN=eth2 OUT=
> MAC=aa:00:00:bf:c2:3b:aa:00:00:37:16:55:08:00 SRC=192.168.106.150
> DST=192.168.151.1 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=8446 DF PROTO=TCP
> SPT=55880 DPT=443 WINDOW=753 RES=0x00 ACK FIN URGP=0
> 2015-03-12 13:18:59 gw kernel:[9018136.955445] OUT-DMZ:IN= OUT=eth2
> SRC=192.168.151.1 DST=192.168.106.150 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0
> DF PROTO=TCP SPT=443 DPT=55880 WINDOW=0 RES=0x00 RST URGP=0
>
>
> And this is a (shortened) version of the firehol.conf file:
> version 6
>
> # application server HTTP
> ipv4 interface eth0 EXT_GW dst $EXT_GW
>         server          http                    accept
>         server          https                   accept
>         server          icmp                    accept
>         server          ssh                     accept
>
>         client          all                     accept
>
>
> # drop everything else on eth0
> interface eth0 EXT
>         policy                                  drop
>
> interface eth1 INT
>         policy                                  accept
>
> interface eth2 DMZ
>         policy                                  reject
>         server          http                    accept
>         server          https                   accept
>
>
> Do you have an idea how to solve that problem the right way? At the moment
> we start a new connection attempt if the first one fails. But this does not
> seem right.
>
> Thanks in advance for your input.
>
> Best regards,
>
> Bernhard J. M. Grün, Germany
> _______________________________________________
> Firehol-support mailing list
> Firehol-support at lists.firehol.org
> http://lists.firehol.org/mailman/listinfo/firehol-support



More information about the Firehol-support mailing list