Opened 10 years ago

Last modified 4 years ago

#96 new defect

Wrong connection killed in logviewer

Reported by: Victor Julien Owned by: Victor Julien
Priority: major Milestone: undecided
Component: suite Version:
Keywords: Cc:

Description

As reported in the forum: https://sourceforge.net/forum/message.php?msg_id=7357448

I'm browsing the Logview, I press M and choose a connection: DROP 500->500(udp) 62.149.229.193 -> 84.222.xx.yy (me) that I want to block since it's several days that it's insisting to connect every few seconds. I press ENTER and choose "Add Source to Blocklist", but I get this error: Error: command '/usr/sbin/conntrack -D -s 84.222.xx.yy -d 210.206.16.94 -p udp --orig-port-src 38742 --orig-port-dst 42771' failed.

Please note that this wasn't the connection that I was viewing.. It's a P2P connection that was vanished. And this is always reproducible. I pick up a connection, try to block it and I get an error regarding another connection.. What happened?

Change History (1)

comment:1 Changed 4 years ago by Adi Kriegisch

with current master (pre v0.8rc2) the behaviour is as follows:

The IP is added to the blocklist, rules get reloaded and killing the connections leads to the message "Warning: all connections already gone, none killed." but all connections are killed.

vuurmuur-conf/src/conn_sec.c line 1422 int block_and_kill calls

vuurmuur-conf/src/conn_sec.c line 1342 int kill_connections_by_ip (two times: once with ip as source and once with ip as destination) that calls

vuurmuur-conf/src/conn_sec.c line 1225 int kill_connection that returns

  • -1 in case of proto not being tcp or udp
  • 0 on successful conntrack -D call and
  • 1 on unsuccessful conntrack -D invocation.

kill_connections_by_ip increases a 'failed' count in case kill_connection returns -1 and increases 'cnt' otherwise (even in case of conntrack failing to remove a connection). Only if 'cnt' remains 0, "all connections already gone, none killed." is the user facing message.

In my case, kill_connection logged one successfully killed connection to the audit.log, but obviously, 'cnt' wasn't increased.

Note: See TracTickets for help on using tickets.