From: Andrew Beverley <andy@andybev.com>
To: netfilter@buglecreek.com
Cc: netfilter@vger.kernel.org
Subject: Re: FORWARD chain and Interfaces
Date: Sat, 21 May 2011 08:37:20 +0100 [thread overview]
Message-ID: <1305963440.2741.65.camel@andybev-desktop> (raw)
In-Reply-To: <1305958205.10779.1454356989@webmail.messagingengine.com>
On Sat, 2011-05-21 at 00:10 -0600, netfilter@buglecreek.com wrote:
> I have a firewall router box that I'm trying to write a ruleset for that
> accepts/blocks traffic from Network A to Network B. I'm testing the
> rules on 3 virtual machines and will eventually deploy to production
> hardware:
>
> Network A Machine Eth0 <-------> Eth0 Firewall/Router Eth1 <------->
> Eth0Network B Machine
> 192.168.99.1 192.168.99.2
> 10.10.10.1 10.10.10.2
>
>
> I have the the following rules on the Firewall/Router as a test before I
> write rules with http, ssh etc:
>
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -i eth0 -o eth1 -p icmp --icmp-type echo-request -s
> 192.168.99.0/24 -d 10.10.10.0/24 -m state --state NEW -j ACCEPT
> iptables -A FORWARD -p icmp --icmp-type echo-request -m state --state
> NEW -j LOG --log-prefix "ICMP: "
>
> When I ping from 192.168.99.1 to 10.10.10.2 it does not work. The log
> rule logs the packet as IN=ETH1 OUT=ETH1. I may not understand how the
> interfaces should be referenced in the FORWARD chain, but I would think
> that the second rule above should allow and forward that icmp traffic.
>
> However, if I remove the -i eth0 and -o eth1 from the second rule above
> the ping works fine, the log of course still says IN=ETH1 OUT=ETH1.
>
> I guess I don't have to reference the interfaces in all my FORWARD
> rules, but I'd like to. I am confused why the -i and -o referenced in
> the second rule does not allow and forward traffic. And you the log rule
> log the packets as IN=ETH1 and OUT=ETH1, I would expect IN=ETH0
> OUT=ETH1.
My only thought on this is that the virtual machines are affecting your
interface names. Have you tried any other rules with interface names to
see if you get the same effect?
I expect that if you did the same with separate hardware, that the rules
would work as expected; therefore, I suggest testing without the
interface names, and inserting them when you have the actual hardware up
and running.
Andy
next prev parent reply other threads:[~2011-05-21 7:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-21 6:10 FORWARD chain and Interfaces netfilter
2011-05-21 7:37 ` Andrew Beverley [this message]
2011-05-21 11:23 ` Pascal Hambourg
2011-05-21 19:49 ` netfilter
2011-05-21 20:51 ` Pascal Hambourg
2011-05-21 21:40 ` netfilter
2011-05-21 22:05 ` Pascal Hambourg
2011-05-21 22:31 ` netfilter
2011-05-22 8:48 ` Pascal Hambourg
2011-05-22 19:06 ` netfilter
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=1305963440.2741.65.camel@andybev-desktop \
--to=andy@andybev.com \
--cc=netfilter@buglecreek.com \
--cc=netfilter@vger.kernel.org \
/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