i have a problem with ipchains. i have a masq'd connection that is
apparently letting unmasq'ed packets through when it shouldn't.
the setup is:
client ->ethernet->(eth1)masq box(ppp0)->isdn->ftp server
client is 192.168.0.200, masq eth1 is 192.168.0.197, ppp0 is
192.0.0.162 to 192.0.0.1, ftp server is 123.45.67.89. The dial-up link
is managed by diald.
routes:
when link down:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.0.0.1 0.0.0.0 255.255.255.255 UH 1 0 0 tap0
192.168.0.197 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
123.45.67.89 192.0.0.1 255.255.255.255 UGH 1 0 0 tap0
192.168.0.128 0.0.0.0 255.255.255.128 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
link up:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.197 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
123.45.67.89 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.128 0.0.0.0 255.255.255.128 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
ipchains rules (rather simple):
Chain input (policy ACCEPT: 4875500 packets, 219256946 bytes):
Chain forward (policy ACCEPT: 170 packets, 7430 bytes):
pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
13715 7544K MASQ all ------ 0xFF 0x00 ppp0 anywhere 123.45.67.89 n/a
0 0 DENY all ------ 0xFF 0x00 any 192.168.0.0/25 anywhere n/a
Chain output (policy ACCEPT: 3980066 packets, 2088563192 bytes):
pkts bytes target prot opt tosa tosx ifname mark outsize source destination ports
0 0 DENY all ------ 0xFF 0x00 ppp0 192.168.0.0/16 anywhere n/a
and of course ip_masq_ftp is loaded.
everything goes swimmingly... the client can ftp to 123.45.67.89
(which automatically makes diald bring up link and switch routes from
tap0 to ppp0) and the connection is MASQ'ed as it should be,
and it's been working grand for ages. until now, when the admins of
the remote end complained that they were seeing packets coming to
their machine with the original un-masq'ed IP address. (which they
don't like).
Here's a tcpdump showing the problem:
15:04:59.265285 eth1 < 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:04:59.265334 tap0 > 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:00.976984 eth1 < 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:00.977046 tap0 > 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:04.037058 eth1 < 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:04.037120 tap0 > 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:06.345819 if89 > 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15:05:06.345874 if89 > 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15:05:06.345914 if89 > 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15:05:10.137340 eth1 < 192.168.0.200.53659 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:10.137432 if89 > 192.0.0.162.61077 > 123.45.67.89.ftp: S 2811393431:2811393431(0) win 16384 <mss 512> [tos 0x10]
15:05:10.243703 eth1 < 192.168.0.200.53659 > 123.45.67.89.ftp: . 2811393432:2811393432(0) ack 503770780 win 16384 [tos 0x10]
15:05:10.243733 if89 > 192.0.0.162.61077 > 123.45.67.89.ftp: . 2811393432:2811393432(0) ack 503770780 win 16384 [tos 0x10]
15:05:10.386402 eth1 < 192.168.0.200.53659 > 123.45.67.89.ftp: P 0:15(15) ack 52 win 16384 [tos 0x10]
15:05:10.386434 if89 > 192.0.0.162.61077 > 123.45.67.89.ftp: P 0:15(15) ack 52 win 16384 [tos 0x10]
uhmmm... why? my initial thought is that there are some packets left
in tap0 (ie inside the diald process) which diald flushes once the
link comes up (as it is supposed to) but that *aren't* being MASQ'ed.
but why aren't they being MASQ'ed? Perhaps because they come from
diald, and then are considered local and don't traverse the forward
chain.. possible.
But then why aren't they caught and stopped and by the rule on the
output chain that specifically is there to catch these kind of
packets?
any ideas? Subtle config problem or kernel bug?
--paulj
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
