On Thu, Feb 07, 2002 at 04:04:28PM -0800, Eric Low wrote:
> Lennert, it looks like the DNAT'ing still does not work. You're correct, I > intentionally did not assign an IP address to either interface on the bridge. > So I added a static ARP entry with the line, > > ip neigh add 198.122.149.10 lladdr 00:08:C7:52:5D:A7 dev eth0 > > and this entry does show up (in fact, it's the only thing that shows up) in > /proc/net/arp. Once the packet hits the DNAT rule in the PREROUTING chain, it > seems to be lost. It never hits either the FORWARD or the POSTROUTING chains > (I tried logging all packets at the beginning of those chains with the same > source address as the DNAT'd packet in the PREROUTING chain). > > Just for the heck of it, after I added the static ARP entry, I also tried > adding a route (ip route add 198.122.149.10 dev eth0), which I did not have > before (since ip forwarding is disabled, of course). As soon as it received > the packet to be DNAT'd, I immediately got a kernel panic error and had to > restart the system. I also tried adding this ip route without the static ARP > entry in place, and got another kernel panic error. > > This DNAT'ing is not important enough to me to assign an IP address to the > bridge's interface, but I could certainly try it for troubleshooting purposes > if you'd like. OK, finally had some time to look at this, and I see why this is happening now. As Bart noted, the reason is that you have IP forwarding disabled, but what's really going on inside is quite subtle. The problem is in br_nf_pre_routing_finish, the bit of code that is run after the POSTROUTING chain has been traversed. Doing DNAT with bridging necessitates doing some fixups such as changing the destination MAC address, perhaps route the packet to a different device, etc. There are two cases: #1 The packet was DNAT'ed to a different ethernet device in the same bridge port group. We can still bridge the packet. #2 The packet was DNAT'ed to an ethernet device not in the same bridge port group (either a separate device, or another bridge port group). The packet will have to be routed. To cover these cases, two tests are needed. 1. If the function ip_route_input returns success, it means that #2 was the case, and we have to overwrite the destination ethernet address with our own address and pass the packet up the stack to have it routed. 2. If not, #1 was the case. We call ip_route_output to attach a needed dst_entry structure to the packet and we send the packet out. The calls to ip_route_input can fail, for example if we have no route to the new IP address, and thus cannot determine where the packet should be going to. When I wrote the code in question, I wasn't totally sure whether I had covered all possible cases, so I added a paranoia check. If ip_route_input fails, the packet is supposed to be destined to the same bridge port group as it came from, so I added an assertion that checked whether the route that ip_route_output returns does in fact go out over the same bridge interface. If not, it will intentionally crash your kernel. What I did not consider was the case where IP forwarding is disabled. In that case, ip_route_input will fail, not for the reason that the new destination IP address is in the same bridge port group, but for the reason because the IP stack notices that this packet would have to be forwarded, and it refuses to do so. I'm not totally sure what the best way is, but I guess I should turn the 'crash now' into a 'drop packet and write a message to the system log'. Ideas? thanks, Lennert > > Hi, > > > > It should certainly work, and if it doesn't, that would be a bug. When a > > packet hits DNAT in PREROUTING, it's stolen away and reinjected into the > > networking stack later on. This reinjection might fail for a number of > > reasons: > > > > - There is no route to the new IP address. > > - There is a route to the new IP address but neighbour discovery, a.k.a. > > ARP, fails. Either because the interface on the bridge has no IP > > address (so that ARP probes can't be sent) or because the destination > > host isn't there. > > > > If you don't want to give the bridge interface an IP address, configure > > a static ARP entry (/sbin/ip neigh add 1.2.3.4 lladdr 00:11:22:33:44:55). > > > > If it still doesn't work, please drop me a line. > > > > > > cheers, > > Lennert > > > > > > On Tue, Feb 05, 2002 at 04:21:31PM -0800, Eric Low wrote: > > > > > I'm just curious, will DNAT'ing work with the bridging netfilter patch and > > > ebtables installed? Everything still appears to go PREROUTING -> FORWARD > > -> > > > POSTROUTING, but when I try DNAT'ing, the packets appear to be lost. Here > > is > > > my ruleset: > > > > > > -t nat -A PREROUTING -i eth1 -p tcp -d 198.122.149.0/24 --dport 80 -j DNAT > > --to > > > 198.122.149.10:80 > > > -A FORWARD -i eth1 -o eth0 -p tcp -d 198.122.149.10/32 --dport 80 -j LOG > > > --log-level 0 > > > -A FORWARD -i eth1 -o eth0 -p tcp -d 198.122.149.10/32 --dport 80 -j ACCEPT > > > > > > The logging was inserted in there for test purposes, and shows no matching > > > packets. None of the packets arrive at 198.122.149.10:80 (those are fake > > > addresses). I believe this is the same ruleset that worked when I was > > doing IP > > > forwarding (before I installed the bridge/netfilter patch). I'm assuming > > that > > > it can't be done, or is perhaps a routing issue (ie. it doesn't know where > > > 198.122.149.10 is located), but I just want to make sure. > > > > > > Thanks, > > > Eric > > > _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
