Shorewall users - Mar 2006 - howto access a dnat-ed port in loc with a 2interface dynamic-ip dsl connection from the loc side (hostname is dyndns) with shorewall 2.4.0

hi there,

quick question with some old shorewall 2.4.0 setup, just to try to find
out if its possible with a simple configuration tweak to make something
possible.

two lancard box, connected with pppoe to some dsl provider with dynamic
changing external official ip address. this external pppoe interface
registers a dyndns.org name (myhost.dyndns.org)

now i have a dnat line to some internal box for a tcp port in the rules
file:

> DNAT net loc:192.168.1.2:80 tcp 80
i can reach this port (being outside on the internet in some other
network for example) just fine with the dyndns.org address just fine.

but i need to make it reachable the same way also from the inside. but
it doesnt work in this scenario. when a client from the inside lan/loc
surfs to the http://myhost.dyndns.org address it never reaches that
192.168.1.2:80 server

i dont want to start messing around with hostfiles, bind-configuration
for internal/external resolving and all this stuff.

is there any way to make this possible with some more shorewall means in
an easy way? i didnt find out so far.

this shorewall on that box is also quite old, maybe its already possible
with some tweaks in some newer shorewall versions?

i wonder what kind of rules i need to add or tweak that the packets from
the inside only travel to the firewall itself, and then get redirected
back to that 192.168.1.2:80

thanks for any quick help to this.
regards.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

On Thursday 30 March 2006 15:24, Andreas Bittner wrote:
>
> i dont want to start messing around with hostfiles, bind-configuration
> for internal/external resolving and all this stuff.
In other words, you don''t want to do it right but rather want a quick
and ugly
hack.
>
> is there any way to make this possible with some more shorewall means in
> an easy way? i didnt find out so far.
>
Read Shorewall FAQ 2 -- the instructions are there.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Hi Andreas

Tom has described this quite thoroughly in the FAQ.  If your webserver
is on the same lan as the rest of your machines, the relevant FAQ is
http://www.shorewall.net/2.0/FAQ.htm#faq2

If your webserver is on a special DMZ lan by itself, the FAQ to read is
http://www.shorewall.net/2.0/FAQ.htm#faq1d

Hope this helps.


Rune

On 3/31/06, Andreas Bittner <abittner@stud.fh-heilbronn.de>
wrote:
> hi there,
>
> quick question with some old shorewall 2.4.0 setup, just to try to find
> out if its possible with a simple configuration tweak to make something
> possible.
>
> two lancard box, connected with pppoe to some dsl provider with dynamic
> changing external official ip address. this external pppoe interface
> registers a dyndns.org name (myhost.dyndns.org)
>
> now i have a dnat line to some internal box for a tcp port in the rules
> file:
>
>
> > DNAT net loc:192.168.1.2:80 tcp 80
>
> i can reach this port (being outside on the internet in some other
> network for example) just fine with the dyndns.org address just fine.
>
> but i need to make it reachable the same way also from the inside. but
> it doesnt work in this scenario. when a client from the inside lan/loc
> surfs to the http://myhost.dyndns.org address it never reaches that
> 192.168.1.2:80 server
>
> i dont want to start messing around with hostfiles, bind-configuration
> for internal/external resolving and all this stuff.
>
> is there any way to make this possible with some more shorewall means in
> an easy way? i didnt find out so far.
>
> this shorewall on that box is also quite old, maybe its already possible
> with some tweaks in some newer shorewall versions?
>
> i wonder what kind of rules i need to add or tweak that the packets from
> the inside only travel to the firewall itself, and then get redirected
> back to that 192.168.1.2:80
>
> thanks for any quick help to this.
> regards.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Tom Eastep wrote:
> In other words, you don''t want to do it right but rather want a
quick and ugly
> hack.
didnt mean to bother you, but this comment doesnt really help much. ;)

> Read Shorewall FAQ 2 -- the instructions are there.
thanks for the pointer, i obviously missed this faq entry, mybad. it
seems as if i would be better of with some better solution to this
problem then that i was thinking of, so you are right with your
objection to my problem :)

thanks again.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Andreas Bittner wrote:
> Tom Eastep wrote:
>>In other words, you don''t want to do it right but rather want a
quick and ugly
>>hack.
>
> didnt mean to bother you, but this comment doesnt really help much. ;)
To rephrase: using DNS and putting your server in a DMZ is a better
solution to this problem than port forwarding.
> ...
> thanks for the pointer, i obviously missed this faq entry, mybad. it
> seems as if i would be better of with some better solution to this
> problem then that i was thinking of, so you are right with your
> objection to my problem :)
I''d like to take this opportunity to introduce "Paul''s
Principles for
Practical Provision of Packet Processing with Shorewall", or PPPPPPS for
short.  Please read them with your tongue planted appropriately in your
cheek, and your sense of humour booted up and sitting at the login
prompt.  :-)

1.  Assume Shorewall already has documentation about your problem.  Read
the documentation, starting with the FAQ.
1.  Assume Tom is right.
1.  When Tom is grumpy and rebukes you for not reading the
documentation, see principles 1 and 1 above.
1.  Shorewall might make iptables easy, but it doesn''t make
understanding fundamental networking principles, traffic shaping, or
multi-ISP routing any easier.
1.  Shorewall is not plug & play.  It is think, plug, think, (configure,
think, test, think, trace, think, )+ and then play.  (With apologies to
those not familiar with perl-compatible regular expressions.)  Get used
to the "think" part - it''s your job!
1.  Design your network on paper before configuring Shorewall.  Some of
the following information might help you with this a little bit
(although note it was designed around Shorewall 2.0):
http://paulgear.webhop.net/linux/shoregen-0.1.1/README
http://paulgear.webhop.net/linux/shoregen-0.1.1/samples/


Paul

On Thursday 30 March 2006 16:40, Paul Gear wrote:
>
> I''d like to take this opportunity to introduce
"Paul''s Principles for
> Practical Provision of Packet Processing with Shorewall", or PPPPPPS
for
> short.  Please read them with your tongue planted appropriately in your
> cheek, and your sense of humour booted up and sitting at the login
> prompt.  :-)
>
<PPPPPPS deleted>

Thanks, Paul! I needed that.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key