Folks,
I've recently upgraded our kerberos servers to RHEL 5. The four new
servers live in two data centers. Each pair behind a cisco firewall
context. Of course, I used IPTables to model what rules I needed in the
hardware firewalls. When we went production, I saw no reason to disable
the local firewalls even with the hardware firewalls in place.
That is...until iptables started getting things wrong.
The kerberos master, like all masters, uses kprop to propagate the
database to the slaves in a TCP connection. Kprop connections to the
kerberos slaves in the other data center would some times get stuck and
the slave would accept no new connections and the old connection would
not terminate. I would kill the child kpropd process on the slave and
things would work. At least until this happened again. (So not with
every connection.)
Turns out, well into the TCP session the kerberos master's iptables
firewall started rejecting ACKs sent from the slave. Depending on how
badly it rejected these packets it looks like a duplicate ACK/resend
storm could arise and basically hang the TCP session.
My iptables rules are fairly basic and fairly standard.
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
and the kprop is a connection initiated on the master to the slaves.
There are no rules on OUTPUT besides a general ACCEPT policy.
Why would iptables start rejecting packets for an established TCP
session? When I added a rule to explicitly allow traffic from a source
port of 754 (kpropd) the problem went away. I've checked my connection
tracking table and its no where near full.
This problem never occurred talking to the kerberos slave in the same
data center and behind the same cisco firewall. It only occurs when
the packets traverse the cisco firewalls. Can anyone shed some light on
what is happening here?
Jack Neely
--
Jack Neely <[email protected]>
Linux Czar, OIT Campus Linux Services
Office of Information Technology, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
