yes, 172.17.166.199 replies,
to sort of narrow it down a bit
I on box B do
ping -I 172.25.12.101 172.17.166.199 = replies
ping -I 192.168.2.100 172.17.166.199 = does not
on a box behind B's 192.168.2.65, eg on 192.168.2.81 (winbox)
ping 172.17.167.41 = replies
feels like B's local routing, but where exactly?? no idea I have
my routing tables:
main:
default dev em3 scope link
$publicNet.0/24 dev em3 proto kernel scope link src
$publicNet.75
172.25.12.0/24 dev em2 proto kernel scope link src
172.25.12.203
192.168.2.0/24 dev em1 proto kernel scope link src
192.168.2.100
192.168.2.10 dev ppp0 proto kernel scope link src
192.168.2.100
192.168.2.64/27 dev br0 proto kernel scope link src
192.168.2.65
private:
internal:
172.0.0.0/8 dev em2 scope link
192.168.4.0/24 via 172.25.12.215 dev em2
external:
default via $publicNet.62 dev em3
$publicNet.0/24 dev em3 scope link
172.25.12.214 dev em2 scope link
192.168.2.64/27 dev br0 scope link
0: from all lookup local
32763: from 172.0.0.0/8 lookup internal
32764: from $publicNet.0/24 lookup external
32766: from all lookup main
32767: from all lookup default
interfaces:
em1 192.168.2.100
em2 172.25.12.203
em3 $publicIP
br0 192.168.2.65
geee...
Post by Vigneswaran RWhen you say "a 192.168.2.81 from behind box B can
ping172.17.166.199" (in your first mail), do you mean both
the following happen?
1) the icmp request from 192.168.2.81 is able to reach
172.17.166.199, and
2) the icmp reply from 172.17.166.199 is able to reach
192.168.2.81
In case, the 2nd is not happening, most probably the
routers in between (which are not in your control) not
having route for 192.168.x.x network. In that case, you
may have to create a tunnel (or use VPN) between Box A and
Box B to connect to 192.168.x.x network.
Regards,
Vignesh
Post by lejeczek-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
Post by Vigneswaran RPost by lejeczekdear experts
I'm looking for ideas/suggestion why the following does
not work
* 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
--
To unsubscribe from this list: send the line "unsubscribe
netfilter" in
More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html