Scott Bronson a écrit : > On Sat, Dec 5, 2015 at 2:31 AM, Pascal Hambourg <pascal@xxxxxxxxxxxxxxx> wrote: >> IIUC, you're looping back traffic on a bridge interface. > > That sounds right. The packet arrives on virbr0, and I want to send it > right back where it came from. > >> Bridge-nf is >> enabled by default and can cause weird behaviour with NAT. Try to >> disable it : >> >> echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables >> >> Without that, after DNAT, the packet is not routed but bridged. But I >> suspect that the bridge code won't forward it back to its original port >> due to its source MAC address. > > It still times out. You must also MASQUERADE or SNAT these packets, otherwise the reply packets won't be sent back to the host and be de-NATed properly. AFAICS, your current ruleset avoids doing it : > -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 > -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 > -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE > Is it worth installing the logging to see if the > packet is still disappearing at the DNAT step? Sure. Or at least do a packet capture on the interface. > Maybe I can DNAT the source MAC too? :) I guess you may SNAT the source MAC address. It might do the trick -- 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
