Re: DNAT iptables bug or connection tracking issue?

[Josh Cepek <josh.cepek@xxxxxxx>]

Irmãos Bocchi & CIA Ltda wrote:
> 1) I have two routers in two different networks: one is a FreeBSD 7.0 
> router, here called "Router A" and another is a Debian 4.0 router, 
> here called "Router B"
> 2) The Router A uses pf to make the firewall rules, with standard 
> installation. The Router B have the kernel 2.6.25.4 and iptables 1.4.0
> 3) In the first router, I have a rule to access my vnc server in a 
> windows machine. To make these, I need to create this rule
> rdr on sk0 proto tcp from any to <my external addr> port 5900 -> <my 
> internal addr> port 5900
> nat on sk0 proto tcp from <my internal addr> port 5900 to any -> sk0
>
> In resume: I need to create a rule to make the redirection and, after 
> these, I need to insert a rule to make the nat
>
> 4) In the second router, only adding this rule
> iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 5900 -j DNAT 
> --to-destination <my internal addr> port 5900
>
> THE RULES WORK PERFECTLY!
>
> It's a bug? Because, in my vision, I need to create the two rules, the 
> DNAT rule and the MASQUERADE rule to these work.

Typically when you have a LAN behind NAT you use either MASQUERADE or 
SNAT on all packets going out the public interface.  It doesn't make 
sense to do so only for certain packets; if you intend to filter traffic 
to prevent it from going out to the Internet you should do so in the 
filter table, not by preventing NAT from occurring (which won't 
necessarily stop the packet from being forwarded.)

> Another point of view: If I need to permit only the machines A, B and 
> C to access the VNC, in BSD, I only need to create these rules
>
> my_servers="{ server_a_addr, server_b_addr, server_c_addr }"
> rdr on sk0 proto tcp from any to <my external addr> port 5900 -> <my 
> internal addr> port 5900
> nat on sk0 proto tcp from <my internal addr> port 5900 to $my_servers 
> -> sk0
>
> or
>
> rdr on sk0 proto tcp from $my_servers to <my external addr> port 5900 
> -> <my internal addr> port 5900
> nat on sk0 proto tcp from <my internal addr> port 5900 to any -> sk0
>
> How I can make these in iptables?

The easiest way is probably to create a user-defined chain containing 
tests for the IP's you want to allow to connect to this port.  If you 
include a rule to allow ESTABLISHED traffic prior to the jump to 
vnc_access only the first packet in the connection will need to traverse 
the list of IP's to allow.  Something like this should accomplish the 
task (along with the NAT rule you listed above):

iptables -N vnc_access
iptables -A vnc_access -s server_a_addr -j ACCEPT
iptables -A vnc_access -s server_b_addr -j ACCEPT
iptables -A vnc_access -s server_c_addr -j ACCEPT
iptables -A vnc_access -j DROP

[... other rules may go here ...]

iptables -A FORWARD -d <internal addr> -p tcp --dport 5900 -j vnc_access

If you have many IP's you want to add to the vnc_access chain, another 
way to write that first portion by using a bash for-loop might be as 
follows:

my_servers="server_a_addr server_b_addr server_c_addr"
iptables -N vnc_access
for ip in $my_servers; do
   iptables -A vnc_access -s $ip -j ACCEPT
done
iptables -A vnc_access -j DROP

For many hundreds or thousands of IP's you probably want to look at 
ipsets for a performance increase when processing that many rules.

Finally, note that this will only cause packets to be dropped that are 
sourced from IP's not in your list.  The standard VNC protocol has 
inherently weak security and would still be vulnerable to a 
man-in-the-middle attack potentially exposing your VNC password.  An 
encrypted tunnel such as a VPN or ssh port-forwarding would secure the 
VNC data cryptographically.

--
Josh

Attachment: signature.asc
Description: OpenPGP digital signature