[SOLVED] NAT 1-1 for Three Public IPs on Ubuntu

debianfan · 03-16-2010, 01:28 PM

Please check my revised post above. Let me know if you think my route tables possibly need more info. Thanks again.

win32sux · 03-17-2010, 02:02 PM

Sorry for the delayed response. I received your email and have also looked at your edited post. Since you've double-checked this with your ISP, let's proceed to have a look at what your log looks like when you attempt to start an SSH connection to the DNS server. Do this and then give it a shot:

Code:

iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: "

To spot the log entry, I recommend having a virtual terminal open with:

Code:

tail -f /var/log/messages

Of course, you could also just grep the file for the log prefix.

debianfan · 03-17-2010, 10:14 PM

Oh not a problem. Here is what happened as I walked through this process. I entered the first code sample:

Code:

iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: "

and then I entered the second code sample:

Code:

tail -f /var/log/messages

Then I tried to ssh into the nameserver remotely, which timed out.

However, when I looked at the results of the log file for any instance of FORWARD DROP: marker there was no sight of it. So I used grep to search the file, but it did not come back with anything either. I tried a wildcard search for that prefix and no luck either.

Then I tried to ssh into the nameserver by public ip address from the firewall itself, which connected. I am not sure why it worked from the firewall as opposed to remotely. Perhaps the public ip is not being routed to the firewall. Anyway, I am sorry I could not find that instance in the log file. What else might you recommend?

Thanks.

win32sux · 03-18-2010, 10:53 AM

You're sure you have IP forwarding enabled, right? I just noticed that in one of your previous posts the FORWARD chain hadn't registered any packets when you attempted to connect from the WAN side to the SSH daemon on the DNS server.

debianfan · 03-18-2010, 11:05 AM

Yup, I just double checked on my firewall using this command:

Code:

iptables -nvL

And I received this information for the forwarding rules:

Code:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp  --  eth0   eth1    0.0.0.0/0            192.168.21.45       multiport dports 443,80,22 state NEW 
    0     0 ACCEPT     tcp  --  eth0   eth1    0.0.0.0/0            192.168.21.46       multiport dports 993,585,465,443,143,80,25,22 state NEW 
    0     0 ACCEPT     tcp  --  eth0   eth1    0.0.0.0/0            192.168.21.47       tcp dpt:22 state NEW 
    0     0 ACCEPT     udp  --  eth0   eth1    0.0.0.0/0            192.168.21.47       udp dpt:53 state NEW 
    0     0 ACCEPT     tcp  --  eth0   eth1    0.0.0.0/0            192.168.21.48       tcp dpt:22 state NEW 
    0     0 ACCEPT     udp  --  eth0   eth1    0.0.0.0/0            192.168.21.48       udp dpt:53 state NEW

win32sux · 03-18-2010, 11:07 AM

Right, but to check if IP forwarding is enabled do a:

Code:

cat /proc/sys/net/ipv4/ip_forward

debianfan · 03-18-2010, 11:12 AM

Well what do you know, that is still at 0. I will check my script and see if there is an error there and get back to you shortly. Thanks again, very good catch.

debianfan · 03-18-2010, 11:16 AM

Ok, it appears like the correct command is in the script at the end of the script:

Code:

echo 1 > /proc/sys/net/ipv4/ip_forward

but for some reason it is still remaining at 0 after reboot. Perhaps I need to change the entry in the init.d file as well?

Thanks.

win32sux · 03-18-2010, 11:17 AM

Quote:

Originally Posted by debianfan

Well what do you know, that is still at 0.

Heh, well, that explains quite a bit.

Quote:

I will check my script and see if there is an error there and get back to you shortly. Thanks again, very good catch.

I've got my fingers crossed over here on my end, hoping this was the only issue holding you back!

win32sux · 03-18-2010, 11:21 AM

Quote:

Originally Posted by debianfan

Ok, it appears like the correct command is in the script at the end of the script:

Code:

echo 1 > /proc/sys/net/ipv4/ip_forward

but for some reason it is still remaining at 0 after reboot. Perhaps I need to change the entry in the init.d file as well?

Thanks.

The command in the script isn't intended to have that setting survive a reboot. The first echo disables forwarding while the rules are being set up. The second echo is there to re-enable forwarding since at that point everything is ready. The IP forwarding setting isn't saved to the iptables configuration file (/etc/firewall.txt in this case), which is why you need to handle it on your own. Post #7 (as well as #6) explains the recommended way of making the setting stick.

debianfan · 03-18-2010, 11:26 AM

Ahhhhh, very good to know. You just made my day if that was it. I will change that startup file shortly, and get back to you soon. Thanks.

debianfan · 03-18-2010, 02:24 PM

Alright! I was able to connect remotely through the SSH daemon to the internal nameserver through the firewall. It was just a forwarding issue apparently. Now to get out to the internet from the internal nameserver you mentioned I needed to set up specific forwarding rules from the internal box, is that correct?

Thanks again.

win32sux · 03-18-2010, 02:35 PM

Quote:

Originally Posted by debianfan

Alright! I was able to connect remotely through the SSH daemon to the internal nameserver through the firewall. It was just a forwarding issue apparently. Now to get out to the internet from the internal nameserver you mentioned I needed to set up specific forwarding rules from the internal box, is that correct?

Thanks again.

Happy to hear that!

Yeah, basically you just gotta decide what sort of outbound connections (and to what destinations, if feasible) you want to allow from that server. Say, for example, that you want that server to be able to ping any box on the WAN (probably not a good idea). For that, you'd just add a line like this to the relevant section of the script:

Code:

$IPT -A FORWARD -p ICMP -i $LAN_IFACE -o $WAN_IFACE -s $SERVER_3_LAN_IP --icmp-type 8 \
-m state --state NEW -j ACCEPT

Let's say you wanted this box to be able to connect to HTTP servers on the WAN (again, probably not a good idea). That might go like:

Code:

$IPT -A FORWARD -p TCP -i $LAN_IFACE -o $WAN_IFACE -s $SERVER_3_LAN_IP --dport 80 \
-m state --state NEW -j ACCEPT

If you only wanted to let it connect to one particular HTTP server, just add the HTTP server's IP:

Code:

$IPT -A FORWARD -p TCP -i $LAN_IFACE -o $WAN_IFACE -s $SERVER_3_LAN_IP --dport 80 \
-d 75.126.162.205 -m state --state NEW -j ACCEPT

And of course, if you want to allow this server to do anything on the WAN (not recommended):

Code:

$IPT -A FORWARD -i $LAN_IFACE -o $WAN_IFACE -s $SERVER_3_LAN_IP -j ACCEPT

Please note that I'm assuming that the server in question is $SERVER_3_LAN_IP in the script, but I don't remember if that's the case. Just replace that variable with the appropriate one if necessary.

debianfan · 03-18-2010, 02:42 PM

Sounds good, so if I am planning to use the DNS server to provide both internal DNS name resolution and external DNS name resolution. And I want it to basically pass out DNS requests to any machine internally or externally, as well as be able to contact the ubuntu update servers should I use something like below:

Code:

$IPT -A FORWARD -p UDP -i $LAN_IFACE -o $WAN_IFACE -s $SERVER_3_LAN_IP --dport 53 \
-m state --state NEW -j ACCEPT

$IPT -A FORWARD -p TCP -i $LAN_IFACE -o $WAN_IFACE -s $SERVER_3_LAN_IP --dport 80 \
-m state --state NEW -j ACCEPT

And likely a basic question, but never hurts to ask to make sure. This is all being done on the internal nameservers iptables configuration as opposed to the firewall iptables configuration correct?

Thanks.

win32sux · 03-18-2010, 03:00 PM

Looks good to me (beware your typo, though), just make sure that the outbound traffic you're allowing is absolutely necessary (for example, do you really need this box to send it's own outbound packets with destination port 53/UDP to any box on the WAN?). This reduces the damage which your server can do on the WAN side when it gets owned, which consequently reduces the amount of legal risk (among other types) you incur. Also, when allowing outbound connections, always try to make them as specific as possible. For example, if you know the IPs of the Ubuntu update servers then you'd wanna stick matches for those IPs in the rules. Otherwise, this server can be used to attack any service on any IP on the WAN/Internet listening on port 80/TCP.

Quote:

Originally Posted by debianfan

This is all being done on the internal nameservers iptables configuration as opposed to the firewall iptables configuration correct?

No, this is all happening on the dedicated firewall. Your DNS box shouldn't even have a functioning FORWARD chain, as it's not doing IP forwarding. On the DNS box, everything is handled in the INPUT and OUTPUT chains, which should have its own rules, somewhat similar to the firewall box's (to act as a second layer of defense). It's vital that the iptables configuration on your LAN boxes is tight, as the dedicated firewall will be of no use within the LAN when one of the boxes is owned. Basically, you should assume that any of the boxes on your LAN will be used to attack the other boxes on the LAN.