nat + forwarding == routing error???

[Noses]

> I've got a slightly complicated problem. I'm running a router with 
> multiple outgoing connections and a number of LANs and a DMZ being 
> routed through it.
>
> 1) Even though I have "fwd <appropriate router>" rules for all 
> addresses I have to have a default router or the rules won't even be 
> reached (giving me a "no route to host" - I'd assume there should be a 
> way to force a packet to get into ipfw even if the kernel is believing 
> the packet would go nowhere.
>
> 2) Strangest problem: It depends on passing through natd whether a fwd 
> rule is behaving according to the man page or not. I've got the 
> following construction:
>
> divert ${NAT_1} all from 192.168.160.0/24 to any in via ${nic_LAN}
> fwd ${Provider_1} all from ${DMZ_Provider_1} to any not ${local}
> fwd ${Provider_1} all from ${NAT_addr_1} to any not ${local}
>
> The relevant NATD is using an "alias_address" statement (if there is 
> any difference). Extending the rules by "log" statements shows packets 
> being caught by the correct rules and tcpdump shows the packets on the 
> wire having been treated correctly by NAT.
> Now packets from DMZ_Provider_1 are being sent to the correct outgoing 
> interface (which is different from the default route's interface) but 
> the packets that have been aliased by natd are sent out on the default 
> route even though the log shows me that the relevant "fwd" rule has 
> been taken.
>
> Any ideas? I always assumed that the knowledge about packets having 
> been treated by NAT would be kept inside natd...

I have to admit that doing serious things after not having slept for 24 
hours is not a good idea. My observation was wrong: The second fwd rule 
is applied and the packet is leaving the machine nut it is acting like 
a "permit" rule (i.e. the forwarding part is ignored). Which is just as 
bad but probably easier to explain.


Achim