Masqed client cannot access masqed server

This is a discussion on Masqed client cannot access masqed server within the Linux Networking forums, part of the Linux Forums category; Hey newsgroup! I have a small home LAN with all internal machines - including the webserver this post is about - SNATed ...


Go Back   Usenet Forums > Linux Forums > Linux Networking

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-24-2004
Artom
 
Posts: n/a
Default Masqed client cannot access masqed server

Hey newsgroup!

I have a small home LAN with all internal machines - including the
webserver this post is about - SNATed to the single (dynamic) IP address
my ISP gives me. Note that my NAT router and my server are different
machines. I'm using the TLPD IP-Masq HOWTO's stronger iptables ruleset,
with some small PORTFW modifications for a file sharing app and the
aforementionned webserver.

I can access my webserver internally on the 192.168.0.0 network, and
people outside can access it using my public IP address (thanks dynamic
DNS!), but I can't access it from the inside using my public IP address,
i.e. I can't go out and then back in again. I can ping my public IP
address from the inside, and I can ssh to it from the inside too, but
port 80 connections time out.

This isn't a real problem, but out of curiosity, what would be the solution?

enjoy!
Artom
Reply With Quote
  #2 (permalink)  
Old 04-24-2004
jack
 
Posts: n/a
Default Re: Masqed client cannot access masqed server

Artom wrote:
> I have a small home LAN with all internal machines - including the
> webserver this post is about - SNATed to the single (dynamic) IP address
> my ISP gives me. Note that my NAT router and my server are different
> machines. I'm using the TLPD IP-Masq HOWTO's stronger iptables ruleset,
> with some small PORTFW modifications for a file sharing app and the
> aforementionned webserver.
>
> I can access my webserver internally on the 192.168.0.0 network, and
> people outside can access it using my public IP address (thanks dynamic
> DNS!), but I can't access it from the inside using my public IP address,
> i.e. I can't go out and then back in again. I can ping my public IP
> address from the inside, and I can ssh to it from the inside too, but
> port 80 connections time out.
>
> This isn't a real problem, but out of curiosity, what would be the
> solution?


Think again.

I've seen this problem, accompanied by the answers, around for a while
by now.

May I ask You a personal favour (only because I am too lazy to do it
myself):

Please make a picture of how a connection between an inside web browser
request to Your public IP would look like. From the beginning over all
MASQ'ing and everything to Your server and back. And step-by-step.

Make it look cute, and You'll be the author of the "Local-MASQ-HowTo",
which will be read worldwide.


Sorry for being brute, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...
Reply With Quote
  #3 (permalink)  
Old 04-24-2004
Antoine EMERIT
 
Posts: n/a
Default Re: Masqed client cannot access masqed server

jack <not@all.org> wrote news:c6eksa$9uk$00$1@news.t-online.com:
> Artom wrote:
>> This isn't a real problem, but out of curiosity, what would be the
>> solution?


No problem :


For each portforwarding to an internal host, you should add a combined
destination and source NAT iptables rule (second following rule) that
modify the source ip of your internal host which are redirected to your
internal server :

iptables --table nat --append PREROUTING --protocol tcp \
--destination-port 80 -j DNAT --to-destination 192.168.0.10:80

iptables --table nat --insert POSTROUTING -p tcp -s 192.168.0.0/24 \
-d 192.168.0.10 --dport 80 -j SNAT --to-source 192.168.0.1


192.168.0.10 = your web server ip
192.168.0.1 = your router ip

As this you may use your public router ip and so you public web server
hostname(s) and support any virtual web server name.

Note : the "standard" port forwarding is not enough because when an
internal host connect to the public interface of your router, the linux
network code don't make it a forward packet (the packet enter the host on
the internal router NIC and don't move to the second NIC, so it's not a
forward and so the masquerading process is not engaged).


Regards

Reply With Quote
  #4 (permalink)  
Old 04-25-2004
Artom
 
Posts: n/a
Default Re: Masqed client cannot access masqed server

I had alread started writing this when Antoine put up his reply, so I
though I might as well finish. By the way Antoine,

iptables --table nat --append PREROUTING --protocol tcp \
--destination-port 80 -j DNAT --to-destination 192.168.0.10:80

causes *any* destination port 80 to be routed to my internal webserver,
so I can't access any external websites. Adding a -d <external address>
(which is a line I already have in my iptables init script) fixes that,
but then my original problem isn't fixed.

jack wrote:

> Artom wrote:
>
>> I have a small home LAN with all internal machines - including the
>> webserver this post is about - SNATed to the single (dynamic) IP
>> address my ISP gives me. Note that my NAT router and my server are
>> different machines. I'm using the TLPD IP-Masq HOWTO's stronger
>> iptables ruleset, with some small PORTFW modifications for a file
>> sharing app and the aforementionned webserver.
>>
>> I can access my webserver internally on the 192.168.0.0 network, and
>> people outside can access it using my public IP address (thanks
>> dynamic DNS!), but I can't access it from the inside using my public
>> IP address, i.e. I can't go out and then back in again. I can ping my
>> public IP address from the inside, and I can ssh to it from the inside
>> too, but port 80 connections time out.
>>
>> This isn't a real problem, but out of curiosity, what would be the
>> solution?

>
>
> Think again.
>
> I've seen this problem, accompanied by the answers, around for a while
> by now.


True. It's in the very same HOWTO I used to configure iptables, but the
solution they give does not work for me.

> May I ask You a personal favour (only because I am too lazy to do it
> myself):
>
> Please make a picture of how a connection between an inside web browser
> request to Your public IP would look like. From the beginning over all
> MASQ'ing and everything to Your server and back. And step-by-step.


Here it goes:

This is the setup:

|--------------------|
| internal webserver |--|
|--------------------| | internal interface & address|------------|
|---------------------------------| NAT router |
|-----------------| | |------------|
| internal client |-----| external interface $ address|
|-----------------| |
|
World

The internal client looks at the destination address and its own address
and netmask, realizes that the address is not on the internal network,
and sends it to the NAT router.

Thanks to port 80 PORTFWing:

iptables -A PREROUTING -t nat -p tcp -d <external address> --dport 80 \
-j DNAT --to <webserver>:80

the packet's destination is modified to the webserver's address before
it is routed, and it ends up going out the router's internal interface
unmasqed. The problem is, the stronger ruleset that the TLPD
IP-Masq-HOWTO provides does not allow packets to be incoming and
outgoing on the same interface:

iptables -A FORWARD -i <external interface> -o <internal interface> \
-p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
(allows port 80 PORTFWing)

and

iptables -A FORWARD -i <external interface> -o <internal interface> \
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i <internal interface> -o <external interface> \
-j ACCEPT
(the last two rules before a routed packet is dropped).

Thus any packet from an internal client to the router's external address
on port 80 is dropped by the router.

If

iptables -A FORWARD -i <internal interface> -o <internal interface> \
-p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

is added, then the router no longer drops the packets (check the syslog
to convince yourself), but the webserver still cannot be accessed by an
internal client through the router's external address.

Recall that the packet's source IP is not masqed by the router because
they never make it to the external interface, so when the webserver
sends packets back, it send them directly to the client's address on the
internal network, using the webserver's address on the internal network
as source address. But the client is expecting to hear back from the
router's external address, because that's where it sent the packets, so
it doesn't pick up the packets sent to it by the webserver.

So along with the aforementionned

iptables -A FORWARD -i <internal interface> -o <internal interface> \
-p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

we need to source NAT anything from the internal network going to the
webserver on port 80 to the router's internal address with a

iptables -I POSTROUTING -t nat -p tcp -s <internal network> -d \
<webserver> --dport 80 -j SNAT --to <router>

This is still not enough however, because the very first thing we added
to the iptables init script was

iptables -A FORWARD -i <internal interface> -o <internal interface> \
-p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

and that only allows packets to be incoming and outgoing on the internal
interface if they are destined to port 80. But the client's port is not
80, and so we need to replace that with a

iptables -A FORWARD -i <internal interface> -o <internal interface> -j\
ACCEPT

right before the last

$IPTABLES -A FORWARD -j drop-and-log-it

catch-all rule.

> Make it look cute, and You'll be the author of the "Local-MASQ-HowTo",
> which will be read worldwide.


Cute enough? :)
>
> Sorry for being brute, Jack.


Hey, no problem. Thanks for the hint. I'll put a modified version of
this post on that webserver some time soon, look for it at coth.no-ip.org.

enjoy!
Artom
Reply With Quote
  #5 (permalink)  
Old 04-25-2004
jack
 
Posts: n/a
Default Re: Masqed client cannot access masqed server

Artom wrote:
> Cute enough? :)


WHOW! - I have no words...! Excellent!


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 01:39 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0