Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

[Bugs] Downed ipsec0 interface still responds to arp requests?

From: Dustin Trammell <DTrammell(at)penson.com>
Date: Wed Feb 19 2003 - 18:10:35 EST


Hello everyone,

I've found what may be a bug, however I can't definitely determine if the bug is caused by FreeS/WAN or the way the linux kernel handles the network drivers for the related interfaces. I'll describe the environment and issue and see if any of you have an idea as to what the source of the problem is. The test environment will take a moment to describe:

On the test network in question we have a test host, which is one end of the ipsec tunnel, and two nodes of a linux-ha firewall cluster (active/standby), which are the other end of the ipsec tunnel. The cluster is managed by heartbeat which brings up VIPs for the cluster on the active node and takes them down on the standby node, and ipsec is configured to use the VIP as it's endpoint on the cluster side.

The issue is when I fail the active cluster node, heartbeat relinquishes the VIP (ifconfig eth0:0 down), and it relinquishes the ipsec tunnel (ipsec setup stop), but the node (now considered the standby node) continues to respond to arp requests for the VIP. Apparently the ipsec0 interface is somehow responding (even though it is down), because if I change the line 'ifconfig $i down' to 'ifconfig $i 1.1.1.1 down' in _realsetup's killklips() function, the problem no longer occurs (effectively changing the address of the ipsec0 interface while it's down). As far as I understand, if the interface is down, it should not be talking on the network. I'm not sure exactly where this problem lies, whether it's something the ipsec code is doing or something the kernel is doing in relation to the network drivers.

Thanks in advance for any information you can provide. I currently have a working implementation using my address-change workaround described above, but I'm sure this issue may pop up and cause problems for others as well if it doesn't get fixed. If anyone can determine it to not be a problem with FreeS/WAN specifically, I'll figure out who next to talk to.

---
Dustin D. Trammell
Information Security Specialist
Penson Financial Services, Inc.


_______________________________________________
Bugs mailing list
Bugs@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/bugs
Received on Thu Feb 20 06:44:30 2003

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:30 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library