Programming iptables rules for 1:1 NAT
 

Hello all,

I am trying to program iptable rules for implementing a 1:1 NAT which does the following:

1. Forward all traffic from all ports on a public ip to a private ip
2. Forward traffic from a range of ports (x-->y) on a public ip, to a private ip

I did some google searches for the same, and came up with the following. I would appreciate it if someone could validate if this is indeed what I need to be doing.


iptables -A FORWARD -t filter -o eth0 -m state \
--state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -t filter -i eth0 -m state \
--state ESTABLISHED,RELATED -j ACCEPT

Thanks

AJ

This is pretty cool stuff and good info to learn; so I am going to take the 'teach a person to fish versus give them a fish' outlook.

If you are trying to use your Linux box as a gateway, which is what it sounds like, you are going to have to do a bit more.

Start looking at the 'nat' table, 'postrouting chain', 'masquerading', and 'ip forwarding'. <-- good google terms

howtoforge - nat_iptables <-- place to start

Alright, I did some research, and came up with this:

Please note that the system has iptable rules already in place, so I need to add mine for 1:1 NAT and not worry about configuring VIFs.

iptables -t nat -A PREROUTING -i ${ext_interface} -d ${ext_ip} -j DNAT –to-destination ${int_ip}

iptables -t nat -A POSTROUTING -o ${ext_interface} -s ${int_ip} -j SNAT –to-source ${ext_ip}

Does anyone see any issues in this?

Looks good to me. Regarding this, though:I think it's a bad idea to allow all outbound packets in state NEW. That is, unless that's your intention. Are these forwarded packets going to a client or a server? Or perhaps a client that will be running certain daemons? I'd start out with something like this (example):...then tighten/loosen the restrictions as desired. In this example ports 5700-6890/TCP are forwarded to the internal host, while said host is only allowed to start outbound connections to the standard HTTPS, HTTP, and FTP ports.

Just my :twocents:.

I am a bit confused now ...

For my 1:1 NAT feature, should I be using the PREROUTING/POSTROUTING sample I posted, or use the original FORWARD sample?

You need both. Your PRE/POSTROUTING looks good, but your FORWARD needs work. I just re-read your post and it seems you're working with two different external IPs. Is that correct? Please elaborate. Also, please explain what outbound packet restrictions you want.

I am working with only "one" external IP. Essentially, I want to achieve the following ...

1. Have rules in my router, which forward all traffic from my public ip (from all ports), to a private ip which is hidden to the external world (but visible to my router)

2. Have rules in my router, which forward traffic from "specific port range" for my public ip, to a private up which is hidden to the external world (but visible to my router)

I do not think I have any restrictions for the outbound packets, except that all public ips should be pingable from this private ip via my router.

Also, when I try and program the prerouting/postrouting part, I do not see the rules in my iptables. Is there any step I miss here?

Okay, but these two requirements aren't compatible. I mean, if you only want to forward a "specific port range", then you aren't gonna be forwarding "all traffic from my public ip (from all ports)". That's why it sounds like you've got more than one external IP. So if you only have one, you need to decide which of the above you want to achieve.

Okay. After your next reply I think we should be able to offer you some iptables commands.

Are you specifying that you wish to see the NAT table? Example:

Ok, I am sorry I was not clear, but I provide an option to the user to either give me a port range and a source and destination ip, or just a source and destination ip. Both these count towards my 1-1 NAT user-cases. These are 2 separate cases based on what the user decides to do.

I agree that it might not be possible to do this in 1 command, but I can have branching in my code to make separate calls for either case. How would I go about programming my rules, given this information?

OIC, yeah, that makes sense now. :)

For the first case, you could do:For the second case, you could do:In the second case, you might want to turn the protocol match into a variable also, in case you're letting the user select between TCP and UDP.

Thanks a bunch for your help. I really appreciate it. I will try out these commands.

Hi, I tried to program the iptable and then run a simple test of trying to ssh the guest vm (and the guest ip i have), via my public ip. (for thr 1-1 NAT case -- all ports)

eg. (public ip: 192.168.30.43 , guest Ip : 10.1.1.2, external if: eth2 internal if: eth1)

iptables -t nat -A PREROUTING -i eth2 -d $publicIp -j DNAT --to-destination $guestIp
iptables -t nat -A POSTROUTING -o $eth2 -s $guestIp -j SNAT --to-source $publicIp
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $eth2 -o $eth1 -d $guestIp -m state --state NEW -j ACCEPT
iptables -A FORWARD -i $eth1 -o $eth2 -s $guestIp -m state --state NEW -j ACCEPT

Then, I tried something like:

aj@aj-laptop:~$ ssh root@192.168.30.43
ssh: connect to host 192.168.30.43 port 22: Connection timed out
aj@aj-laptop:~$

I am not really sure as to how to go about debugging this issue. I assume if everything worked fine, I should have been able to ssh into the machine via it's guest ip (10.1.1.2), accessed via the public ip

Are you sure you don't have any other (potentially conflicting) rules active? Maybe post the output of:BTW, you can slap a LOG rule onto the end of the FORWARD chain to see if packets are being filtered there:

Re-running. Had used the wrong eth (1 instead of 0)

aj@aj-laptop:~$ ssh root@192.168.30.41
ssh: connect to host 192.168.30.41 port 22: No route to host
aj@aj-laptop:~$

I've added CODE tags to your post in order to add readability.

Going forward, please use CODE tags on your own.

Well, the policy isn't getting hit so that's good. The rule which allows the handshake to start is getting hit, which is good too. No packets in state ESTABLISHED seem to be passing through here, though, which is bad.

The first POSTROUTING rule conflicts with the second one. That is, packets exiting eth2 will get their source address changed to 192.168.30.45, regardless (the 192.168.30.41 rule doesn't stand a chance). To fix that, just invert the rule order. But still, that doesn't seem to be the underlying cause of your issue, since neither rule is getting hit.

I must ask: Are you sure that the SSH box (10.1.1.2 AFAICT) is properly setup? It seems to me that having the gateway address on it improperly configured could cause these very symptoms. Let us know.

BTW, have you tried killing this jump to check if the problem resides in NETWORK_STATS?

Thanks a lot for all your help. I was able to get this working finally. I was using an iso, and had some configuration issues for my vm (internal issues). After re-configuring my vm using a template, I was able to ssh from my public ip into the vm. This was the test case I tried to ensure the rules worked fine.