Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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").
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").
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 11:25 AM.
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.
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.
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.
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:
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):
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
accessing my site from internal network
