0001423: Weird behavior with DNS and connection tracking in inline enforcement - PacketFence

Bug Tracking System

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001423

PacketFence

inline

public

2012-04-16 11:24

2012-10-24 09:58

Reporter

obilodeau

Assigned To

fgaudreault

Priority

low

Severity

minor

Reproducibility

random

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

Target Version

3.6.0

Fixed in Version

devel

Summary

0001423: Weird behavior with DNS and connection tracking in inline enforcement

Description

Sometimes DNS is still blackholed even if the mark on the inline node was removed. Looking at the firewall you see no reason why the DNS would be still handled that way but a pcap reveals that it actually still does. This happens for a couple of minutes and then DNS is NATed to the right destination properly again.

We think it's an UDP connection tracking issue and that clients that don't change their source port for every DNS query are more affected than others as they are in the conntrack table. An old CentOS 5.2 client exhibited that behavior while most other OS tested properly changed its source port (OSX, Windows, Fedora, Android, iOS). We had problems with OSX once but weren't able to reproduce reliably.

We are not really 100% sure it's related to connection tracking at this point since it worked fine on some lab servers but didn't on others and they are very similar (same OS but kernel version differs).

Since our latest tests showed it working on all the above mentionned OS, we are giving this a low priority but giving us solid reproducible cases will increase bug's priority. It is too random for us right now to sanely track.

What we think we'll do in the future is either disable or aggressively reduce the UDP tracking timers for DNS traffic (if that's even possible) or integrate with the conntrack-tools to kill any active conntrack session when a node is changed state. This requires an additional dependency (unpackaged in CentOS5 at this point) so it will need to be evaluated or bring enough value to warrant it.

Tags

No tags attached.

fixed in git revision

fixed in mtn revision

Attached Files

Relationships

related to

0001374

closed

dwuelfrath

Inline mode should work as VLAN mode regarding DNS blackholing

Notes
(0002649) obilodeau (reporter) 2012-04-17 10:56 edited on: 2012-04-17 10:58	For the record, connection tracking variables for UDP are located here: /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout* Turning these down to 0 and trying again with a client that re-uses source ports (like the CentOS 5.2 we tried) would be a good way to confirm or deny that the problem is connection tracking related after all. Unfortunately we know that it's not going to be an acceptable fix since we NAT through in inline enforcement and it would break UDP-based applications (like Skype).

(0003150) fgaudreault (viewer) 2012-10-19 12:08	Reminder sent to: fdurand Is this fixed with the ipset feature?

(0003164) fdurand (administrator) 2012-10-19 12:58	Yes this is fixed with ipset feature

(0003235) fgaudreault (viewer) 2012-10-24 09:58	Fixed with the ipset feature that will be released in 3.6.0.

Issue History
Date Modified	Username	Field	Change
2012-04-16 11:24	obilodeau	New Issue
2012-04-16 11:24	obilodeau	Relationship added	related to 0001374
2012-04-17 10:56	obilodeau	Note Added: 0002649
2012-04-17 10:58	obilodeau	Note Edited: 0002649
2012-10-19 12:07	fgaudreault	Target Version	=> investigate
2012-10-19 12:08	fgaudreault	Note Added: 0003150
2012-10-19 12:58	fdurand	Note Added: 0003164
2012-10-24 09:58	fgaudreault	Note Added: 0003235
2012-10-24 09:58	fgaudreault	Status	new => resolved
2012-10-24 09:58	fgaudreault	Fixed in Version	=> devel
2012-10-24 09:58	fgaudreault	Resolution	open => fixed
2012-10-24 09:58	fgaudreault	Assigned To	=> fgaudreault
2012-10-24 09:58	fgaudreault	Target Version	investigate => 3.6.0