netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: lejeczek <peljasz@yahoo.co.uk>
To: Vigneswaran R <vignesh@atc.tcs.com>
Cc: netfilter <netfilter@vger.kernel.org>
Subject: Re: [Bulk] Re: a missing rule / incomplete routing
Date: Wed, 13 Aug 2014 11:21:15 +0100	[thread overview]
Message-ID: <53EB3C1B.60702@yahoo.co.uk> (raw)
In-Reply-To: <53E8AEE0.60800@atc.tcs.com>

I have had:
-A FORWARD -i em1 -o em2 -m state --state NEW -j ACCEPT
-A FORWARD -i em2 -o em1 -m state --state NEW -j ACCEPT
besides, also usual
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT

one strange thing is that when I tracepath on box B I see 
traffic (to box A 172.17.167.x) wants to go out via 
em3(another psyh interface)

if it might be routing, then
I have 3 man made routing tables, one for each interface
private 192.xxxx
internal 172.xxx
external a public IP

I've left out private (empty, no rules no routes) for I 
thought kernel would take care of it,
which it does (well, to certain extent) eg. 172.25.12.x net 
get to box B's 192.168.2.100 and behind (this is internal 
table route rules)
but eg. 172.17.x.x  which essentially goes through the same 
phys0 cannot get to box B's 192.168.2.100 (but can to box 
B's 172.25.12.101)

there are router(s) between 172.x.x.x (not mine) but then as 
above they all can get to box B's psyh0 172.25.12.101

it's all a bit weird to me


On 11/08/14 12:54, Vigneswaran R wrote:
> On 08/11/2014 03:31 PM, lejeczek wrote:
>> dear experts
>>
>> I'm looking for ideas/suggestion why the following does 
>> not work
>>
>> there is a:
>> * box A - 172.17.166.199 --  then there is 172./8 net -- 
>> box B - 172.25.12.101 (phys0), 192.168.2.100 (phys1) -- 
>> and one more net behind 192.168.2.100
>>
>> a 192.168.2.81 from behind box B can ping172.17.166.199
>> but not the other way around, box A cannot get to box B's 
>> phys1 but it does get to phys0
>>
>> I can control box A but have no control over the nets 
>> between it and box B's phys0
>> I can control box B
>>
>> I thought my route rules on box B are complete, box A is 
>> a winbox
>> I though box B' firewall is ready
>> but I obviously miss something
>>
>> there is no masquerading for phys0 nor phys1 one box B
>
> It looks like  the firewall (FORWARD chain) in B is not 
> allowing NEW connections from phys0 to phys1; only 
> allowing ESTABLISHED connections, which made the ICMP 
> reply packets through.
>
>
> Regards,
> Vignesh
>
>


  reply	other threads:[~2014-08-13 10:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 10:01 a missing rule / incomplete routing lejeczek
2014-08-11 11:54 ` Vigneswaran R
2014-08-13 10:21   ` lejeczek [this message]
2014-08-13 11:12     ` [Bulk] " Vigneswaran R
2014-08-15 11:29       ` lejeczek
2014-08-18  3:31         ` Vigneswaran R

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=53EB3C1B.60702@yahoo.co.uk \
    --to=peljasz@yahoo.co.uk \
    --cc=netfilter@vger.kernel.org \
    --cc=vignesh@atc.tcs.com \
    /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;
as well as URLs for NNTP newsgroup(s).