HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Technical (http://www.howtoforge.com/forums/forumdisplay.php?f=8)
-   -   IPTables Masquerading Issue (http://www.howtoforge.com/forums/showthread.php?t=53632)

johncongdon 2nd August 2011 17:43

IPTables Masquerading Issue
 
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?

Mark_NL 3rd August 2011 14:39

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.

johncongdon 3rd August 2011 17:51

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 :(

Mark_NL 3rd August 2011 17:56

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

johncongdon 3rd August 2011 18:56

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
Quote:

root@PSWEBNODE1 [~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain acctboth (0 references)
target prot opt source destination
root@PSWEBNODE1 [~]# cat /etc/redhat-release
CentOS release 5.6 (Final)
Output from B
Quote:

[root@psfw1 ~]# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:46:49.508565 IP 10.0.73.11 > MachineC: ICMP echo request, id 36931, seq 1, length 64
11:46:49.528951 IP MachineC > 10.0.73.11: ICMP echo reply, id 36931, seq 1, length 64
11:46:50.508192 IP 10.0.73.11 > MachineC: ICMP echo request, id 36931, seq 2, length 64
11:46:50.529028 IP MachineC > 10.0.73.11: ICMP echo reply, id 36931, seq 2, length 64

4 packets captured
4 packets received by filter
0 packets dropped by kernel
[root@psfw1 ~]# tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:46:53.507654 IP MachineB_PublicIP > MachineC: ICMP echo request, id 36931, seq 5, length 64
11:46:53.527257 IP MachineC > MachineB_PublicIP: ICMP echo reply, id 36931, seq 5, length 64

2 packets captured
2 packets received by filter
0 packets dropped by kernel
Output from C
Quote:

[root@squishy scanner]# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:47:18.171359 IP MachineB_PublicIP > MachineC: icmp 64: echo request seq 74
11:47:18.250561 IP MachineC > MachineB_PublicIP: icmp 64: echo reply seq 74

2 packets captured
2 packets received by filter
0 packets dropped by kernel

Franz 3rd August 2011 19:41

did you configure this on machine B?

Code:

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

johncongdon 3rd August 2011 20:43

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.

Mark_NL 3rd August 2011 21:56

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

johncongdon 3rd August 2011 23:44

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.

Mark_NL 4th August 2011 00:05

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 ;)


All times are GMT +2. The time now is 06:40.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.