LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices



Reply
 
Search this Thread
Old 08-21-2005, 01:57 AM   #1
FLBlindman
LQ Newbie
 
Registered: Aug 2005
Posts: 9

Rep: Reputation: 0
Question accessing my site from internal network


Im sure this a noob question,but ever since I set up an iptables NAT box,I've had to access my pub website by its internal address.
Is there a workaround for this?The closest thing I could find had to do with SNAT'ing the packets to foolthe box into thinking the request came from an outside source,but I cant get that to fly.
I'm using webmin to access the iptables config.
Thanks.
 
Old 08-21-2005, 03:01 AM   #2
carl.waldbieser
Member
 
Registered: Jun 2005
Location: Pennsylvania
Distribution: Kubuntu
Posts: 197

Rep: Reputation: 32
Re: accessing my site from internal network

Quote:
Originally posted by FLBlindman
Im sure this a noob question,but ever since I set up an iptables NAT box,I've had to access my pub website by its internal address.
Is there a workaround for this?The closest thing I could find had to do with SNAT'ing the packets to foolthe box into thinking the request came from an outside source,but I cant get that to fly.
I'm using webmin to access the iptables config.
Thanks.
Are you doing any kind of packet filtering like rejecting outbound traffic on port 80? There could be lots of reasons, I guess. Could you post the output of theses commands?
Code:
# iptables -nL
# iptables -t nat -nL
They will spit out you firewall rules for the filter and nat tables (if you are doing anything funky with the mangle table, maybe you want to print that out, too (with "-t mangle").

Thanks.
 
Old 08-21-2005, 03:27 AM   #3
FLBlindman
LQ Newbie
 
Registered: Aug 2005
Posts: 9

Original Poster
Rep: Reputation: 0
Re: Re: accessing my site from internal network

Quote:
Originally posted by carl.waldbieser
Are you doing any kind of packet filtering like rejecting outbound traffic on port 80? There could be lots of reasons, I guess. Could you post the output of theses commands?
Code:
# iptables -nL
# iptables -t nat -nL
They will spit out you firewall rules for the filter and nat tables (if you are doing anything funky with the mangle table, maybe you want to print that out, too (with "-t mangle").

Thanks.

Chain INPUT (policy ACCEPT)
target prot opt source destination
REJECT all -- 200.28.92.0/24 0.0.0.0/0 reject-with icmp-por t-unreachable
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:1:20 reject -with icmp-port-unreachable
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:26:8766 rej ect-with icmp-port-unreachable
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:8767:8768
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:8769:27949 reject-with icmp-port-unreachable
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:27966:31999 reject-with icmp-port-unreachable
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:35001:65100 reject-with icmp-port-unreachable
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:27950:27965
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp state NEW,RELATE D,ESTABLISHED
the funky ports are teamspeak and an enemy territory server.

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination



Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:192.168.1.35:80

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


iptables -t mangle -nL
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

thanks.
 
Old 08-21-2005, 12:24 PM   #4
carl.waldbieser
Member
 
Registered: Jun 2005
Location: Pennsylvania
Distribution: Kubuntu
Posts: 197

Rep: Reputation: 32
Re: Re: Re: accessing my site from internal network

It looks like you have it configured so any outbound traffic is masqueraded. It also looks like you have it so any tcp traffic on any port gets sent to the webserver on your LAN (port 80).

The stuff in the INPUT table I am a little unclear about. The INPUT chain is the last filter hook before the traffic gets sent to a local process, so...

+You reject all traffic from 200.28.92.0 with ICMP unreachable.
+ Same for tcp traffic for most ports. The only non-blocked ports appear to be 21-25, 8767-8768, 27950-27965, 32000-35000, and 65101-MAX.
+ udp ports seem to be allowed for certain ranges, though I can't see where they were ever blocked...

So, let's say you try to access the web site from the outside. Packets travel to the public interface, and the PREROUTING chain has at it, so the packet is re-written to specify the destination as 192.168.1.35:80.

Well, assuming that the web server is not the local machine, that seems like it should work, based on my interpretation of your setup.

Do you think you could explain the relevant physical connections? (Is it webserver <--> firewall box <--> Internet). Where are you trying to access the public address from? (E.g. browser is on 1) The webserver, 2) The firewall, 3) Some other PC on the LAN, 4) Some PC out across the Internet).

Also, if I misinterpreted anything from your setup, could you please let me know? Thanks.

Last edited by carl.waldbieser; 08-21-2005 at 12:25 PM.
 
Old 08-21-2005, 05:23 PM   #5
FLBlindman
LQ Newbie
 
Registered: Aug 2005
Posts: 9

Original Poster
Rep: Reputation: 0
Well,It may very well be that all tcp traffic is routed to the webserver.(ooops).But from another machine on the lan,all other sites are fine. The NAT box is the gameserver box for reasons being that packet forwarding doesnt seem to hold if it isnt,i.e players get dropped.The box i use to access other stuff has no services running on it.
Im a little unclear about the order of the chains,I was under the impression that in order to filter out unwanted crap,all the traffic from the net had to go through the ext int.
 
Old 08-21-2005, 05:59 PM   #6
carl.waldbieser
Member
 
Registered: Jun 2005
Location: Pennsylvania
Distribution: Kubuntu
Posts: 197

Rep: Reputation: 32
Quote:
Originally posted by FLBlindman

Im a little unclear about the order of the chains,I was under the impression that in order to filter out unwanted crap,all the traffic from the net had to go through the ext int.
Err, I am not sure what you mean this statement. The chains are processed in this order:
-- One NIC to another NIC --
PREROUTING
FORWARD
POSTROUTING

-- NIC to Local Process --
PREROUTING
INPUT

-- Local Process to NIC --
OUTPUT
POSTROUTING

-- Local Process to Local Process --
OUTPUT
INPUT

Not sure what you want to filter out. I think the conventional wisdom is to have a policy where you block everything, and then you make rules to selectively let packets flow in and out.

If you could explain a little more in detail what is happening (walk me from where the packets start to where they are supposed to go) maybe that would help.
Thanks.
 
Old 08-22-2005, 03:16 AM   #7
FLBlindman
LQ Newbie
 
Registered: Aug 2005
Posts: 9

Original Poster
Rep: Reputation: 0
I am aware that conventional wisdom supports the idea of blocking everything first,then letting what you want in,just that everytime I've tried that,nothing gets in. I did read somewhere that the order of the rules is important,so would that mean that I would set default policy to drop?If so where?,at the end of the input chain?

Ideally,I would like traffic only through ports necessary for the webserver,gameserver and teamspeak,which so far seems to be working.
My original problem is getting the internal servers' public ip visible to the internal network,without fudging anything else.
So I type in the address from this machine,it's supposed to go the gateway. Instead what I get is 'connection refused'.. So that makes me think the packets are not leaving this machine.
I have changed the DNAT rule to only forward to the webserver if the source port is 80.

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 to:192.168.1.35:80


taken from the netfilter page---

Quote:
f you are doing port forwarding back onto the same network, you need to make sure that both future packets and reply packets pass through the NAT box (so they can be altered). The NAT code will now (since 2.4.0-test6), block the outgoing ICMP redirect which is produced when the NAT'ed packet heads out the same interface it came in on, but the receiving server will still try to reply directly to the client (which won't recognize the reply).

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.
 
Old 08-22-2005, 06:27 PM   #8
carl.waldbieser
Member
 
Registered: Jun 2005
Location: Pennsylvania
Distribution: Kubuntu
Posts: 197

Rep: Reputation: 32
Quote:
Originally posted by FLBlindman
I am aware that conventional wisdom supports the idea of blocking everything first,then letting what you want in,just that everytime I've tried that,nothing gets in. I did read somewhere that the order of the rules is important,so would that mean that I would set default policy to drop?If so where?,at the end of the input chain?
When you set a policy for a chain, it is *always* the lats thin g in the chain that is checked. It is essentially the rule that gets followed if none of the other rules match.
The order of the rules are important. Basically, they are processed from first to last. Each rule has 2 parts-- a match and an action. The match is just a test to see if the current packet matches the rule. If it matches, that action is executed. If not, the next rule is checked. If no rules match, the policy action is executed.

Quote:
Originally posted by FLBlindman

Ideally,I would like traffic only through ports necessary for the webserver,gameserver and teamspeak,which so far seems to be working.
My original problem is getting the internal servers' public ip visible to the internal network,without fudging anything else.
So I type in the address from this machine,it's supposed to go the gateway. Instead what I get is 'connection refused'.. So that makes me think the packets are not leaving this machine.
I have changed the DNAT rule to only forward to the webserver if the source port is 80.

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 to:192.168.1.35:80


taken from the netfilter page---
Well, you could use "traceroute" to find out where the packet is stopping. According to that quote you provided, what is happening to your packets is something like this:

Packet starts life on some PC in your LAN. It is destined for the public interface of your web server, so it heads over to your default gateway.
At the router, the MASQUERADE rule means that the router changes the packet so it looks like it was sent from the router.
You router routes this to the internal web server.
The web server processes the data and replies.
The reply packet heads to the router.
One of your REJECT rules (maybe REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spts:26:8766 rej ect-with icmp-port-unreachable?) is stoping the reply packet from getting back out.

So maybe you should put an ACCEPT rule in for packets that originate on the web server on port 80 that are destined for hosts outside the LAN?

The other suggestion from the quote, that you just fiddle with DNS, sounds like it could be easier if you have a small network. You could just put your web server's internal IP address in the /etc/hosts file (\WINDOWS\system32\drivers\etc\hosts on Windows) for each of the machines on the LAN. Then their traffic wouldn't have to do the outside-inside trick.
 
Old 08-22-2005, 08:05 PM   #9
scowles
Member
 
Registered: Sep 2004
Location: Texas, USA
Distribution: Fedora
Posts: 620

Rep: Reputation: 31
The other suggestion from the quote, that you just fiddle with DNS, sounds like it could be easier if you have a small network. You could just put your web server's internal IP address in the /etc/hosts file (\WINDOWS\system32\drivers\etc\hosts on Windows) for each of the machines on the LAN. Then their traffic wouldn't have to do the outside-inside trick.

I agree. Why anyone would want to tie up NATing resouces of a firewall for internal hosts trying to access another internal host (via the public IP address of the firewall) has never made any since to me. Maybe there is a legitimate reason, but to date, I have yet to find a reason to waste firewall resources in such a manner. Either setup an internal DNS server that returns the private IP address of your server or edit the hosts file on the clients to point to the internal IP address of the server.
 
Old 08-22-2005, 09:29 PM   #10
FLBlindman
LQ Newbie
 
Registered: Aug 2005
Posts: 9

Original Poster
Rep: Reputation: 0
hadnt thought of that,thanks.
 
Old 08-22-2005, 10:39 PM   #11
FLBlindman
LQ Newbie
 
Registered: Aug 2005
Posts: 9

Original Poster
Rep: Reputation: 0
Worked like a charm thanks a million guys.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

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 On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Accessing Web Site dudeman41465 Linux - Networking 2 09-17-2005 11:36 AM
accessing an internal network via internet softice2001 Linux - Networking 7 10-21-2004 01:35 PM
accessing an internal network via internet kg4joh Linux - Networking 1 10-03-2004 09:02 PM
?Accessing my internal (c type) ip webpages from external pudhiyavan Linux - Networking 7 12-08-2003 01:48 AM
accessing box from internal network but not from external JereBear Linux - Networking 12 05-12-2001 02:12 AM


All times are GMT -5. The time now is 01:51 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration