On Monday 21 June 2004 15:06, Jean-Francois Dive wrote: > > Does this make sense to anyone? > > not unless you explain us what's your setup, which host/ip does what in > your scenario... Sure thing - I put out the previous mail as an initial feeler to determine if this was the right place, since I can't seem to find any better place for the kernel-native IPSec stack.. OK, We have a pair of firewall/VPN boxen, which are both transparent bridges. Device br0 on both encompasses eth0 (WAN) and eth1 (LAN). Whilst I have to use some 'ebtables' magic to make this all work, the trace doesn't even complete successfully between the two firewall/VPN machines themselves. Without the 'ebtables magic', both sides WOULDbe able to reach each other, but the link wouldn't be encrypted (i.e. the packets go straight through the bridge rather than being routed)... fw-ws fw-mcc 194.200.209.0/24 == 194.200.209.247 <-> 213.2.4.61 == 213.2.4.32.0/27 I don't think the ebtables stuff is the cause of the problem because traceroutes fail even when the ebtables rules are flushed out. I've included the rules for completeness :) Old style (2.4.20): ebtables -t nat -A PREROUTING -i eth1 -p ipv4 --ip-dst 194.200.209.0/24 -j dnat --to-dst 00:40:63:C0:7C:6E --dnat-target ACCEPT New style (2.6.6): ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-dst 194.200.209.0/24 -j redirect --redirect-target DROP ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-dst 213.2.4.32/27 -j redirect --redirect-target DROP Cheers, Gavin. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
