Re: [netfilter-core] iptables redirect is broken on bridged setup
Denis Vlasenko wrote: Linux 2.6.12 Was running for months with this simple iptables rule: iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 9100 -j REDIRECT --to 9123 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) 00 REDIRECT tcp -- * * 172.17.6.44 172.16.42.201 tcp dpt:9100 redir ports 9123 But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. This doesn't look related to the nf_reset problem since it happens in PREROUTING and only the output hooks are defered. I suspect a configuration error, when there is no IP configured on a device the REDIRECT target can't be used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [netfilter-core] iptables redirect is broken on bridged setup
Denis Vlasenko wrote: Linux 2.6.12 Was running for months with this simple iptables rule: iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 9100 -j REDIRECT --to 9123 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) 00 REDIRECT tcp -- * * 172.17.6.44 172.16.42.201 tcp dpt:9100 redir ports 9123 But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. This doesn't look related to the nf_reset problem since it happens in PREROUTING and only the output hooks are defered. I suspect a configuration error, when there is no IP configured on a device the REDIRECT target can't be used. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iptables redirect is broken on bridged setup
On Fri, Jul 29, 2005 at 03:11:35PM +0300, Denis Vlasenko wrote: > Note that REDIRECT loads ip_conntrack, and this seem to > cause problems, see another bugzilla entry at > https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 REDIRECT is a for of DNAT, like you correctly state. DNAT _needs_ ip_conntrack, so that's not what is causing problems. Causing problems is probably the nf_reset() and other hacks that were put into the briding code to remove conntrack references once a packet enters the bridge (in order to make the 'fake iptables hooks' from the bridging code work). There were recently a number of fixes for this issue, which each caused new bugs. Could you please try with a current development kernel (linus' git tree, or davem's net-2.6.14 tree) and see if the problem persists? -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpT5xFPiJ24e.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
[removed a number of unneccessarry CC's from list] On Fri, Jul 29, 2005 at 12:11:52PM +0300, Denis Vlasenko wrote: > Linux 2.6.12 Denis, your bug is not getting fixed faster, no matter how often you will post it at how many places and to how many recipients. We have seen it, and we will look at it. bridging and netfilter/iptables is always a very tricky case, and the code was developed by separate groups who - as it is my impression - don't fully understand each others codebase too well. Also, many of the possible combinations of bridging and netfilter/iptables have apparently not been tested (or even used by anyone), so I'm not surprised that you see some unexpected behaviour. Also, the bridging/ebtables maintainer Bart de Schuymer is currently on holidays, as I understand. So please be patient. -- - Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed."-- Paul Vixie pgpyBlS3uLVpN.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
[removed a number of unneccessarry CC's from list] On Fri, Jul 29, 2005 at 12:11:52PM +0300, Denis Vlasenko wrote: Linux 2.6.12 Denis, your bug is not getting fixed faster, no matter how often you will post it at how many places and to how many recipients. We have seen it, and we will look at it. bridging and netfilter/iptables is always a very tricky case, and the code was developed by separate groups who - as it is my impression - don't fully understand each others codebase too well. Also, many of the possible combinations of bridging and netfilter/iptables have apparently not been tested (or even used by anyone), so I'm not surprised that you see some unexpected behaviour. Also, the bridging/ebtables maintainer Bart de Schuymer is currently on holidays, as I understand. So please be patient. -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpyBlS3uLVpN.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
On Fri, Jul 29, 2005 at 03:11:35PM +0300, Denis Vlasenko wrote: Note that REDIRECT loads ip_conntrack, and this seem to cause problems, see another bugzilla entry at https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 REDIRECT is a for of DNAT, like you correctly state. DNAT _needs_ ip_conntrack, so that's not what is causing problems. Causing problems is probably the nf_reset() and other hacks that were put into the briding code to remove conntrack references once a packet enters the bridge (in order to make the 'fake iptables hooks' from the bridging code work). There were recently a number of fixes for this issue, which each caused new bugs. Could you please try with a current development kernel (linus' git tree, or davem's net-2.6.14 tree) and see if the problem persists? -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie pgpT5xFPiJ24e.pgp Description: PGP signature
Re: iptables redirect is broken on bridged setup
On Friday 29 July 2005 22:37, David S. Miller wrote: > From: Denis Vlasenko <[EMAIL PROTECTED]> > Date: Fri, 29 Jul 2005 12:11:52 +0300 > > > Linux 2.6.12 > > > > Was running for months with this simple iptables rule: > ... > > But now I need to bridge together two eth cards in this machine, and > > suddenly redirect is no longer works. > > I think this is the regression we fixed up in 2.6.12.x, can > you try the latest 2.6.12.x stable release and see if it > clears up this behavioral change? Just tested. 2.6.12.3 does not have this bug. Thanks! -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iptables redirect is broken on bridged setup
From: Denis Vlasenko <[EMAIL PROTECTED]> Date: Fri, 29 Jul 2005 12:11:52 +0300 > Linux 2.6.12 > > Was running for months with this simple iptables rule: ... > But now I need to bridge together two eth cards in this machine, and > suddenly redirect is no longer works. I think this is the regression we fixed up in 2.6.12.x, can you try the latest 2.6.12.x stable release and see if it clears up this behavioral change? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iptables redirect is broken on bridged setup
On Friday 29 July 2005 14:23, Jan Engelhardt wrote: > > >iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport > >9100 -j REDIRECT --to 9123 > > > >Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) > > 00 REDIRECT tcp -- * * 172.17.6.44 > > 172.16.42.201 tcp dpt:9100 redir ports 9123 > > > >But now I need to bridge together two eth cards in this machine, and > >suddenly redirect is no longer works. > > I somehow have to say this is expected behavior. > > >tcpdump on real interface: > > > >10:44:37.964087 172.17.6.44.1385 > 172.16.42.201.9100: S > >4092145578:4092145578(0) win 65535 (DF) > >10:44:37.964365 172.17.0.1.9123 > 172.17.6.44.1385: S 520564491:520564491(0) > >ack 4092145579 win 5840 (DF) > > reply from wrong address! should be simulated as from 172.16.42.201 > > Not at all. The interface has more than one addresses, so it is free to > choose > which source address to use - Linux usually takes the first, unless you have > some routing rules in the route tables. > Your "ip a" output shows 17.0.1 as the first address. This is true for connectionless UDP, but not for TCP. For TCP, answer always comes from address where original SYN request was directed. > >10:44:37.964493 172.17.6.44.1385 > 172.17.0.1.9123: R > >4092145579:4092145579(0) win 0 > > peer didn't understand that > > This seems all normal to me, and looks like the port on 17.6.44 is just > closed. > > You also say that the [source or destination?] address should be 16.42.201, > but why? After all, you are using REDIRECT, not SNAT/DNAT. REDIRECT is a form of DNAT. You seem to misunderstand what is going on. 172.17.6.44 tries to connect to 172.16.42.201:9000 via TCP. Packets go thru this box, which acts as a router. REDIRECT causes this to be directed to local process listening on port 9123. Any reply packets from local process are NATed so that 172.17.6.44 sees "faked" src address of 172.16.42.201 and not my local one, 172.17.0.1. This works just fine on many of machines I have here. This worked just fine on the machine I have problem with. It had two IP addrs long before, and it worked. It stopped working only when I created a bridge and added the only active iface (ifi) to it. Basically, "reply packets from local process are NATed so that 172.17.6.44 sees faked src address" does not happen anymore. > >same packets on bridge interface: > > > >10:44:37.964087 172.17.6.44.1385 > 172.17.0.1.9123: S > >4092145578:4092145578(0) win 65535 (DF) > > looks like redirect was done before bridging - dst addr is already > > changed > > redirect, and in fact, the whole iptables-nat table, _is_ done before > bridging, see http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png BTW, I filed the bug into bugzilla: https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=365 Note that REDIRECT loads ip_conntrack, and this seem to cause problems, see another bugzilla entry at https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iptables redirect is broken on bridged setup
>iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport >9100 -j REDIRECT --to 9123 > >Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) > 00 REDIRECT tcp -- * * 172.17.6.44 > 172.16.42.201 tcp dpt:9100 redir ports 9123 > >But now I need to bridge together two eth cards in this machine, and >suddenly redirect is no longer works. I somehow have to say this is expected behavior. >tcpdump on real interface: > >10:44:37.964087 172.17.6.44.1385 > 172.16.42.201.9100: S >4092145578:4092145578(0) win 65535 (DF) >10:44:37.964365 172.17.0.1.9123 > 172.17.6.44.1385: S 520564491:520564491(0) >ack 4092145579 win 5840 (DF) > reply from wrong address! should be simulated as from 172.16.42.201 Not at all. The interface has more than one addresses, so it is free to choose which source address to use - Linux usually takes the first, unless you have some routing rules in the route tables. Your "ip a" output shows 17.0.1 as the first address. >10:44:37.964493 172.17.6.44.1385 > 172.17.0.1.9123: R 4092145579:4092145579(0) >win 0 > peer didn't understand that This seems all normal to me, and looks like the port on 17.6.44 is just closed. You also say that the [source or destination?] address should be 16.42.201, but why? After all, you are using REDIRECT, not SNAT/DNAT. >same packets on bridge interface: > >10:44:37.964087 172.17.6.44.1385 > 172.17.0.1.9123: S 4092145578:4092145578(0) >win 65535 (DF) > looks like redirect was done before bridging - dst addr is already > changed redirect, and in fact, the whole iptables-nat table, _is_ done before bridging, see http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
iptables redirect is broken on bridged setup
Linux 2.6.12 Was running for months with this simple iptables rule: iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 9100 -j REDIRECT --to 9123 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) 00 REDIRECT tcp -- * * 172.17.6.44 172.16.42.201 tcp dpt:9100 redir ports 9123 But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. tcpdump on real interface: 10:44:37.964087 172.17.6.44.1385 > 172.16.42.201.9100: S 4092145578:4092145578(0) win 65535 (DF) 10:44:37.964365 172.17.0.1.9123 > 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 (DF) reply from wrong address! should be simulated as from 172.16.42.201 10:44:37.964493 172.17.6.44.1385 > 172.17.0.1.9123: R 4092145579:4092145579(0) win 0 peer didn't understand that same packets on bridge interface: 10:44:37.964087 172.17.6.44.1385 > 172.17.0.1.9123: S 4092145578:4092145578(0) win 65535 (DF) looks like redirect was done before bridging - dst addr is already changed 10:44:37.964336 172.17.0.1.9123 > 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 (DF) 10:44:37.964493 172.17.6.44.1385 > 172.17.0.1.9123: R 4092145579:4092145579(0) win 0 If this a feature? If yes, how to work around it? # ip a 1: ifk: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:b3:9f:50:2a brd ff:ff:ff:ff:ff:ff 2: ifi: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:a0:c9:83:75:21 brd ff:ff:ff:ff:ff:ff 3: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 9: br: mtu 1500 qdisc noqueue link/ether 00:a0:c9:83:75:21 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global br inet 172.16.42.75/24 brd 172.16.42.255 scope global br # brctl show bridge name bridge id STP enabled interfaces br 8000.00a0c9837521 no ifi (yes, currently bridge contains only one iface...) kernel .config is below -- vda CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-r4" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=1 CONFIG_CC_ALIGN_LABELS=1 CONFIG_CC_ALIGN_LOOPS=1 CONFIG_CC_ALIGN_JUMPS=1 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_X86_PC=y CONFIG_M486=y CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_NAMES=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_EISA=y CONFIG_EISA_VLB_PRIMING=y CONFIG_EISA_PCI_EISA=y CONFIG_EISA_VIRTUAL_ROOT=y CONFIG_EISA_NAMES=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_COMPAQ=y CONFIG_HOTPLUG_PCI_CPCI=y CONFIG_HOTPLUG_PCI_CPCI_ZT5550=y CONFIG_HOTPLUG_PCI_CPCI_GENERIC=y CONFIG_BINFMT_ELF=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_PNPBIOS=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_XD=m CONFIG_PARIDE=m CONFIG_PARIDE_PARPORT=m CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_LBD=y CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y
iptables redirect is broken on bridged setup
Linux 2.6.12 Was running for months with this simple iptables rule: iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 9100 -j REDIRECT --to 9123 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) 00 REDIRECT tcp -- * * 172.17.6.44 172.16.42.201 tcp dpt:9100 redir ports 9123 But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. tcpdump on real interface: 10:44:37.964087 172.17.6.44.1385 172.16.42.201.9100: S 4092145578:4092145578(0) win 65535 mss 1460,nop,nop,sackOK (DF) 10:44:37.964365 172.17.0.1.9123 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 mss 1460,nop,nop,sackOK (DF) reply from wrong address! should be simulated as from 172.16.42.201 10:44:37.964493 172.17.6.44.1385 172.17.0.1.9123: R 4092145579:4092145579(0) win 0 peer didn't understand that same packets on bridge interface: 10:44:37.964087 172.17.6.44.1385 172.17.0.1.9123: S 4092145578:4092145578(0) win 65535 mss 1460,nop,nop,sackOK (DF) looks like redirect was done before bridging - dst addr is already changed 10:44:37.964336 172.17.0.1.9123 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 mss 1460,nop,nop,sackOK (DF) 10:44:37.964493 172.17.6.44.1385 172.17.0.1.9123: R 4092145579:4092145579(0) win 0 If this a feature? If yes, how to work around it? # ip a 1: ifk: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:b3:9f:50:2a brd ff:ff:ff:ff:ff:ff 2: ifi: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:a0:c9:83:75:21 brd ff:ff:ff:ff:ff:ff 3: lo: LOOPBACK,UP mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 9: br: BROADCAST,MULTICAST,UP mtu 1500 qdisc noqueue link/ether 00:a0:c9:83:75:21 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global br inet 172.16.42.75/24 brd 172.16.42.255 scope global br # brctl show bridge name bridge id STP enabled interfaces br 8000.00a0c9837521 no ifi (yes, currently bridge contains only one iface...) kernel .config is below -- vda CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-r4 CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=1 CONFIG_CC_ALIGN_LABELS=1 CONFIG_CC_ALIGN_LOOPS=1 CONFIG_CC_ALIGN_JUMPS=1 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_X86_PC=y CONFIG_M486=y CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_NAMES=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_EISA=y CONFIG_EISA_VLB_PRIMING=y CONFIG_EISA_PCI_EISA=y CONFIG_EISA_VIRTUAL_ROOT=y CONFIG_EISA_NAMES=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_COMPAQ=y CONFIG_HOTPLUG_PCI_CPCI=y CONFIG_HOTPLUG_PCI_CPCI_ZT5550=y CONFIG_HOTPLUG_PCI_CPCI_GENERIC=y CONFIG_BINFMT_ELF=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_PNPBIOS=y CONFIG_PNPACPI=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_XD=m CONFIG_PARIDE=m CONFIG_PARIDE_PARPORT=m CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_LBD=y CONFIG_CDROM_PKTCDVD=y
Re: iptables redirect is broken on bridged setup
iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 9100 -j REDIRECT --to 9123 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) 00 REDIRECT tcp -- * * 172.17.6.44 172.16.42.201 tcp dpt:9100 redir ports 9123 But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. I somehow have to say this is expected behavior. tcpdump on real interface: 10:44:37.964087 172.17.6.44.1385 172.16.42.201.9100: S 4092145578:4092145578(0) win 65535 mss 1460,nop,nop,sackOK (DF) 10:44:37.964365 172.17.0.1.9123 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 mss 1460,nop,nop,sackOK (DF) reply from wrong address! should be simulated as from 172.16.42.201 Not at all. The interface has more than one addresses, so it is free to choose which source address to use - Linux usually takes the first, unless you have some routing rules in the route tables. Your ip a output shows 17.0.1 as the first address. 10:44:37.964493 172.17.6.44.1385 172.17.0.1.9123: R 4092145579:4092145579(0) win 0 peer didn't understand that This seems all normal to me, and looks like the port on 17.6.44 is just closed. You also say that the [source or destination?] address should be 16.42.201, but why? After all, you are using REDIRECT, not SNAT/DNAT. same packets on bridge interface: 10:44:37.964087 172.17.6.44.1385 172.17.0.1.9123: S 4092145578:4092145578(0) win 65535 mss 1460,nop,nop,sackOK (DF) looks like redirect was done before bridging - dst addr is already changed redirect, and in fact, the whole iptables-nat table, _is_ done before bridging, see http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png Jan Engelhardt -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iptables redirect is broken on bridged setup
On Friday 29 July 2005 14:23, Jan Engelhardt wrote: iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport 9100 -j REDIRECT --to 9123 Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) 00 REDIRECT tcp -- * * 172.17.6.44 172.16.42.201 tcp dpt:9100 redir ports 9123 But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. I somehow have to say this is expected behavior. tcpdump on real interface: 10:44:37.964087 172.17.6.44.1385 172.16.42.201.9100: S 4092145578:4092145578(0) win 65535 mss 1460,nop,nop,sackOK (DF) 10:44:37.964365 172.17.0.1.9123 172.17.6.44.1385: S 520564491:520564491(0) ack 4092145579 win 5840 mss 1460,nop,nop,sackOK (DF) reply from wrong address! should be simulated as from 172.16.42.201 Not at all. The interface has more than one addresses, so it is free to choose which source address to use - Linux usually takes the first, unless you have some routing rules in the route tables. Your ip a output shows 17.0.1 as the first address. This is true for connectionless UDP, but not for TCP. For TCP, answer always comes from address where original SYN request was directed. 10:44:37.964493 172.17.6.44.1385 172.17.0.1.9123: R 4092145579:4092145579(0) win 0 peer didn't understand that This seems all normal to me, and looks like the port on 17.6.44 is just closed. You also say that the [source or destination?] address should be 16.42.201, but why? After all, you are using REDIRECT, not SNAT/DNAT. REDIRECT is a form of DNAT. You seem to misunderstand what is going on. 172.17.6.44 tries to connect to 172.16.42.201:9000 via TCP. Packets go thru this box, which acts as a router. REDIRECT causes this to be directed to local process listening on port 9123. Any reply packets from local process are NATed so that 172.17.6.44 sees faked src address of 172.16.42.201 and not my local one, 172.17.0.1. This works just fine on many of machines I have here. This worked just fine on the machine I have problem with. It had two IP addrs long before, and it worked. It stopped working only when I created a bridge and added the only active iface (ifi) to it. Basically, reply packets from local process are NATed so that 172.17.6.44 sees faked src address does not happen anymore. same packets on bridge interface: 10:44:37.964087 172.17.6.44.1385 172.17.0.1.9123: S 4092145578:4092145578(0) win 65535 mss 1460,nop,nop,sackOK (DF) looks like redirect was done before bridging - dst addr is already changed redirect, and in fact, the whole iptables-nat table, _is_ done before bridging, see http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png BTW, I filed the bug into bugzilla: https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=365 Note that REDIRECT loads ip_conntrack, and this seem to cause problems, see another bugzilla entry at https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=339 -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iptables redirect is broken on bridged setup
From: Denis Vlasenko [EMAIL PROTECTED] Date: Fri, 29 Jul 2005 12:11:52 +0300 Linux 2.6.12 Was running for months with this simple iptables rule: ... But now I need to bridge together two eth cards in this machine, and suddenly redirect is no longer works. I think this is the regression we fixed up in 2.6.12.x, can you try the latest 2.6.12.x stable release and see if it clears up this behavioral change? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
