[SOLVED] CentOS 5.8 NAT router icmp unreachable admin prohibited problem

kenneth_phough · 08-08-2012, 08:20 AM

Hi,

I have a CentOS 5 set up as a NAT router between network A and Network B in a test environment, like so:

eth0 (NETWORK B) <==> CENTOS <==> eth1 (NETWORK A)

I have set up ipv4 forwarding and have added(what I think) are the correct entries in iptables. NETWORK A is our "Internet" in this test environment. CENTOS is set to provide DHCP service only on eth0 for NETWORK B computers as well as NAT functionality. But I have two problems (one on the first day, another on the second day...got no where on the third...):

Day 1) When I permit forwarding from eth0 to eth1 and postrouting masquerade, I cannot connect from any computer in NETWORK B to services (web, ssh, ftp, etc) on NETWORK A. The computers on NETWORK B are assigned the correct IP, subnet, gateway, and dns. So I pinged a few public IPs including: google.com and opendns.com and get replies. This seemed sugesstive of a DNS problem, so I manually set my DNS on one of my computers on NETWORK B to use opendns and still no name resolution. The next thing I did from NETWORK B was a traceroute for the public IP of google.com. Nothing! It goes to the gateway (the CentOS 5.8) and stops there with a !Z. I next did a tcpdum on the CentOS 5.8 gateway and found what looks like icmp requests to nameservers (charter, opendns, verizon, etc) resulting with an "unreachable - admin prohibited". I then disabled iptables completely, and bingo! I can connect to services in NETWORK A from computers in NETWORK B...(but leaving iptables off is maybe one of the last things I want to do). However, even with iptables off, I still noticed in the tcpdum a significant number of "unreachable - admin prohibited", which I can definitely experience when browsing the web - it's VERY SLOW and often times results with a timeout exception. What could be causing this? Is this normal activity? I'm starting to wonder if my box is incapable of keeping up with the workload - doubtful but here are the specs: it's has a Intel Pentium 2.7Ghz(Intel Pentium G630 Sandy Bridge 2.7GHz LGA 1155 65W Dual-Core Desktop Processor Intel HD Graphics BX80623G630 - http://www.newegg.com/Product/Produc...82E16819116406) and 4GB of RAM. Both NICs are 1Gbps.

Day 2) I thought maybe if I use the system-config-network-tui to configure the firewall, test the system to make sure it works and look at the generated config files I can better understand what I need to do to make my CentOS NAT work. So I went ahead with the guided system-config-network-tui and set both eth0 and eth1 as trusted and masqueraded. Saved the config and restarted iptables. This seemed to work! I was able to access services on NETWORK A from NETWORK B. But there are two problems with this: 1) The generated config file means gibberish to me (I most likely need to go back to my iptables book to remind my self what some of the options mean), and 2) the "unreachable - admin prohibited" problem in my tcpdump is not resolved. And once again I can expereince it when browsing the web - it's VERY SLOW and often times results with a timeout exception.

Day 3) head...banging...against...wall...

I apologize in advance for the long post and not providing any logs or config files. I'm posting this from work where I do not have remote access to my box at home. This has been on my mind for three days now and I can't seem to find anything from my searches. Any help is much appreciated!

Thanks,
Ken

kbp · 08-08-2012, 07:19 PM

Lets start at the start .. in plain english what exactly do you want to achieve? .. are you simulating connecting a private (RFC1918) network to the internet ? .. are you wanting to provide access from the (simulated) internet to specific services on the private network ?

kenneth_phough · 08-08-2012, 07:24 PM

Quote:

are you simulating connecting a private (RFC1918) network to the internet ?

Yes. My hope is to eventually make this CentOS box a firewall/gateway that will directly connect to my cable modem.

So something like this

My home network <===> CentOS Gateway/Firewall <===> Cable Modem

kbp · 08-08-2012, 09:07 PM

Lets get basic source NAT working first - perform these commands on the console not remotely

Enable ip forwarding:

Code:

perl -pi -e 's|^net\.ipv4\.ip_forward.*|net.ipv4.ip_forward = 1|' /etc/sysctl.conf
sysctl -p

Flush the current iptables rules:

Code:

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -F -t nat

Set policies:

Code:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Add iptables NAT rules, these rules assume that eth1 connects to your private network and eth0 is your external interface:

Code:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Allow all traffic on eth1 and loopback:

Code:

iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

Make the rules permanent in whichever way you please, possibly:

Code:

iptables-save > /etc/sysconfig/iptables

I haven't tested these commands but they're pretty straight forward. Hosts on the private network should have the firewall host as their default gateway and should be able to connect to the firewall itself or external hosts - please test and get back to us.

kenneth_phough · 08-08-2012, 09:53 PM

Commands executed on a fresh CentOS 5.8

eth0 faces external network DHCP (192.168.1.0/24) Gateway 192.168.1.1
eth1 faces private network Static (192.168.2.0/24)

Below is the physical setup:

|---------PRIVATE NETWORK:eth1----------|-------eth0:EXTERNAL NETWORK--------|-------------INTERNET
iBook G3 <=====> SWITCH <=====> CentOS NAT <=====> SWITCH <=====> ROUTER <====> MODEM

I did a ping for my centos eth1: 192.168.2.1, which worked.

I did a ping for my gateway (192.168.1.1), which didn't work.

Quote:

Elena:~ kenneth$ ping 192.168.1.1
PING 192.168.1.0 (192.168.1.1): 56 data bytes

I don't hear back....

tcpdump shows echo from 192.168.2.254 (my iBook) to the router on the external network (192.168.1.1).

I can also see both switches flickering as the ICMP requests are being sent.

Below is my iptables after running the commands:

Quote:

# Generated by iptables-save v1.3.5 on Wed Aug 8 22:39:17 2012
*nat
:PREROUTING ACCEPT [54:4241]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [2:140]
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Wed Aug 8 22:39:17 2012
# Generated by iptables-save v1.3.5 on Wed Aug 8 22:39:17 2012
*filter
:INPUT ACCEPT [9:930]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [29:2771]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Wed Aug 8 22:39:17 2012

Also to confirm ip forwarding is enabled:

Quote:

[root@localhost ~]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

kbp · 08-08-2012, 10:34 PM

Quote:

-A POSTROUTING -o eth1 -j MASQUERADE

.. looks like you put the wrong interface in, should be eth0.

kenneth_phough · 08-09-2012, 08:14 AM

Wow, that is my bad. I forgot that I had switched interfaces three days ago to eth1 -> internal and eth0 -> external....it used to be eth1 -> external and eth0-> internal because of the way the NIC cards were plugged in).

Thank you so very much! It all works now!

Ken