Re: UDP packets sent with wrong source address after routing change [AV#3431]

[Ed W <lists@wildgooses.com>]

>> An in-kernel "route changed" notification were great, because then we 
>> could delete all MASQUERAD-ed entries where --update-source-address 
>> flag is set.
>
> If we could register to receive routing changed events for SNAT source 
> addresses, that would be great (more efficient) but if the mechanism 
> does not yet exist, it would be much more difficult to create.
>
> I suppose that if we just deleted them all on any routing change, then 
> that would solve the immediate problem for us. It would be ideal if 
> incoming packets could still be directed to the correct internal 
> source, but dropping them is a smaller problem than continuing to send 
> out invalid packets and keeping a broken entry alive forever.

I'm probably completely missing the point, but:

- Route changes such as you describe will be triggered by some user 
space event.
- Lets generically call that "dhcpcd" for the sake of a label
- These userspace events should all be capable of some kind of "hook" on 
change
- This userspace hook can zap the relevant conntrack entries

The pros/conns seem to be that:
- one more piece of userspace to maintain
- but there is now integration between the userspace routing decisions 
and the decision to zap certain conntrack entries


For example in my situation I dynamically tweak ipsets and an IP 
dropping into an IPset causes routing decisions to be made for just that 
user. When we add a user to an ipset we also zap previous conntrack 
entries relating to that user.

I'm not sure that I can see any way for the kernel to know when it 
should adjust conntrack entries in my situation?


Cheers

Ed W