Solved

Iptables routing

Posted on 2009-04-02
25
1,322 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
  • 13
  • 11
25 Comments
 
LVL 34

Expert Comment

by:Duncan Roe
Comment Utility
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
Comment Utility
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
Comment Utility
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
 
LVL 2

Author Comment

by:itnifl
Comment Utility
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
Comment Utility
"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
Comment Utility
(tcpdump sees packets before netfilter gets them - at least, that's been my experience)
0
 
LVL 2

Author Comment

by:itnifl
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 2

Author Comment

by:itnifl
Comment Utility
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
Comment Utility
Sorry that was a typo for 192.168.1.0
0
 
LVL 2

Author Comment

by:itnifl
Comment Utility
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
Comment Utility
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
Comment Utility
(posted before I saw http:#24085834)
0
 
LVL 2

Author Comment

by:itnifl
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
Thanks again! Very helpful. See the comment below.
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

In my business, I use the LTS (Long Term Support) versions of Linux. My workstations do real work, and so I rarely have the patience to deal with silly problems caused by an upgraded kernel that had experimental software on it to begin with from a r…
The purpose of this article is to fix the unknown display problem in Linux Mint operating system. After installing the OS if you see Display monitor is not recognized then we can install "MESA" utilities to fix this problem or we can install additio…
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

744 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

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now