Solved

Iptables routing

Posted on 2009-04-02
25
1,362 Views
Last Modified: 2013-12-06
I have a intranet webserver. I want all traffic to be redirected to that web-server, the web-server is also a recursive dns server. I have another server acting as a router also. At first I tried to use the webserver as a router and set up these rules:

iptables -t nat -A PREROUTING -p udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.100:80

It doesnt deny anything, just allows dns and re-routes web traffic to itself. Now all clients using that web-server as a gateway will only get that web-servers web-page displayed. Bt I didnt want the web-server to do routing. I wanted my network server and router to do that. So I set the clients to use my router as a default gateway and added these rules to it:

#Ping is oing to be allowed
iptables -A FORWARD -p icmp -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

#DNS is going to be allowed
iptables -t nat -A PREROUTING -p udp --dport 53 -j ACCEPT

#Clients with these IP-addresses are gong to be allowed(changing to MAC later):
iptables -t nat -A PREROUTING -p tcp -s 192.168.1.100 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -s 192.168.1.101 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -s 192.168.1.102 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -s 192.168.1.205 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -s 192.168.1.206 -j ACCEPT

#MSN is allowed
iptables -t nat -A PREROUTING -p tcp --dport 1873 -j ACCEPT

#All web traffic should be redirected
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.100:80
iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j DNAT --to-destination 192.168.1.100:80

#Later I will add rules to denying traffic.

The rules that handle DNAT are the same as on the web-server, when it was a router. But this doesnt work. The clients never get a reply from any page, but they are supposed to get a reply from my web-server.
0
Comment
Question by:itnifl
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 13
  • 11
25 Comments
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24047967
What is the policy? (ACCEPT / REJECT / DROP...)
When you have services running on a router (i.e. system with some iptables rules) then you have to accept packets on the INPUT queue. All packets arriving at an interface are INPUT packets unless they match a rule in the nat table or are part of an existing tracked connection (via nat).
Your nat table accepts packets from 192.168.1.100 &c but doesn't do anything with them - if you want them to go somewhere else you have to have a rule in the POSTROUTING chain. If you want them to come into the box you want a rule in the filter (default) table, INPUT chain.
Web connections from 192.168.1.100&c will not be routed to 192.168.1.100:80 because of -j ACCEPT in a previous rule.

Could you post a specific example of a connection that didn't work for a user: what was the IP/port being connected to, where did you want he packet to go, where did it go (if known)
0
 
LVL 2

Author Comment

by:itnifl
ID: 24049016
There is no users other then myself, this is in my home network. That is why I used the word client.
Connections from 192.168.1.100 & c are not supposed to go anywhere else then where they are originally heading, hence they are just accepted. I coud have used the rule FORWARD instead of PREROUTING, but I guess it goes for the same. It is not the INPUT or OUTPUT to the server that I want to control. I want to let the specified servers route anywhere in the network, this is why they are accepted in the PREROUTING rule.

If you read the question closely you will see that I am trying to route all web traffic from any client using 192.168.1.102 as a router. All clients EXCEPT those with the addresses specified in the ACCEPT list. This line on the router shoud do this; iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.100:80 (this is the web server, see the question for the rest of the setup.)

This is not working.

BUT if I use the same rule ON the webserver and I set up the clients and use the webserver as a router (192.168.1.100), the rule works!

There are no policies for accept, reject or drop other then are listed in the question. These policies do not have to be specified for the router to receive and route the packets. If they are not denied, then they are accepted.
0
 
LVL 19

Expert Comment

by:jools
ID: 24051487
I think you may need ip_forwarding enabled on the router.
# cat /proc/sys/net/ipv4/ip_forward
0
# echo 1 > /proc/sys/net/ipv4/ip_forward
# cat /proc/sys/net/ipv4/ip_forward
1
0
Enterprise Mobility and BYOD For Dummies

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.

 
LVL 2

Author Comment

by:itnifl
ID: 24051736
Thats offcourse done already via /etc/sysctl.conf: net.ipv4.ip_forward=1
And then updating: sysctl -p

Chedking:
cat /proc/sys/net/ipv4/ip_forward
1

So thats not the problem :)
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24054400
"If you read the question closely you will see that I am trying to route all web traffic from any client using 192.168.1.102 as a router".
How am I supposed to divine that from your Q? - the only mention of 192.168.1.102 is "iptables -t nat -A PREROUTING -p tcp -s 192.168.1.102 -j ACCEPT".
As I said before, you cannot expect the same rules that work on the system actually offering a service to work on another system.
Use tcpdump on each system to track how far the packets get; and if they reach their destination then track how far the return packets get. You'll find the problem.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24054426
(tcpdump sees packets before netfilter gets them - at least, that's been my experience)
0
 
LVL 2

Author Comment

by:itnifl
ID: 24057081
At the router (192.168.1.102) I now only set these rules:
iptables -t nat -A PREROUTING -p udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination

All http packages going to port 80 should be routed to 192.168.1.100 now.
From a windows client I ran Wireshark capturing everything on port 80. I then ran "tracert google.com."

Tracert shows that the packages reach the router 192.168.1.102, and then the internet gateway 192.168.1.101 and there it stops. The router is used as a gateway because it hosts several virtula networks that it routes between. The internet gateway is reached from there, since the internet gateway is a windows XP machine with a registry hack that lets it route I dont want to use it as a default gateway.

Anyway, in wireshark I see the packages littlebit differently:
192.168.1.206->174.133.198.138-TCP-61139 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1260
192.168.1.100->192.168.1.206-TCP-http > 61139 [SYN, ACK] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 WS=6
192.168.1.100->192.168.1.206-TCP-http > 61139 [SYN, ACK] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 WS=6

So the client, 192.168.1.206 tries to establish a connection through a 3-way handshake as normally done when TCP connections are set up[SYN], and the web server replies with an offer to connect [SYN, ACK]. But my client never acknowledges this [ACK]. And so it goes again and again until it stops.

Looks like my client was expecting an answer from 174.133.198.138 and because of that ignored replies for a connection from my web server(192.168.1.100). That explains why the rule works when I set the web-server as a default gateway in stead. Then the packages are actually a part of a conection with the web-server already(since it is also the gateway), and replies from the web-server are accepted.

Now, any way to fix that? I guess there could be done some more changes to the packages via iptables so that my client will accept replies from my web-server?
0
 
LVL 2

Author Comment

by:itnifl
ID: 24057087
Coorrection, the rule is: iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.100:80
0
 
LVL 2

Author Comment

by:itnifl
ID: 24057201
Its not too good that I cant edit my replies here. I forgot to mention that when running wireshark I ran it when actually trying to reach google.no from my explorer. I guess tracert does not use TCP port 80, so that explains why it reached the internet gateway. When trying to reach google.no from my browser however, things were littlebit different.

0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24058160
Yes I guess so - tracert sounds like the Linux / Unix utility traceroute which as I understand it sends ICMP packets with ever-increasing lifetimes towards the destination. It relies on responses from each node where the lifetime expires to give you a trace of where the call is going. As such, it would bypass your port 80 rules.
I've only used wireshark a little, and didn't pay a lot of attention to the detail, would the line:

192.168.1.206->174.133.198.138-TCP-61139 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1260

equate approximately to the tcpdump line:

IP 192.168.1.206.61139 > 174.133.198.138.http: S [other stuff]

It seems that your router is not source-natting the return packets. I'm not certain that that's necessary: the combination of destination IP/port is unique in the network so it should be sufficient for the client to process the packet. I wonder if the client has its own firewall which is blocking it?
On the other hand, the return packets claim to come from 192.168.1.100, *not* the firewall 192.168.1.102. Perhaps they did come from there - has that system still got IP forwarding turned on?
My suggestion now is that you use tcpdump on 192.168.1.102 on both the input and output interfaces (i.e. in 2 windows) and repeat the experiment.

Agree with you about not being able to edit - that would be a nice feature. Probably would have to be limited to only the poster being able to do it while there wasn't a newer post.
0
 
LVL 2

Author Comment

by:itnifl
ID: 24078885
The client has no firewall blocking the response. In that case all other http requests should be affected also, depending on the firewall rule. The client accesses internet normally via http if the iptable rules are turned off at the router. The client also accesses the web-server normally via http if the same rules are not implied(same situation as the last example). So it cant be the client.

Yes, the packets are indeed from 192.168.1.100. My theory is that the http packets get re-routed from the router(192.168.1.102) to the web-server(192.168.1.100). And the web-server tries to reply, but gets ignored.

The reason for this is as follows(correct me if I have forgotten my technical-theory):
Client: Tries to establish a TCP connection with google.no by starting a TCP-threeway handshake with the [SYN] flag. The packet gets routed to the web-server. Client is waiting a connection offer from google.no(TCP packet with the flags [SYN][ACK] marked).

Web-server(192.168.1.100): Receives the [SYN] request(asking to establish a TCP connection) and replies to the client with a [SYN][ACK] TCP packet. The web-server is now waiting for the third and last stage in this process, the acknowledge reply from the client. A TCP packet with the [ACK] flag set.

Client: Receives the [SYN][ACK] reply from the web-server, but ignores it. The client is waiting for a reply from google.no, and assumes that the connection offer from the web-server is bogus.

Server: Tries to resend the [SYN][ACK] connection offers, but never gets a reply from the client.
Here we stop, the connection is never established.

On the other hand, if I set the web-server as the router, the client already has a connection to the web-server as its router. That way, the connection failure, that we see here does not happen.

It is important to note that the router I want to use (192.168.1.102) uses the same physical network interface as the web-server. This is because the web-server is a virtual guest on my physical router, with its virtual NIC bridged to the already mentioned physical NIC(the share it with two different IP's and MAC's).

I include a "drawing" (if you can call it that) of my network, it will make it easier to understand.
Hope you have time to read this all and reply :)
Network.png
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24082293
Hi thanks for that - I did have time to look but not to figure out a good answer - have to leave for work now.
Just to be sure - network 192.168.8 has connected to it the client, web server and router. The router has 4 other network interfaces of interest - one to WIFI and one each to 10.1.2, 192.188.10, and 172.16.0 (or maybe 172.16). Is that right? -the labelling is a bit on the small side. Are your iptables rules still exactly as per Q? please re-post if not. The diagram says 172 but your rule says 174. Must go now
0
 
LVL 2

Author Comment

by:itnifl
ID: 24085733
Thanks for spending your time helping me. But you have to take a closer look. There is no 192.168.8.0 network.  I agree that the labelling is a bit on the small side. The rules does not say 174. That is the result of the wireshark sniff when I tried to access google.no.
192.168.1.206->174.133.198.138-TCP-61139 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1260
This means that the client (192.168.1.206) sends a [SYN] package to 174.133.198.138 (google.no). The [SYN] package is typical when establishing TCP connections via a so called three-way handshake. Please read my previous reply about this.

The IP table rules are just as before.

The network is like this:
The switch is a 5 port network switch with WIFI connection.
192.168.1.100 is the internet gateway connected to the switch.
192.168.1.102 is a vmware server with 1 and only 1 physical NIC. The vmware server hosts several virtual machines and virtual networks that it routes to. This server routes from the physical network to the virtual networks. It aslo hosts a vmware guest, a virtual machine(192.168.1.100) that is the web server. It shares the VMWare servers physical NIC(it is bridged to it). Please read my last reply more carefully. Hope this reply adds to it.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24085811
Sorry that was a typo for 192.168.1.0
0
 
LVL 2

Author Comment

by:itnifl
ID: 24085834
Yes, the 192.168.1.0 network is the only network directly connected to the client. This is the physical network that everything physical is connected to, except for the virtual web-server that also got the priviledge to be here (192.168.1.100). I am sorry, in the last reply I also mention 192.168.1.100 as the internet gateway. That was a mistake. 192.168.1.101 is the internet gateway and 192.168.1.100 is the vrtual web-server.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24086996
As the asker of a question, it is incumbent on you to make your question as clear as you can. Rather than thinking "he should look more closely", you should be thinking "how can I make my question more clear?". We experts have day jobs, and a life.
There are 2 items I would like you to post, in the "Attach Code Snippet" box please, so they display in monotype:
1. output from ifconfig on your router, showing the 5 interfaces.
2. All of your actual scripts that contain iptables commands, and on what system each script runs
Coincidence about 172 / 174 - as I said I am much more familiar with tcpdump output than with wireshark.
An observation:
192.168.1.206->a700sm.avast.com-TCP-61139 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1260
(I looked up the IP with dig)
Somehow (and that is why I want to see your scripts) (but probably because the frame gets to the router) your routing rules divert this frame to 192.168.1.100:80. There is no source natting, so 192.168.1.100 responds to the sending address 192.168.1.206. This is on the same network as 192.168.1.100 so the packet is delivered forthwith, with no routing. 192.168.1.206 is not expecting a SYN/ACK from 192.168.1.100 so ignores the response.
Did you really want to block access to the external site? You need more rules if so.
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24087030
(posted before I saw http:#24085834)
0
 
LVL 2

Author Comment

by:itnifl
ID: 24088171
Below is the info you wanted.
I guess I made a mistake when I pasted from wireshark. I will try again:
1-0.000000-192.168.1.206->74.125.77.103-TCP-50960 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=2
2-0.000599-192.168.1.100->192.168.1.206-TCP-http > 50960 [SYN, ACK] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 WS=6
3-1.602766-192.168.1.100->192.168.1.206-TCP-http > 50961 [SYN, ACK] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 WS=6

And so it goes over and over again.

nslookup 74.125.77.103
Non-authoritative answer:
103.77.125.74.in-addr.arpa      name = ew-in-f103.google.com.

For now I want to be able to let all http traffic get redirected to the web-server(192.168.1.100). I can add exceptions later. As mentioned earlier this works if I use the web-server as a default gateway for the clients. I want to be able to do it with the vmware server as the router and default gateway, to learn more about this.
ifconfig-192.168.1.102.txt
iptables.192.168.1.100.txt
iptables.192.168.1.102.txt
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24092526
Preliminary comments;
How can 192.168.1.102 be the router when it only has one physical interface? You need to have the iptables rules inside the cylinder with red arrows on it.
What was wrong with your previous arrangement that seemed to work for you?
0
 
LVL 2

Author Comment

by:itnifl
ID: 24094624
No, the cylinder with red arrows on it is just a switch. It has some possibillities of traffic control, but then I am not using IP-tables to control it. In the future I might want learn how to script changes to the firewall from some kind of interface request. I cant do that when using the switch.

192.168.1.102 can be the router, because it hosts several virtual networks that show as connected to it via virtual network cards. This router mostly routes between these networks. I cold also do the same with the web-server, after connecting it to all the virtual networks. The rules would be working then, as we discussed earlier.

I could just move the default gateway to the web-server, or make the router a web-server. What bothers me is that I have not learbed how to handle this kind of problem, so I have a hole in the my visionary "learning process" :p
0
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 24095682
The vmnet<n> addresses just appear when VMWare does bridging. We have them at work on our Windows systems hosting Linux. I have always thought they were best left alone. They are all private networks as per RFC1918 http://www.ietf.org/rfc/rfc1918.txt and none of them are the same as the real actual private network you use (192.168.1.0). Ifconfig run in the host does not show the guest external i/f 192.168.1.100, you only see that from ifconfig run in the guest. That is the same as my Windows experience (command is ipconfig there). You cannot do any useful routing in that box.
0
 
LVL 2

Author Comment

by:itnifl
ID: 24099929
This is littlebit off topic, but ok: That depends how you view useful routing, and how we define useful. When I set the host up as a router, and the host also is connected to all the virtual networks via its virtual NIC's it will route from my physical network to the virtual ones. Example: OrangeNet is the name of one of my virtual nets (10.1.2.0/24). I can choose to connect a virtual machine to that net. Lets say that this virtual machine gets the IP adress 10.1.2.3. Now I can reach that machine with the host as a router and default gateway from my physical net. What is the point of that? Learning. This is my home network, that I use to experiment. I know that the networks are all private, and they would never bee routed out on the internet. But it doesnt stop me from doing it here.

192.168.1.100 is bridged with 192.168.1.102 and does offcourse not show on the hosts list of NIC's. 192.168.1.100 acts as its own interface on my virtuaø web-server, just sharing the physical hardware of the host. But that really doesnt change anything. The host can still contact the virtual-web server in any normal way. I assume the host first gets the MAC of the IP address (192.168.1.100) via a ARP request broadcasted to the switch. When the host has the MAC adress he will send the packages to the switch and the switch I guess will send them back to the host, where the brilliant programmers at vmware have thought of the rest.

The bottom line is: What do I have to do so that I can redirect all web traffic on the network to 192.168.1.100 when using 192.168.1.102 as a default gateway and router?

Actually, I can admit it would be more logic to use 192.168.1.101 as a router and default gateway, since it is the internetgateway. The thing there is that this internetgateway is actually just a Win XP machine :) I could not get my mobile broadband modem to work under Debian, so I use my Win XP machine standin in the livingroom. The vmware host and router/defalut will now re-route all internet traffic from the clients to this internet gatewa if I do not se the ip-table rules we have already mentioned. The CP machine forwards the packages to the mobile broadband modem thanks to a registry hack. Theres no Ip tables on a Win XP computer, so I wont use that as the default gateway. And, yes I know its a security issue, but this network is for play and learning.

Back to bottom line:
What do I have to do so that I can redirect all web traffic on the network to 192.168.1.100 when using 192.168.1.102 as a default gateway and router?
0
 
LVL 34

Accepted Solution

by:
Duncan Roe earned 500 total points
ID: 24102495
I think you need to do SNAT, so that packets from wherever appear to come from the router. That way, hosts will return packets to the router which will mangle them back and return them to the originating host.
I do that on my "real" router - with the line in the box. You will need to do something different. Actually what you have to do is somewhat more complicated, because you only want to apply the rule to tcp port 80.
Also you are using the same NIC for input and output. I am hoping that will not cause a problem but I think you will be OK. From my reading of the man page, SNAT like all nat rules only triggers on connection initialisation (i.e.SYN w/out ACK). from then on the connection is tracked so appropriate rules are applied to every packet. Give it a go
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to $gateway

Open in new window

0
 
LVL 2

Author Comment

by:itnifl
ID: 24104892
Thanks, that worked! I have learned alot.
The final code of iptable rules for this purpose looks like below:
iptables -t nat -A PREROUTING -p udp --dport 53 -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp --dport 80 -o eth0 -j SNAT --to 192.168.1.102
iptables -t nat -A PREROUTING -p tcp -j DNAT --to-destination 192.168.1.100:80

Open in new window

0
 
LVL 2

Author Closing Comment

by:itnifl
ID: 31565677
Thanks again! Very helpful. See the comment below.
0

Featured Post

Tutorials alone can't teach real engineering

So we built better training tools.

-Hands-on Labs
-Instructor Mentoring
-Scenario-Based Tests
-Dedicated Cloud Servers

All at your fingertips. What are you waiting for?

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Linux users are sometimes dumbfounded by the severe lack of documentation on a topic. Sometimes, the documentation is copious, but other times, you end up with some obscure "it varies depending on your distribution" over and over when searching for …
I. Introduction There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial

690 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question