I have setup masquerading dozens of times with no issues. I have 2 linux boxes (A=Private, B=Masquerader) Here are the checks I have done A - Default gateway is B B - iptables is wide open with 1 postrouting statement iptables -t nat -A POSTROUTING -s 10.0.73.11 -j SNAT --to-source PUBLIC_IP B - IP Forwarding is enabled. I can ping from A to B's private address. Cannot go past that. If I run iptraf on B, I can see the ping req/reply from A to another IP. If I ssh from A to another machine outside the firewall, I can see the connection attempt with netstat -an | grep :22 on the remote machine. So the connection are being transmitted out correctly, but not getting returned correctly through SNAT. Any ideas?
why do you SNAT? for a simple and fast gateway you should do this: set net.ipv4.ip_forward to 1 (/etc/sysctl.conf, then run: sysctl -p) iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE eth0 being your external interface (wan connection). That's it.
I have done that as well. Both give me the same results. The SNAT was a last attempt and something that I read was "more secure" than just masquerade. Either way, the end result was the same
If my solution doesn't work, then there is something you haven't told us about your setup. A -> B -> C you're able to ping C unless "C" is dropping stuff A: ping c B: tcpdump -i eth0 icmp C: tcpdump -i eth0 icmp now see what packets go back and forth on B and C
I wish I was not telling you something. That's why I tried to be very specific in my setup and testing that I have done. I have setup simple masquerading before, should not be this difficult. I also made sure selinux was off, in case that was the issue. I can ping from A to the private side of B, so ping is not being blocked on A. I also went back to your suggestion of iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE, and I get the same results. I see the ping request/reply on C (in your example). I see the ping request/reply on B ( on both eth0 and eth1 ) The firewall on A is default open Output from B Output from C
Yes, sorry, I thought I included that in my first post, guess not. The packets are being forwarded, as you can see, machine C (which is across the Internet, not local) is getting requests and replying. Very very strange. I'm wondering if there is some other type of firewall on CentOS that I am unaware of.
It looks clear to me that the icmp responses are being send back to A. Code: 11:46:49.528951 IP MachineC > 10.0.73.11: ICMP echo reply, id 36931, seq 1, length 64 Do the test again, but this time, open up another connection to machine A and start a tcpdump on it and filter icmp. Do you see icmp responses on machine A when you have tcpdump running on it? to be sure, run this on machine A and B and show us the results: Code: iptables-save
Just received additional information. These are virtual servers. Do you think there is something in a virtual environment that could stop this type of traffic? -------Private Network-------- | | | | A B | | ----Public Network 1 ------Public Network 2 I guess Public Network 1 is a higher cost bandwidth. A and B are virtual servers connected to the same private network.
If the physical server is configured properly, then it shouldn't be any problem. I've a VM gw as well and other vm's have no problem getting data through it. Though the awesome acsii art you just drawn ... i've no idea what it is. but back on topic: From the tcpdumps you supplied, we've seen traffic going from: A -> B -> C -> B I'm missing the tcpdump from A when you ping from A to C. If the underlying physical host is misconfigured it could be that the pings aren't received on your host A .. but first, show me a tcpdump from A
ARGH, My ascii art got messed up In words, A connects to another more expensive pipe. So my client wants to connect to the server through B on a cheaper internet connection. Here is the tcpdump from A.
ahhhh, so: A -> C goes over line B C -> A goed over line A That could mess things up. Also the tcpdump shows you the replies are not reaching A. They do reach B, but B want to send them over another line to A ? Though i think i understand your ASCII art now ;-) - A and B are both connected to the same internal private network. - A is connected to external net 1 - B is connected to external net 2 - C is connected somewhere completely different (on the other side of the world f.e.) Show me: - iptables-save (server A and B) - route -n (server A and B)
I was just informed that the physical machine was put in and worked right away. Turns out there was an ACL in the virtual environment that I had zero control over. I'm not crazy... Yipee! Thanks for trying.
I have done that as well. Both give me the same results. The SNAT was a last attempt and something that I read was "more secure" than just masquerade.
