On 10/01/08 09:51, Marcio Veloso Antunes wrote:
I found out what is happening, it is exactly what you've said.
*nod*
The reason this occurs is related to conntrack, the specific route is
getting up after the first packet leaves the internal network (via
VPN interface, without masquerade), then when the specific route
enters, the connection has been established already.
That will do it.
Even when the interface changes from TUN0 to PPP0 the connection
persists and the packets keep NOT being re-verified.
'k
I don't know if it can be considered a Bug, but it seems to me an odd
situation as the interface have changed, other networks will be
crossed, i think the rules should be re-validated, don't you ?
I don't know if it is a bug per say or not. I would guess it has to do
with whether or not the connection tracking code in kernel is aware of
interface / network / route state changes or not. If it is unaware of
state changes then it is not possible for connection tracking to know
that something is amiss. If it is aware of state change then I would
think that it should trap for this and handle it more gracefully than it
did, thus a possible bug. But seeing as how I don't get that deep in to
kernel I can't say one way or the other.
root@fw:/proc/net# grep 172.18.0.13 ip_conntrack
udp 17 2809 src=172.18.0.13 dst=200.198.184.204 sport=5060
dport=5060 packets=977 bytes=537937 src=200.198.184.204
dst=172.18.0.13 sport=5060 dport=5060 packets=30 bytes=16384
[ASSURED] mark=0 use=1
Would it be possible to DROP the traffic before the VPN comes up such
that the connection would never be successfully established and then
allow the traffic once the VPN is up? Hopefully this would allow
connection tracking to track the traffic on the proper interface. Also,
make sure you use a DROP not a REJECT as you don't want to return an
error the the client application(s) thus causing them to give up rather
than timing out and re-trying like they would if the traffic was just
DROPed and lost in the ether.
Thanks for your help,
If you consider a direction to look with out an answer help, you are
welcome. ;)
Grant. . . .
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
