* [LARTC] NAT+portfw failure
2001-02-27 3:12 [LARTC] NAT+portfw failure Paul
@ 2001-02-27 8:53 ` Arthur
2001-02-27 17:56 ` Paul
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Arthur @ 2001-02-27 8:53 UTC (permalink / raw)
To: lartc
<PRE>
On Tue, 27 Feb 2001, Paul Wouters wrote:
><i> I have the following forced up mew by evil telco problem:
</I>><i>
</I>><i> - One IP
</I>><i> - Homebrew LAN
</I>><i> - portforwarding for some services.
</I>><i> - extra PPTP/ppp layer to an internal 10.* network which mutilates DNS
</I>><i> answers.
</I>><i>
</I>><i> Setup:
</I>><i>
</I>><i> Machine A has ip a.b.c.d (real IP) and is reachable over ADSL with it from
</I>><i> the world. It does NAT for an internal LAN 192.168.0.0/24) and has portforwading
</I>><i> turned on for some ports (eg 80) to 192.168.0.x. The pptp interface has 10.c.d.e.
</I>><i>
</I>><i> Problem: When on the LAN, pointing to www.whatever.nl resolves to a.b.c.d for
</I>><i> everyone, but the Telco's stupid system rewrites it to be 10.c.d.e. A packet
</I>><i> is sent with source 192.168.0.y and destination 10.c.d.e. It arrives a the
</I>><i> firewall, get's NATTED, and portforwarded. However, the portforwarded
</I>><i> destination is on the same interface as the packet came from, and this then
</I>><i> generates an icmp unreachable.
</I>><i>
</I>><i> Is there a way to allow this (on linux 2.2). If not, would 2.4 NAT of the
</I>><i> destination address work or have the same simmilar interface problem?
</I>><i>
</I>><i> Paul, who realises he is too tired to better explain "MXstream, KPN's
</I>><i> wonderful horrible ADSL network"
</I>
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.
--
/\ / | <A HREF="mailto:arthurvl@sci.kun.nl">arthurvl@sci.kun.nl</A> | 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
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread* [LARTC] NAT+portfw failure
2001-02-27 3:12 [LARTC] NAT+portfw failure Paul
2001-02-27 8:53 ` Arthur
@ 2001-02-27 17:56 ` Paul
2001-02-28 4:06 ` Largo
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Paul @ 2001-02-27 17:56 UTC (permalink / raw)
To: lartc
<PRE>On Tue, 27 Feb 2001, Arthur van Leeuwen wrote:
[ MXstream ]
><i> Paul's problem might be relatively easily solved with a local DNS server on
</I>><i> the LAN that will generate the LAN-local address for a.b.c.d, and is a DNS
</I>><i> forwarder for everything else.
</I>
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.
><i> The problem might also be solved by adding a
</I>><i> specific firewall rule that will *not* masquerade packets to the 10.x.y.z
</I>><i> address the PPP connection has, but simply accept them. It *is* possible,
</I>><i> after all, to connect a single IP address to multiple interfaces. :)
</I>
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.
><i> Paul, could maybe you specify us with a more detailed picture of the LAN and
</I>><i> the position of a.b.c.d in it and whether or not a.b.c.d is tunneled into
</I>><i> the LAN and whether or not a.b.c.d is the 'internet-visible' address of the
</I>><i> 10.x.y.z address of the PPP connection and such? The above blurb was
</I>><i> slightly unclear of that.
</I>
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.
--- <A HREF="mailto:cne_pc@youknowwhattodo.yahoo.com">cne_pc@youknowwhattodo.yahoo.com</A>, in response to Norton's
patent on "software updates"
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread* [LARTC] NAT+portfw failure
2001-02-27 3:12 [LARTC] NAT+portfw failure Paul
2001-02-27 8:53 ` Arthur
2001-02-27 17:56 ` Paul
@ 2001-02-28 4:06 ` Largo
2001-02-28 13:14 ` striscio
2001-03-02 17:24 ` Paul
4 siblings, 0 replies; 6+ messages in thread
From: Largo @ 2001-02-28 4:06 UTC (permalink / raw)
To: lartc
<PRE>yeah i think i get the saame thing when routing 10. to 192.168.1.
the packet wont go backwards. is it a performance question?
i seem to only get this when there is no traffic.
i have a single external int w/ ipmasq. Portforwarded servers are 192.168.1.
My private Lan is 10.*
00:07:15.730063 lo < Oort.miranda.opz > Oort.miranda.opz: icmp: host
10.0.0.255 unreachable [tos 0xc0]
00:07:15.730099 lo < Oort.miranda.opz > Oort.miranda.opz: icmp: host
10.0.0.255 unreachable [tos 0xc0]
00:07:19.730396 lo > Oort.miranda.opz > Oort.miranda.opz: icmp: host
10.0.0.255 unreachable [tos 0xc0]
00:07:19.730439 lo > Oort.miranda.opz > Oort.miranda.opz: icmp: host
10.0.0.255 unreachable [tos 0xc0]
00:07:19.730464 lo > Oort.miranda.opz > Oort.miranda.opz: icmp: host
10.0.0.255 unreachable [tos 0xc0]
00:07:19.730396 lo < Oort.miranda.opz > Oort.miranda.opz: icmp: host
10.0.0.255 unreachable [tos 0xc0]
-----Original Message-----
From: <A HREF="mailto:lartc-admin@mailman.ds9a.nl">lartc-admin@mailman.ds9a.nl</A> [mailto:<A HREF="mailto:lartc-admin@mailman.ds9a.nl">lartc-admin@mailman.ds9a.nl</A>]On
Behalf Of Paul Wouters
Sent: Tuesday, February 27, 2001 3:12 AM
To: <A HREF="mailto:lartc@mailman.ds9a.nl">lartc@mailman.ds9a.nl</A>
Subject: [LARTC] NAT+portfw failure
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"
--
Just patent your virus and sue the anti-virus companies for reverse
enineering it.
--- <A HREF="mailto:cne_pc@youknowwhattodo.yahoo.com">cne_pc@youknowwhattodo.yahoo.com</A>, in response to
Norton's
patent on "software updates"
_______________________________________________
LARTC mailing list / <A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A>
<A HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc">http://mailman.ds9a.nl/mailman/listinfo/lartc</A> HOWTO:
<A HREF="http://ds9a.nl/2.4Routing/">http://ds9a.nl/2.4Routing/</A>
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread* [LARTC] NAT+portfw failure
2001-02-27 3:12 [LARTC] NAT+portfw failure Paul
` (2 preceding siblings ...)
2001-02-28 4:06 ` Largo
@ 2001-02-28 13:14 ` striscio
2001-03-02 17:24 ` Paul
4 siblings, 0 replies; 6+ messages in thread
From: striscio @ 2001-02-28 13:14 UTC (permalink / raw)
To: lartc
<PRE>On Tuesday 27 February 2001 04:12, Paul Wouters wrote:
On Tuesday 27 February 2001 04:12, you wrote:
I'm not sure I understood the problem, but I have a similar situation (an
ADSL router with public address a.b.c.d that forwards everything coming in to
a single host THOR with ip 172.17.32.91). The router can't reach other
internal addresses (only 172.17.32.91).
This host THOR has a second network card (ip 172.18.32.99) and acts also as
gateway for the LAN.
To make internal hosts reach adress a.b.c.d I put an ip alias to the second
eth on THOR that answers on the address a.b.c.d
In that way:
- external host talk to the router which forwards on the internal host THOR
- internal host try to connect to a.b.c.d and receive answer from THOR.
If the router would be able to handle packets addressed to it and coming from
internal network this werid trick wouldn't be necessary, but actually THOR
would answer to internal and external call both in the actual situation and
in the perfect world.
Hope this may help you. If this soluiton has something wrong or can be done
better, please help me.
have a good day
gianpaolo
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread* [LARTC] NAT+portfw failure
2001-02-27 3:12 [LARTC] NAT+portfw failure Paul
` (3 preceding siblings ...)
2001-02-28 13:14 ` striscio
@ 2001-03-02 17:24 ` Paul
4 siblings, 0 replies; 6+ messages in thread
From: Paul @ 2001-03-02 17:24 UTC (permalink / raw)
To: lartc
<PRE>On Wed, 28 Feb 2001, striscio wrote:
><i> Subject: Re: [LARTC] NAT+portfw failure
</I>
There is answer is at:
<A HREF="http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc-10.html">http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc-10.html</A>
Paul
The classic case is that internal staff try to access your `public' web server, which is actually DNAT'ed from the public address (1.2.3.4) to an internal machine
(192.168.1.1), like so:
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
One way is to run an internal DNS server which knows the real (internal) IP address of your public web site, and forward all other requests to an external DNS
server. This means that the logging on your web server will show the internal IP addresses correctly.
The other way is to have the NAT box also map the source IP address to its own for these connections, fooling the server into replying through it. In this example,
we would do the following (assuming the internal IP address of the NAT box is 192.168.1.250):
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
-p tcp --dport 80 -j SNAT --to 192.168.1.250
Because the PREROUTING rule gets run first, the packets will already be destined for the internal web server: we can tell which ones are internally sourced by the
source IP addresses.
</PRE>
^ permalink raw reply [flat|nested] 6+ messages in thread