On Thu, 2003-11-27 at 21:41, Richard Bewley wrote: > Hi, > > Thanks for the response. The Cisco commands simply accomplish port mapping, > so that all DNS requests are sent to my linux box (since obviously the > router isn't serving my dns zone). The end result, is I want to host a dns > zone off the linux box, and have it available when somebody queries > 12.159.185.248 (the cisco router's ip address). > > Now, I know this type of setup works, because if I map port 80 to 10.3.0.10, > I can view webpages from the outside world at 12.159.185.248 fine. The > packet comes in, goes to the linux box, and back out again. I'm wondering > if there's something different going on because it's UDP... That's fine, but you're saying that external to internal works fine. It sounded like your original request was from internal to internal, hence the reflection problem. It's all a matter of routing. Allow me to try and explain again... 1) Client (10.3.0.11) sends DNS request. [ src == 10.3.0.11:<high_port>, dst == 12.159.185.248:53 ] 2) Router redirects traffic. [ src == 10.3.0.11:<high_port>, dst == 10.3.0.10:53 ] 3) Linux server receives packet. [ src == 10.3.0.11:<high_port>, dst == 10.3.0.10:53 ] 4) Linux server returns packet to sender. [ src == 10.3.0.10:53, dst == 10.3.0.11:<high_port> ] 5) Client receives return packet. [ src == 10.3.0.10:53, dst == 10.3.0.11:<high_port> ] Events #1, 2 and 3 exhibit "normal behavior". However, unless your Cisco is also translating the source address (should occur at #2), the Linux server will see that the source exists on the same network segment and attempt to deliver it directly (#4). But your client isn't expecting to see any packets from the Linux server (#5), so it drops them. External to internal traffic should work fine, since the client would exist outside of the local LAN, causing normal routing to take effect. In order to "bounce" traffic internally, you need the router to translate BOTH destination (which you're currently doing) and source (which I don't think you are) addresses. Make sense? Apropos to your situation? Honestly, your best bet is to dump IP traffic. I get the impression you haven't done this yet. -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
