ipv4 options

odious1 · 08-31-2004, 06:46 AM

Does anyone know where I can find documentation on all those ipv4 options in the /proc/sys/net/ipv4 and in the ../all directory such as log_martians. I am trying to learn firewalling and have not found these items addressed anywhere. You see documentation that recomends this and not that but with no explanation.

Thanks,
Tom

ToniT · 08-31-2004, 07:48 AM

Have you checked through the advanced linux routing howto?

Capt_Caveman · 08-31-2004, 08:13 AM

These are my favorites:
http://www.securityfocus.com/infocus/1711
http://ipsysctl-tutorial.frozentux.n...-tutorial.html

chort · 08-31-2004, 10:53 AM

Or the ever popular
man ip
man tcp
man udp

odious1 · 08-31-2004, 05:43 PM

Thanks guys that was exactly what I was looking for yet I am still unable to solve my problem. I thought it had something to do with DNAT and it may yet prove to be the case but I am unable to figure it out.

PROBLEM#####
My webserver is behind my nat. Domains are properly resolving to my gateway. What I am trying to accomplish is to be able get web pages using other than the literal name. In other words I have to enter the private ip to fetch pages on my local http server, if I use the domain name it fails.

So what is happening, is it a routing issue somhow.

Thanks,
Tom

ToniT · 08-31-2004, 06:32 PM

Do you have to use private ip when you are in local net, or when you try to access your web-server from outside? If later, to where you have to put that private ip? To host: field in your http query?

Getting http requests to their destination consists of two parts: Reaching the right machine and talking to the correct virtualhost. Are you having problems with the first, or with the second part?

odious1 · 08-31-2004, 06:40 PM

I have to use the private ip from the local net only. From outside I can use the public ip or the domain name. And actually vitual hosting is when this became such a problem. I had gotten the users accustomed to using the local ip but with virtual hosting that only gets the default directory.

If i traceroute to my domain from the local net it makes one hop to the external ip. This seems right but it is almost as if it stops there.

Thanks

Capt_Caveman · 08-31-2004, 08:50 PM

Yeah, I've had that happen too. This trick works pretty well:

http://www.netfilter.org/documentati...-HOWTO-10.html

odious1 · 09-07-2004, 09:03 PM

Thanks, wish I had checked back sooner. This looks a whole lot easier than the dns solution I used. I am a little confused (will try and see) but if dns shows the name resolution to be a public ip how would the destination be an internal ip?

Code:

# 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

Tom

Capt_Caveman · 09-07-2004, 10:00 PM

Because the http traffic is then getting DNATed to the internal IP of the internal webserver.

The main crux of the problem is that the webserver then gets the packet from the NAT box that has the internal clients IP as the source address. When it serves the http request, it then sends a packet to that source address. Since it's on the same network, the webserver sends it directly to the internal client (skipping the NAT box entirely). The client is expecting an http response from the the external IP (it has no knowledge that the DNAT occurred) and instead gets a random response from the local webserver. Since it isn't expecting this response, it discards the packet or at least fails to associate it with the original connection attempt. So you end up with what looks like a triangle. The way around this is to trick the webserver to respond to the DNAT box instead, that way the packet can then be "un-DNATed" properly and the client gets back a packet that looks like it came from the external IP and all is good.

A good way to get your mind around this is to draw a diagram with the three machines and their IPs. Then follow the path the packet will take, keeping in mind the source and dest IPs at each hop. I tried to do an ASCII Art diagram of it, but I suck and it looked like a log cabin exploded instead, so you're on your own there.

ToniT · 09-08-2004, 05:12 PM

The prerouting rule is more important. Postrouting part is probably not an issue if you have direct access from web-server to the client (that is in your intranet). If yackages are passed through the box doing the NAT, it does un-natting implicitly; that postrouting rule just helps the packages to reach the nat-box.

Capt_Caveman · 09-08-2004, 11:03 PM

Postrouting part is probably not an issue if you have direct access from web-server to the client (that is in your intranet)

Actually that is the problem itself. The internal client sends packets to the external IP address, but is getting replies back from the local webservers IP. I looked around for a better explanation of this and came across this one by Oskar Andreasson:

Quote:

We want to publish our website via our Internet connection. We only have one IP address, and the HTTP server is located on our internal network. Our firewall has the external IP address $INET_IP, and our HTTP server has the internal IP address $HTTP_IP and finally the firewall has the internal IP address $LAN_IP. The first thing to do is to add the following simple rule to the PREROUTING chain in the nat table:

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP

Now, all packets from the Internet going to port 80 on our firewall are redirected (or DNAT'ed) to our internal HTTP server. If you test this from the Internet, everything should work just perfect. So, what happens if you try connecting from a host on the same local network as the HTTP server? It will simply not work. This is a problem with routing really. We start out by dissect what happens in a normal case. The external box has IP address $EXT_BOX, to maintain readability.

1. Packet leaves the connecting host going to $INET_IP and source $EXT_BOX.
2. Packet reaches the firewall.
3. Firewall DNAT's the packet and runs the packet through all different chains etcetera.
4. Packet leaves the firewall and travels to the $HTTP_IP.
5. Packet reaches the HTTP server, and the HTTP box replies back through the firewall, if that is the box that the routing database has entered as the gateway for $EXT_BOX. Normally, this would be the default gateway of the HTTP server.
6. Firewall Un-DNAT's the packet again, so the packet looks as if it was replied to from the firewall itself.
7. Reply packet travels as usual back to the client $EXT_BOX.

Now, we will consider what happens if the packet was instead generated by a client on the same network as the HTTP server itself. The client has the IP address $LAN_BOX, while the rest of the machines maintain the same settings.

1. Packet leaves $LAN_BOX to $INET_IP.
2. The packet reaches the firewall.
3. The packet gets DNAT'ed, and all other required actions are taken, however, the packet is not SNAT'ed, so the same source IP address is used on the packet.
4. The packet leaves the firewall and reaches the HTTP server.
5. The HTTP server tries to respond to the packet, and sees in the routing databases that the packet came from a local box on the same network, and hence tries to send the packet directly to the original source IP address (which now becomes the destination IP address).
6. The packet reaches the client, and the client gets confused since the return packet does not come from the host that it sent the original request to. Hence, the client drops the reply packet, and waits for the "real" reply.

The simple solution to this problem is to SNAT all packets entering the firewall and leaving for a host or IP that we know we do DNAT to. For example, consider the above rule. We SNAT the packets entering our firewall that are destined for $HTTP_IP port 80 so that they look as if they came from $LAN_IP. This will force the HTTP server to send the packets back to our firewall, which Un-DNAT's the packets and sends them on to the client. The rule would look something like this:

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP

Remember that the POSTROUTING chain is processed last of the chains, and hence the packet will already be DNAT'ed once it reaches that specific chain. This is the reason that we match the packets based on the internal address.

This is part of his awesome iptables tutorial which I would highly recommend: http://iptables-tutorial.frozentux.n...tml#DNATTARGET

odious1 · 09-10-2004, 10:27 PM

Man, thanks so much; great explanation.