On Tue, 27 Feb 2001, Paul Wouters wrote: > I have the following forced up mew by evil telco problem: > > - One IP > - Homebrew LAN > - portforwarding for some services. > - extra PPTP/ppp layer to an internal 10.* network which mutilates DNS > answers. > > Setup: > > Machine A has ip a.b.c.d (real IP) and is reachable over ADSL with it from > the world. It does NAT for an internal LAN 192.168.0.0/24) and has portforwading > turned on for some ports (eg 80) to 192.168.0.x. The pptp interface has 10.c.d.e. > > Problem: When on the LAN, pointing to www.whatever.nl resolves to a.b.c.d for > everyone, but the Telco's stupid system rewrites it to be 10.c.d.e. A packet > is sent with source 192.168.0.y and destination 10.c.d.e. It arrives a the > firewall, get's NATTED, and portforwarded. However, the portforwarded > destination is on the same interface as the packet came from, and this then > generates an icmp unreachable. > > Is there a way to allow this (on linux 2.2). If not, would 2.4 NAT of the > destination address work or have the same simmilar interface problem? > > Paul, who realises he is too tired to better explain "MXstream, KPN's > wonderful horrible ADSL network" Ah, for those among you with a taste for the horrid, I'll try to explain things a bit more completely: What Paul here seems to have done is set up a local masqueraded LAN connected to the internet over KPN's MXStream ADSL service. To connect to the MXStream service, you connect the ADSL modem and set up a PPTP connection to it. Over that PPTP connection you then start a PPP connection, which gives you IP connectivity to the MXStream network. The PPP connection, ofcourse, uses 10.x.y.z addresses. Then, you log in to the MXStream service, over HTTP, thereby selecting the 'upstream' provider to use. The MXStream network then masquerades your 10.x.y.z address as a routable IP address, that will get routed by your upstream provider. Among the nicer 'services' the MXStream network provides you is a DNS redirector that will answer any and all DNS requests for you, according to its idea of what name goes with what IP address. This is very useful in the case of start.mxstream.nl, which is the login-server and also has a 10.x.y.z address, but becomes painful in cases where you want to connect to your own host, as the network 'helpfully' provides you with the address *you* know, not with the address other people on the internet see. And yes, this makes for *great* routing examples. :) Paul's problem might be relatively easily solved with a local DNS server on the LAN that will generate the LAN-local address for a.b.c.d, and is a DNS forwarder for everything else. The problem might also be solved by adding a specific firewall rule that will *not* masquerade packets to the 10.x.y.z address the PPP connection has, but simply accept them. It *is* possible, after all, to connect a single IP address to multiple interfaces. :) Paul, could maybe you specify us with a more detailed picture of the LAN and the position of a.b.c.d in it and whether or not a.b.c.d is tunneled into the LAN and whether or not a.b.c.d is the 'internet-visible' address of the 10.x.y.z address of the PPP connection and such? The above blurb was slightly unclear of that. Doei, Arthur. -- /\ / | arthurvl@xxxxxxxxxx | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
