On Wed, Aug 5, 2009 at 7:04 AM, Pascal Hambourg<pascal.mail@xxxxxxxxxxxxxxx> wrote: > > You don't see these packets in the 'nat' table because the "connection" > already exists and has an an entry in the conntrack table. You can delete a > conntrack entry with the conntrack command from the conntrack-tools package. > You can also prevent the packets to create a conntrack entry by using the > NOTRACK target in the 'raw' table until after you add the NAT rules. Make > sure to match packets in both directions. After you remove the NOTRACK > rules, the next packet will enter the 'nat' chains and hit the NAT rules. Thank you! That works perfectly. Both approaches are useful to me (as is doing NOTRACK and then waiting the 30 seconds for the conntrack entry to expire; installing conntrack-tools is a bit of a pain on these boxes.) I don't need to match packets in both directions, because there aren't any coming back -- I'm streaming MPEG data out and no response is desired or necessary. >> sysctl net.ipv4.ip_forward=1 # Dunno if this matters > > It doesn't matter. Packets are locally generated, the box does not act as a > router. Right. That's what I thought, but I tend to cargo-cult that line because it's usually the thing I forget when I'm bouncing packets around a network. >> (I'm testing this over a VPN, hence the tun0 device. Both $ORIG_DEST >> and $SPY are accessible via the VPN.) > > This matters a lot : for both $ORIG_DEST and $SPY, the actual next hop is > the VPN endpoint. Ok, that makes sense. 'ip' is only routing, not rewriting. -- 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
