Confirm: letting certain packages pass through un-natted

Confirm: letting certain packages pass through un-natted

[David Leangen]

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

Re: Confirm: letting certain packages pass through un-natted

[Rob Sterenborg]

> 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?

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

> 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.

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

Re: Confirm: letting certain packages pass through un-natted

[David Leangen]

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

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

> 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.

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...


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

Hmmm... weird...

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



>>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...

> 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.

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.

Re: Confirm: letting certain packages pass through un-natted

[Rob Sterenborg]

On Tue, September 27, 2005 02:17, David Leangen wrote:
>> What do the byte counters for this rule say when you execute :
>> iptables -nvL PREROUTING
>
> Hmmm... weird...
> [root@sannomiya ~]# iptables -nvL PREROUTING
> iptables: Table does not exist (do you need to insmod?)

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

> 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.

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

Re: Confirm: letting certain packages pass through un-natted

[Mariusz Kruk]

David Leangen napisał(a):
> 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?

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.

RE: Confirm: letting certain packages pass through un-natted

[David Leangen]

Hello!

> > -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?
> 
> 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.

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

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

Re: Confirm: letting certain packages pass through un-natted

[David Leangen]

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

Re: Confirm: letting certain packages pass through un-natted

[Jörg Harmuth]

David Leangen wrote:
> 
> 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.

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.

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

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

> 
> *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 SNAT --to 192.168.1.2

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.

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

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

> *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
> 

Re: Confirm: letting certain packages pass through un-natted

[David Leangen]

Nice ASCII art! ;-)

 > 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 ?

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.


 > 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.

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


 > And proc/sys/net/ipv4/ip_forward must be set to 1.

Yep.


 > *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
 > ... etc.

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

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

:-)

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... :-/

 > > *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 SNAT --to 192.168.1.2

 > 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.

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.


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

 > 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.

Nope... Problem with routing, maybe?


 > 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.

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.


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

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

Re: Confirm: letting certain packages pass through un-natted

[David Leangen]

Hello!

 >>    +---------------+
 >>    |     modem     |
 >>    | (192.168.1.1) |
 >>    +---------------+
 >>            |
 >>   +-----------------+
 >>   |       ppp0      |
 >>   |        |        |
 >>   |  ...1.2 (eth0)  |
 >>   |        |        |eth1
 >>   |           ...2.1|-----192.168.2.0/24
 >>   |     Firewall    |
 >>   +-----------------+
 >
 > [SNIP]
 >
 >
 >>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
 >
 >
 > [Rest snipped - probably not relevant]
 >
 > The only thing I can think of, is that pppd causes the problem.
 > I think the following happens:
 >
 > 2.2 sends to 1.1
 > Firewall receives on 2.1
 > According to routing table firewall tries to send out on eth0
 > But eth0 is now owned by pppd
 > And pppd doesn't know about 1.1, he only knows about default
 > gateway xxx
 >
 > As already said - this may be totally wrong (someone correct
 > me please).
 >
 > I bet if you stop pppd, 2.2 can connect to 1.1 without any firewall
 > rules (as long as the policies are ACCEPT and default gateway on 2.2
 > points to 2.1). If this is true, the question is how to persuade
 > pppd to deliver to 1.1. Sorry, I can't help you - may be
 > somebody can jump in.

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