Confirm: letting certain packages pass through un-natted

Hello!

Could somebody please confirm whether or not I'm doing this right?

I am using, in my nat table:

-A PREROUTING -s 192.168.0.0/16 -d 192.168.1.1 -j ACCEPT

Shouldn't all packets, including ICMP packets, get passed through to 192.168.1.1 if originating from the local network?

BTW, I'm not sure why I can communicate with the 192.168.2 subnet, but not my 192.168.1 subnet... Only the machine directly connected to 192.168.1.1 is able to communicate with it...

My routing table looks like this:

bla bla bla
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
bla bla bla

which seems correct.

So, I'm not so sure why this isn't working...

Any hints?

Thanks!!!

Dave

IMO only if there's no rule on top of this one that does NAT. Is there ? In that case this rule will never be reached.

What do the byte counters for this rule say when you execute :
iptables -nvL PREROUTING

Did you tcpdump anything to see what's going on ?
Not having your complete routing table and ruleset it's hard to tell if everything is setup correctly.

Gr,
Rob

Thank for for the quick reply! (For some reason, I didn't hit "send" yesterday...)

Nope. It's the first rule in the NAT table.

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -s 192.168.0.0/255.255.0.0 -d 192.168.1.1 -j ACCEPT -A PREROUTING -p tcp --dport 443 -j DNAT --to 192.168.2.2:443 etc...

Hmmm... weird...

[root@sannomiya ~]# iptables -nvL PREROUTING
iptables: Table does not exist (do you need to insmod?)

I tried that. Apparently, the packets get routed to 192.168.2.1 as expected, so they must be getting eaten up by my iptables... I'll take another look to try to figure out why.

Not at all ; my mistake : I forgot to add "-t nat" in the rule.

Check out Jörg's reply.
If the setup in his reply represents yours, is it really necessary to do NAT for 192.168.1.0/24 to reach 192.168.2.0/24 ?
I'd say you should be able to reach 192.168.2.0/24 using routing only (when FORWARD policy is ACCEPT and doesn't do filtering and ip_forward is set to "1").

Gr,
Rob

David Leangen napisał(a):

Not necesarily.
Even if you pass the packet in nat table, you still might drop it in filter table. I know the ACCEPT target may be used in every (?) table, but it's a matter of good practice to filter packets in filter tables and nat in nat tables and so on. So I would suggest moving this from nat table to filter table and from PREROUTING to FORWARD.

Hello!

Good point... I'll do just that. Thanks!!

BTW, where can I find out more about "good practices"?

Ok, I'm obviously doing a horrible job at troubleshooting...

Here's the gist of my iptables rules on my router box 192.168.1.2/192.168.2.1. I'm trying to figure out why machines on my local network can't communicate with 192.168.1.1.

BTW, don't even ask about the entries in the mangle table... I just copied them mindlessly. :-(

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p tcp --dport 443 -j DNAT --to 192.168.2.2:443
-A POSTROUTING -d 192.168.2.2 -s 192.168.0.0/255.255.0.0 -p tcp --dport 443 -j S NAT --to 192.168.1.2
-A PREROUTING -p tcp --dport 8180 -j DNAT --to 192.168.2.10:8180
-A POSTROUTING -d 192.168.2.10 -s 192.168.0.0/255.255.0.0 -p tcp --dport 8180 -j
SNAT --to 192.168.1.2
-A PREROUTING -p tcp --dport 8182 -j DNAT --to 192.168.2.2:8182
-A POSTROUTING -d 192.168.2.2 -s 192.168.0.0/255.255.0.0 -p tcp --dport 8182 -j SNAT --to 192.168.1.2
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:LOG_ACCEPT - [0:0]
:LOG_DROP - [0:0]
:icmp_packets - [0:0]
# I don't even think this next line is necessary, though, since the default policy is "ACCEPT"... -A FORWARD -s 192.168.0.0/16 -d 192.168.1.1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j LOG_ACCEPT
# Open up some other ports (edited out)
-A INPUT -s 127.0.0.1 -j ACCEPT
-A INPUT -p icmp -j icmp_packets
-A INPUT -j LOG_DROP
-A LOG_ACCEPT -j LOG --log-prefix "[IPTABLES ACCEPT] : " --log-tcp-options --log -ip-options
-A LOG_ACCEPT -j ACCEPT
-A LOG_DROP -j LOG --log-prefix "[IPTABLES DROP] : " --log-tcp-options --log-ip- options
-A LOG_DROP -j DROP
-A icmp_packets -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A icmp_packets -s 192.168.0.0/255.255.255.0 -p icmp -m icmp --icmp-type 8 -j AC CEPT
-A icmp_packets -s 192.168.1.0/255.255.255.0 -p icmp -m icmp --icmp-type 8 -j AC CEPT
-A icmp_packets -s 192.168.2.0/255.255.255.0 -p icmp -m icmp --icmp-type 8 -j AC CEPT
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT

Let's see. As far as I understand, your network looks something like this:

                          +-----------------+
                          |       ppp0      |
                          |        |        |
                          |        |        |
192.168.1.0/24------------|...1.2     ...2.1|-----192.168.2.0/24
                          |     Firewall    |
                          +-----------------+

By "local network" you mean 192.168.2.0. Right ?

If so or not, the first thing to check is the default gateway. For 1.0 it must be 1.2 and for 2.0 it must be 2.1. And proc/sys/net/ipv4/ip_forward must be set to 1.

Always a bad idea. In this case the rules don't do any harm and are not the culprit. But I think copying once is enough ;)

That's strange. Imagine this. Client 2.2 sends to 2.1 to port 443. The packet will be DNATed to 2.2, but SNATed to 1.2. And 2.2 will discard this packet, because he sent to 2.1. A packet originating from 1.1 will make it to 2.2, but it should be SNATed to 2.1 and not to 1.2.

Hmm, I see no rule that DNATs to 1.1. But your OP shows such a rule. So, it vanished. I recommend to start with an empty rule set in nat and see if it works. As your FORWARD policy is ACCEPT and there is only an ACCEPT rule in FORWARD (yes, you are right, this rule isn't needed), there should be no problem connecting from 2.0 to 1.1. After verifying the connection add rules like this:

[-t nat] -A PREROUTING -i ethX1 -p tcp --dport YYYY \
         -j DNAT --to $HOST

[-t nat] -A POSTROUTING -o ethX2 -p tcp -j SNAT \
--to $ADDRESS_OF_OUTGOING_INTERFACE

As long as you don't have multiple addresses per interface or your setup is more complicated than I think, I see no need to specify source/destination addresses in PREROUTING rules. Ofcourse you can do it, if you like.

Filter table is not related to your problem, at least not with this rule set. We are only dealing with FORWARD here.

HTH,

Joerg

Nice ASCII art! ;-)

Sorry, I should have been more precise. Actually, I think my situation is even simpler. I'll try to live up to the quality of ASCII art you established in your post. :-)

    +---------------+
    |     modem     |
    | (192.168.1.1) |
    +---------------+
            |
   +-----------------+
   |       ppp0      |
   |        |        |
   |  ...1.2 (eth0)  |
   |        |        |eth1
   |           ...2.1|-----192.168.2.0/24
   |     Firewall    |
   +-----------------+

So, what I mean (and which is probably a bit confusing) is that 19.168.1.0/24 means the "outside" network, which includes my modem, and 192.168.2.1 is my "local" network.

I think this is ok, but maybe somebody could confirm for me:

Destination Gateway    Genmask      Iface
192.168.1.0    *    255.255.255.0   eth0
192.168.2.0    *    255.255.255.0   eth1
default       xxx   0.0.0.0         ppp0

Yep.

:-)

I agree that it is best to understand what you're doing before writing rules. This stuff was proposed by one of the "security" books and I figured that the guy knows better than I, and I don't have the time to figure out what all that junk means... :-/

I got this from the following page:
http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

In other words, all packets to port 443, regardless of the source, should be routed to 192.168.2.2:443. However, the problem is with hosts on the local network. The solution proposed in the document above was:

...have the NAT box also map the source IP address to its own for these connections, fooling the server into replying through it. In this example, we would do the following (assuming the internal IP address of the NAT box is 192.168.1.250):

  # iptables -t nat -A POSTROUTING -d 192.168.1.1 -s \
        192.168.1.0/24 -p tcp --dport 80 -j SNAT --to \
        192.168.1.250

Because the PREROUTING rule gets run first, the packets will already be destined for the internal web server: we can tell which ones are internally sourced by the source IP addresses.

Did I misread this? This is supposed to do something like a "double NAT". And it works, too. Again, the only problem I'm having is connecting to 192.168.1.1. BTW, I can connect to 192.168.1.2 without any problems, which is why I can't figure this problem out.

Nope... Problem with routing, maybe?

Ok... so I changed this:

-A PREROUTING -p tcp --dport 443 -j DNAT --to 192.168.2.2:443

into this:

-A PREROUTING -i ppp0 -p tcp --dport 443 -j DNAT --to 192.168.2.2

Doesn't seem to make any difference, but I guess it's a bit cleaner.

I don't see how this can be done, though, since this rule must only be applied to local machines. So, it seems to be that the source address is definately required.... No?

Thanks for helping me figure all this out.

Dave

Hello!

Hmmm... unfortunately, this does not seem to be the case...

I say this for two reasons:

1. I can still connect to 192.168.1.1 from 192.168.2.1
2. Even when I bring down ppp0, I still can't reach 192.168.1.1 from anywhere other than the machine I mention in (1)

Unless, I didn't do the right thing. I simply did:

 # ifconfig ppp0 down

Is this sufficient?

Thanks again!!

Dave