1

We have a Linux virtual server running CentOS 4. There are two physical NIC's, 12 virtual NIC's and 12 IP addresses configured on the virtual NIC's. Traffic to the IP's on the virtual NIC's is routed to a single IP that's associated with the physical NIC. Therefore, our Apache webserver will not respond to the virtual host configurations for the other IP's on the virtual NIC's. None of us are Unix admins. But, we're guessing that there's something in IPTables that's causing this. Here's the content of IPTables that we think is the culprit:

-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports xxxx
-A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-ports xxxx

Are we correct in this assumption?

Here's the complete table:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 8011
-A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-ports 8001
COMMIT

*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT

# Disable timestamp requests
-A RH-Firewall-1-INPUT -p icmp --icmp-type 13 DROP
# End timestamp request

# Disable Bad Packets
-A RH-Firewall-1-INPUT - tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# End Bad Packets

-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8011 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8001 -j ACCEPT

#Begin TSM Client Port (1501)
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 1501 -j ACCEPT
#End TSM Client Port (1501)

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1512 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9494 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9495 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 4750 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1920 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1922 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8200:8299 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8300:8399 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 63335 -j ACCEPT

-A RH-Firewall-1-INPUT  -p  tcp  --dport  137:139  -j  ACCEPT
-A RH-Firewall-1-INPUT  -p  udp  --dport  137:139  -j  ACCEPT

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

2 Answers 2

0

I'm a bit confused about your question, but what i can tell is what the iptables statements are doing: every packet to port 80/443 (HTTP/HTTPS) is redirected to another port.

So the apache must listen on that port or the packets won't get to the apache.

The IP adresses of the packets stay untouched.

I suggest you talk to the guys, that did the setup and ask why they do that port redirection.

0
0

the REDIRECT target will modify the destination address of the packet to be one that is assigned to the interface that it came in on (i.e. it redirects the packet to itself)

This obviously means that the real destination is nuked and whatever it was actually bound for will never see it.

Naturally, that doesn't really guarantee that it's the source of your problem, consider providing full iptables-save information.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .