On Tue, 27 Feb 2001, Arthur van Leeuwen wrote:
[ MXstream ]
> 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.
Indeed, and this I have done for a client setup using Euronet for their ADSL.
That works fine in that case, they only "have" one domain with just MX and
www A records.
This setup btw, did NOT use NAT, so let me explain this setup because I think
this is the core of the problem (and I just had a large coffee, which should
help my narrative skills somewhat)
internet------- eth0 -- firewall ---- eth1 ------LAN
1.2.3.4 192.168.0.1 192.168.0.x
Now, there is a mailserver on 192.168.0.2, so firewall does portforwarding
of port 25 to 192.168.0.2. 1.2.3.4 is a real IP, and DNS is hosted on the net,
with best MX pointing to 1.2.3.4.
So from the net, there is no problem. But now a machine from the LAN is trying
to use the smtp server. It does a lookup, and gets 1.2.3.4 as address. It's
not local so it sends the packet to the gateway machine, our NAT firewall,
whiuch nicely NAT's it to 1.2.3.4 and then sends it to 1.2.3.4 25, which it
should portforward to 192.168.0.2. But then the firewall outsmarts itself.
Either the combination of NAT+portfowarding kills it, or the "send a packet
to the same interface we received it from protection" kills it. What I saw was
an ICMP unreachble of 1.2.3.4 sent BY 1.2.3.4 (eg it's sending an icmp
unreachable for ITSELF, which is ofcourse a lie :)
Like I said, this is one domain, so we did decide to run dns on the firewall
and it works fine, but I'm still curious. This is all 2.2.x kernels, but I
wonder if 2.4 would have the same problem.
> 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. :)
Yes, I had a similar idea of actually doing NAT based on the destination
address AS WELL, but then I realised 2.2 can't do real NAT, just simple
masquerading.
> 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.
Okay, let me try some more ascii art:
xs4all----------internet-------MXstream----gw------firewall-----webserver
|
ADSL client
Now. As xs4all/ADSL client you get an IP from xs4al, say 194.109.a.b. This is
ofcourse perfectly routable through xs4all's network. But like Arthur said,
it's done over a NAT'ed network. You get a 10.a.b.c number with a PPTP
(pointopoint connection to 195.something with a netmask of 255.255.255.0).
There the fun starts, as the received DNS servers through the PPP link reside
on 10.X.Y.Z where X != a, so you try to route private IP space via your default
route which gets you icmp unreachables.
Now, look at the above diagram again. Realise that ADSL client and firewall
are the same machine. ADSL client has the ppp0 interface, and firewall has
the xs4all IP number on its eth0 interface. Again, there is a port forwarding
from firewall to webserver. So this is what happens when you try to access
the webserver from the LAN.
- send out DNS request for whatever.xs4all.nl (your xs4all IP). This returns
the MXstream 10.X.Y.Z number (It gets REWRITTEN, and you can't circumvent this,
there is apparently a transparent proxy for port 53)
- your browser starts a connection tot he webserver, from 192.168.0.x to
10.X.Y.Z. This is sent to the gateway, which NAT's it, and then the packet is
from 192.168.0.1 to 10.X.Y.Z, which then gets portforwarded to 192.168.0.y.
With tcpdump I actually saw the packets, but they were from 192.168.0.1 to
192.168.0.y (note no 10.* anywhere anymore). Again, the problem seems that
either NAT+portforwarding fucks up, or the "sent to interface we received it
from protection" again kicks in. Again, icmp unreachable messages.
Added weirdness is that icmp itself seems to work fine. From a client in the
LAN, I can ping the 10.*, the 192.168.0* AND the xs4all 194.109.* ip numbers.
So why, if I can ping it, can I not connect to port 80 of it? Something wrong
with NAT and portforwading?
In this setup, a LOT of DNS zones point to that server, so it becomes a
nightmare to run dns for all of those. But I just realised I can try and
have an external bind listen to port 5353 and have an internal forwarding only
bind that uses port 5353, and hopefully MXstream will leave those packets alone.
Paul
--
Just patent your virus and sue the anti-virus companies for reverse
enineering it.
--- cne_pc@xxxxxxxxxxxxxxxxxxxxxxxxx, in response to Norton's
patent on "software updates"
