rp_filter makes ipsec stop working after some time

Hi,

I'm posting this because I've found an in consistency in the way
rp_filter is handled while using ipsec. My current setup is a lenny
box with 4 NIC, 2 vlans and shorewall, this box is used as an ipsec
vpn server hosting around 12 ipsec tunnels distributed in two ISPs so
i have something like this: eth0(dhcp, but always get the same ip) ->
ISP1, eth1(static ip) -> ISP2, eth2(no ip) -> Currently unused,
eth3(static ip) -> Internal Network, vlanX@eth3(static ip) -> Internal
Wireless Network, vlanY@eth3(no ip) -> Currently unused. Now the
problem; when i start this box, having rp_filter active on every
interface as it's shorewall default I belive everything works fine,
but a few days later all the ipsec tunnels coming through the ISP2
stop working and i start seeing martians logged in my syslog. I ran
some tests while having the problem and this is what the results
where:

ping -I eth3 <remote internal ip>
I don't get any answer and do get the martians on the log.

tcpdump -n -i eth1 host <tunnel remote end-point>
I do see the ESP traffic coming and going normally.

tcpdump -n -i eth1 host <remote internal ip>
I do see the icmp-request and response to/from the remote ip.

this happened once before and since I was on a hurry I just restarted
the machine and everything went back to normal. Now that it happened
again I knew I had to do something, so after googling around for a
while I decided to disable rp_filter on eth1 and everything just
worked without doing anything else. According to the reply on this
post http://www.mail-archive.com/netdev@vger.kernel.org/msg58756.html
this is the intended behavior.

But if this is intended behavior I wonder the following:
- Why this happens after a while and not immediately ?
- Why I never get this problem on tunnels from ISP1 ?

Like I said it's working now, and I hope I never have this problem
again. But there is always that little thing some call curiosity.

Thanks in advance for any information you may have about this issue.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org