Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "John A. Sullivan III" <john.sullivan@nexusmgmt.com>
To: Kean Pedersen <netfilter@zakarun.dk>
Cc: netfilter <netfilter@lists.netfilter.org>
Subject: Re: Running iptables behind router
Date: Mon, 23 Feb 2004 23:31:16 -0500	[thread overview]
Message-ID: <1077597076.394.7.camel@localhost> (raw)
In-Reply-To: <20040224001308.GA10127@zaklinux.zakarun>

Hmmm . . . I've always used SNAT instead of MASQUERADE.  Is it my
imagination or are the SEQ numbers very strange in your log.  I wonder
if there is some kind of loop.  What happens if you add an interface
restriction to your MASQUERADE rule, i.e., from 192.168.2.0/24 -o eth0?
What happens if you SNAT instead of MASQUERADE?

On Mon, 2004-02-23 at 19:13, Kean Pedersen wrote:
> Okay... I have tried the solutions, but still can't connect from
> 192.168.2 to 192.168.1
> 
> I can connect fine to 192.168.1.3 (the ip of eth0 on NAT box) from
> 192.168.2.101 (the only machine apart from the NAT box on .2 network).
> 
> My network right now is:
> 
> Hardware router(192.168.1.1), the only access to Internet.
> Desktop (192.168.1.42)
> Server/NAT box (eth0:192.168.1.3 and eth1:192.168.2.1)
> Laptop (192.168.2.101)
> 
> The hardware router, desktop and server:eth0 are on one switch, while
> laptop and server:eth1 are on another switch.
> 
> Info from the server:
> # uname -a
> Linux luftguitar 2.4.25 #1 man feb 23 23:45:36 CET 2004 i586 GNU/Linux
> 
> # iptables -V
> iptables v1.2.9
> 
> # iptables -t nat -L -v; iptables -L -v
> Chain PREROUTING (policy ACCEPT 603 packets, 52677 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
> 
> Chain POSTROUTING (policy ACCEPT 630 packets, 49138 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>     2    84 MASQUERADE  all  --  any    any     192.168.2.0/24       anywhere            
> 
> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
> 
> Chain INPUT (policy ACCEPT 48705 packets, 4302K bytes)
>  pkts bytes target     prot opt in     out     source               destination         
> 
> Chain FORWARD (policy DROP 97 packets, 8120 bytes)
>  pkts bytes target     prot opt in     out     source               destination         
>     4   336 LOG        all  --  any    any     anywhere             anywhere            LOG level warning 
>     2   168 ACCEPT     all  --  any    any     192.168.2.0/24       anywhere            
> 
> Chain OUTPUT (policy ACCEPT 54057 packets, 13M bytes)
>  pkts bytes target     prot opt in     out     source               destination         
> 
> # lsmod
> Module                  Size  Used by    Not tainted
> ipt_LOG                 3256   1  (autoclean)
> ipt_state                472   0  (autoclean)
> ipt_MASQUERADE          1208   1  (autoclean)
> iptable_nat            14414   1  (autoclean) [ipt_MASQUERADE]
> ip_conntrack           18468   0  (autoclean) [ipt_state ipt_MASQUERADE iptable_nat]
> iptable_filter          1612   1  (autoclean)
> ip_tables              11360   7  [ipt_LOG ipt_state ipt_MASQUERADE iptable_nat iptable_filter]
> 
> (and I have enabled ip forwarding)
> 
> I then try a ping from my laptop (192.168.2.101) to my desktop (192.168.1.42),
> but all packes are lost. The packet count on iptables -L -v goes up for
> postrouting/masquerade and forward/accept.
> Looking in syslog the following is logged:
> 
> Feb 24 00:49:02 server kernel: IN=eth1 OUT=eth0 SRC=192.168.2.101
> DST=192.168.1.42 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP
> TYPE=8 CODE=0 ID=65281 SEQ=0 
> Feb 24 00:49:02 server kernel: IN=eth0 OUT=eth1 SRC=192.168.1.42
> DST=192.168.2.101 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=34538 PROTO=ICMP
> TYPE=0 CODE=0 ID=65281 SEQ=0 
> Feb 24 00:49:03 server kernel: IN=eth1 OUT=eth0 SRC=192.168.2.101
> DST=192.168.1.42 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP
> TYPE=8 CODE=0 ID=65281 SEQ=256 
> Feb 24 00:49:03 server kernel: IN=eth0 OUT=eth1 SRC=192.168.1.42
> DST=192.168.2.101 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=34539 PROTO=ICMP
> TYPE=0 CODE=0 ID=65281 SEQ=256 
> 
> I can ping the server on 192.168.2.1 and 192.168.1.3 fine from
> 192.168.2.101, but cannot reach the desktop (192.168.1.42) or the
> hardware router 192.168.1.1, and thus not the Internet.
> 
> --
> Kean Pedesen
> 
> 
> On Tue, Feb 17, 2004 at 09:39:07AM -0300, Alexis wrote:
> > yes, do this
> > 
> > 
> > echo 1 > /proc/sys/net/ipv4/ip_forward
> > 
> > iptables -p FORWARD DROP
> > 
> > iptables -A FORWARD -s 192.168.2.0/24 -j ACCEPT
> > 
> > then, you have 2 options
> > 
> > 1 to use 1 ip of 192.168.1 to nat all the .2 network, or use a pool,
> > its your choice
> > 
> > 1st case
> > iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j SNAT --to
> > 192.168.1.254
> > 
> > or
> > 
> > iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j MASQUERADE
> > 
> > 
> > 2nd case
> > 
> > iptables  -t nat -A POSTROUTING -s 192.168.2.0/24 -j SNAT --to
> > 192.168.1.50-192.168.1.60
> > 
> > 
> > 
> > 
> > Hello Kean,
> > 
> > Monday, February 16, 2004, 8:55:14 PM, you wrote:
> > 
> > KP> Hi, I have some problems setting up iptables on a linux box, acting as a
> > KP> router between two networks. I have an internet connection through a
> > KP> hardware router, which I have no access to. This router uses NAT, and
> > KP> has an interface on 192.168.1.1. So far I've had my LAN on
> > KP> 192.168.1.0/24, with no problems, but would like to split it into two
> > KP> LANs, one on 192.168.1.0/24, having the hardware router and some hosts,
> > KP> and another one on 192.168.2.0/24, acting as an "internal" LAN.
> > 
> > KP> I'd then like to connect these two LANs with a linux box running
> > KP> iptables, so the both LANs have access to the internet through the
> > KP> hardware router.
> > 
> > KP> I sat up the iptables machine (which have two NICs) to the IPs
> > KP> 192.168.1.100 and 192.168.2.100, one on each interface. How should I set
> > KP> up iptables, so the 192.168.2.0/24 range have access through iptables,
> > KP> and further through the hardware router onto the internet? Only outbound
> > KP> connections will be made. (Inbound connections are mapped in the
> > KP> hardware router to 192.168.1.x to specific hosts, no problem there).
> > 
> > KP> The computers on the 192.168.2.0/24 range should be able to make
> > KP> connections to the 192.168.1.0/24 range, but not the other way around.
> > 
> > KP> Any help is appreciated.
> > 
> > KP> --
> > KP> Kean Pedersen
> > 
> > 
> > -- 
> > Best regards,
> >  Alexis                            mailto:alexis@attla.net.ar
> > 
> > 
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com



  reply	other threads:[~2004-02-24  4:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-16 23:55 Running iptables behind router Kean Pedersen
2004-02-17 12:39 ` Alexis
2004-02-24  0:13   ` Kean Pedersen
2004-02-24  4:31     ` John A. Sullivan III [this message]
2004-02-24 12:07       ` Kean Pedersen
2004-02-25 18:40         ` John A. Sullivan III
2004-02-25 19:41           ` Kean Pedersen
2004-02-24 11:06     ` Antony Stone
2004-02-24 14:13     ` Jeffrey Laramie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1077597076.394.7.camel@localhost \
    --to=john.sullivan@nexusmgmt.com \
    --cc=netfilter@lists.netfilter.org \
    --cc=netfilter@zakarun.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox