* a missing rule / incomplete routing @ 2014-08-11 10:01 lejeczek 2014-08-11 11:54 ` Vigneswaran R 0 siblings, 1 reply; 6+ messages in thread From: lejeczek @ 2014-08-11 10:01 UTC (permalink / raw) To: netfilter 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 any ideas/thoughts? greatly appreciated thanks P. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: a missing rule / incomplete routing 2014-08-11 10:01 a missing rule / incomplete routing lejeczek @ 2014-08-11 11:54 ` Vigneswaran R 2014-08-13 10:21 ` [Bulk] " lejeczek 0 siblings, 1 reply; 6+ messages in thread From: Vigneswaran R @ 2014-08-11 11:54 UTC (permalink / raw) To: lejeczek; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bulk] Re: a missing rule / incomplete routing 2014-08-11 11:54 ` Vigneswaran R @ 2014-08-13 10:21 ` lejeczek 2014-08-13 11:12 ` Vigneswaran R 0 siblings, 1 reply; 6+ messages in thread From: lejeczek @ 2014-08-13 10:21 UTC (permalink / raw) To: Vigneswaran R; +Cc: netfilter 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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bulk] Re: a missing rule / incomplete routing 2014-08-13 10:21 ` [Bulk] " lejeczek @ 2014-08-13 11:12 ` Vigneswaran R 2014-08-15 11:29 ` lejeczek 0 siblings, 1 reply; 6+ messages in thread From: Vigneswaran R @ 2014-08-13 11:12 UTC (permalink / raw) To: lejeczek; +Cc: netfilter When 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 On 08/13/2014 03:51 PM, lejeczek wrote: > 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 >> >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bulk] Re: a missing rule / incomplete routing 2014-08-13 11:12 ` Vigneswaran R @ 2014-08-15 11:29 ` lejeczek 2014-08-18 3:31 ` Vigneswaran R 0 siblings, 1 reply; 6+ messages in thread From: lejeczek @ 2014-08-15 11:29 UTC (permalink / raw) To: netfilter 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... On 13/08/14 12:12, Vigneswaran R wrote: > When 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 > > On 08/13/2014 03:51 PM, lejeczek wrote: >> 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 >>> >>> >> > > -- > To unsubscribe from this list: send the line "unsubscribe > netfilter" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at > http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bulk] Re: a missing rule / incomplete routing 2014-08-15 11:29 ` lejeczek @ 2014-08-18 3:31 ` Vigneswaran R 0 siblings, 0 replies; 6+ messages in thread From: Vigneswaran R @ 2014-08-18 3:31 UTC (permalink / raw) To: lejeczek; +Cc: netfilter On 08/15/2014 04:59 PM, lejeczek wrote: > 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 You can try the following to debug the problem: While the "ping -I 192.168.2.100 172.17.166.199" is in progress, please run tcpdump on Box A (172.17.166.199) and observe. 1. If you are seeing the ICMP request with source IP 192.168.2.100, however no ICMP reply seen on Box A, then either Box A doesn't have route to 192.168.2.100, or Box A's iptables may block the reply. 2. If you are seeing both ICMP request and reply on Box A, but the reply is not reaching Box B, most probably the intermediate machines don't have route to 192.168.2.0/24. In that case, one possible solution would be creating tunnel between Box A and Box B to reach 192.168.2.0/24 network. > 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... I couldn't find anything wrong/inconsistent in the above routing configuration. Regards, Vignesh > > On 13/08/14 12:12, Vigneswaran R wrote: >> When 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 >> >> On 08/13/2014 03:51 PM, lejeczek wrote: >>> 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 >>>> >>>> >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe netfilter" in >> the body of a message to majordomo@vger.kernel.org >> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-08-18 3:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-08-11 10:01 a missing rule / incomplete routing lejeczek 2014-08-11 11:54 ` Vigneswaran R 2014-08-13 10:21 ` [Bulk] " lejeczek 2014-08-13 11:12 ` Vigneswaran R 2014-08-15 11:29 ` lejeczek 2014-08-18 3:31 ` Vigneswaran R
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).