Hello,
I mailed this a couple days ago to linux-net, no reply yet. so lets try
again.
I found a ipv4 masq issue/bug.
In normal conditions it isn't real issue but in my opinion need some
work.
This machine has isdn. With the isdn i use masq with the following rule:
/sbin/ipchains -A forward -s 192.168.0.0/255.255.0.0 -i ippp0 -d
0.0.0.0/0 -p all -j MASQ
this works fine, but if an connection is dropped, and reastablished with
in the masq timeouts, the connections can't be established, because when
i do a ipchains -F, then redail, the old masq entry is still not timed
out, and because of this the connection request is send out with the
wrong source ip address, it is masq but with the old ip. in my opinion
it should be flushed.
The following will be seen with tcpdump and ifconfig
First connection attempt:
ip address ippp0 : 212.127.195.55
ping started to www.xs4all.nl and works, tcpdump output ok:
00:32:11.598213 > 212.127.195.55 > 194.109.6.92: icmp: echo request
00:32:11.636254 < 194.109.6.92 > 212.127.195.55: icmp: echo reply
bringing link down: changing ip on ippp0 to 192.168.250.1, running
ipchains -F, ping still running
output of ipchains -M -L:
IP masquerading entries
prot expire source destination ports
ICMP 00:59.29 192.168.56.3 www.xs4all.nl 5391
(61089)-> 8
as you can see the ip masq entry is still there.
bringing up link again ip address : 212.127.195.25, ping still running
tcpdump output:
00:32:29.596224 > 212.127.195.55 > 194.109.6.92: icmp: echo request
00:32:30.596080 > 212.127.195.55 > 194.109.6.92: icmp: echo request
Ofcourse this is wrong but this ip masq entry will NEVER time out
because the kernel still things its valid.
ipchains -M -L output is still as above.
When i start a second ping, it works without problems ofcourse because
then a new masq entry is made.
Basicly there should be some way to flush the masq entries or make them
disappear after an interface changes ip.
I tried this both with the value of 0,1 and 2 in
/proc/sys/net/ipv4/ip_dynaddr.
I only tried this with icmp, but i assume this also applies to tcp/udp.
although with tcp the connection will be broken, but with udp/icmp you
can still get through and transfer data.
But you could trigger all kinds of intrusion detection on the dialin
side.
So i think this will qualify as a bug, but not a major one, this only
happens if time between dialout sessions is smaller then an ip masq
timeout. But it isn't very nice. But a possible chance to happen.
I hope i explained it aquerate enough. If not i can reproduce it. And
willing to tell more info if needed.
Please leave the CC in there. The linux-net is for archiving.
-- Met Vriendelijke groet/Yours Sincerely Stijn Jonker <S.J.C.Jonker@SJC.nl>Get my GPG/PGP key by sending me an email with "getkey" as subject. Key fingerprint: 9083 1B03 3699 F345 BE18 5987 1F43 FFA0 BB96 06B7
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:15 EST