Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am experiencing something a little bit odd. I'm running OpenZV on a CentOS 5 server. It appears that on containers the source IP address that say Apache webserver sees a request from is the OpenVZ Host's IP address rather than the actual surfer's IP address. Any suggestions as to why this may be occurring?

This is my sysctl.conf:

# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.default.proxy_arp = 0

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# We do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

iptables-save output:

# Generated by iptables-save v1.3.5 on Sun Jan  3 15:23:59 2010
*nat
:PREROUTING ACCEPT [756200:49422664]
:POSTROUTING ACCEPT [903767:67426359]
:OUTPUT ACCEPT [369070:31874494]
-A POSTROUTING -m mark --mark 0x9 -j MASQUERADE 
COMMIT
# Completed on Sun Jan  3 15:23:59 2010
# Generated by iptables-save v1.3.5 on Sun Jan  3 15:23:59 2010
*mangle
:PREROUTING ACCEPT [12320704:7736523164]
:INPUT ACCEPT [384169:50094465]
:FORWARD ACCEPT [11926020:7685806944]
:OUTPUT ACCEPT [386465:36820058]
:POSTROUTING ACCEPT [12308944:7722398683]
-A PREROUTING -i eth0 -j MARK --set-mark 0x9 
COMMIT
# Completed on Sun Jan  3 15:23:59 2010
# Generated by iptables-save v1.3.5 on Sun Jan  3 15:23:59 2010
*filter
:INPUT ACCEPT [379753:49502640]
:FORWARD ACCEPT [11855492:7632198223]
:OUTPUT ACCEPT [386465:36820058]
:RH-Firewall-1-INPUT - [0:0]
COMMIT
# Completed on Sun Jan  3 15:23:59 2010

ip ro sh output:

68.168.248.39 dev venet0  scope link 
68.168.248.38 dev venet0  scope link 
68.168.248.37 dev venet0  scope link 
68.168.248.36 dev venet0  scope link 
68.168.248.35 dev venet0  scope link 
68.168.248.34 dev venet0  scope link 
68.168.248.33 dev venet0  scope link 
68.168.248.40 dev venet0  scope link 
208.89.162.96/27 dev eth0  proto kernel  scope link  src 208.89.162.114 
169.254.0.0/16 dev eth0  scope link 
default via 208.89.162.97 dev eth0 
share|improve this question

4 Answers 4

http://wiki.openvz.org/Differences_between_venet_and_veth

Make sure you're using Ethernet bridging for guests, rather than "nat at host level"

share|improve this answer
    
I am using venet. I'm not sure if this is "nat at host level" or not. –  Jerry Tunin Jan 3 '10 at 22:42
    
That is NAT at the host level. –  womble Jan 4 '10 at 0:43
    
I signed up at a VPS hosting provider and they are using venet. Appears the source IP addresses passing correctly in their setup so I'm still under the belief it's just something I'm missing in configuring. –  Jerry Tunin Jan 4 '10 at 4:30

Are you reverse NAT'ing into your container, or some other strange trickery?

I see this myself at work because we have Piranha based web load balancers at work, so when a request comes from a public IP I NAT into my web servers instead of exposing them to the Internet

share|improve this answer
    
Nope, just trying to do a simple venet setup is all. –  Jerry Tunin Jan 3 '10 at 19:28

Can you say (and attach the output):

iptables-save
ip ro sh

on your host?

Which distribution is this?

share|improve this answer
    
I have added the requested information. –  Jerry Tunin Jan 3 '10 at 22:38
up vote 0 down vote accepted

It appears that it all came down to having the mangle in iptables. Once that was removed everything appears to be working as it should. I'm not sure if this is a default CentOS setting or something that was set along the way. So if you are experiencing this run:

iptables -t nat -L
iptables -t mangle -L

And make sure that everything is cleaned out. Also check to make sure the changes are reflected in /etc/sysconfig/iptables so it doesn't re-occur on reboot.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.