Friendly ping for feedback or alternative suggestions to fix the problem Thx, Hans
> Hi, > > The problem occurs in the following scenario where two hosts A and B are in > use on the lan and connected to a router which is doing masquerade on the > wan link. > Host A has a private IP@ (eg 192.168.1.10/24) while host B has a public IP@ > (eg 172.18.16.240/24); the router has a public IP@ on the wan in the same > subnet as host B (eg 172.18.16.245/24). > A redirect rule is defined on the router to forward tcp service 8080 to > host A port 80 and translates into following iptables nat rules : > > Chain delegate_prerouting (1 references) > pkts bytes target prot opt in out source > destination > 2 68 prerouting_rule all -- * * 0.0.0.0/00.0.0.0/0 > /* user chain for prerouting */ > 1 32 zone_lan_prerouting all -- br-lan * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 zone_wan_prerouting all -- pppoe-wan * 0.0.0.0/0 > 0.0.0.0/0 > > chain zone_wan_prerouting (1 references) > pkts bytes target prot opt in out source > destination > 0 0 prerouting_wan_rule all -- * * 0.0.0.0/0 > 0.0.0.0/0 /* user chain for prerouting */ > 0 0 DNAT tcp -- * * 0.0.0.0/00.0.0.0/0 > tcp spt:8080 /* @redirect[0] */ to:192.168.1.10:80 > > > TCP traffic on pppoe-wan interface with as destination port 172.18.16.245 > will be redirected to 192.168.1.10 as expected but if host B runs a similar > tcp service on port 8080 it will be unreachable as traffic directed to > 172.18.16.240 will also be re-directed to 192.168.1.10. > The patch tries to fix this issue by using the wan IP address in the > zone_wan_prerouting lookup; in this case traffic destined for 172.18.16.240 > will not be redirected. > Chain delegate_prerouting (1 references) > pkts bytes target prot opt in out source > destination > 1 87 prerouting_rule all -- * * 0.0.0.0/00.0.0.0/0 > /* user chain for prerouting */ > 1 87 zone_lan_prerouting all -- br-lan * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 zone_wan_prerouting all -- pppoe-wan * 0.0.0.0/0 > 172.18.16.245 > > Chain zone_wan_prerouting (1 references) > pkts bytes target prot opt in out source > destination > 0 0 prerouting_wan_rule all -- * * 0.0.0.0/0 > 0.0.0.0/0 /* user chain for prerouting */ > 0 0 DNAT tcp -- * * 0.0.0.0/00.0.0.0/0 > tcp spt:8080 /* @redirect[0] */ to:192.168.1.10:80 > > Output of fw3 print diff before/after the patch > > < iptables -t nat -D delegate_prerouting -i pppoe-wan -j zone_wan_prerouting > < iptables -t nat -A delegate_prerouting -i pppoe-wan -j zone_wan_prerouting > --- > >* iptables -t nat -D delegate_prerouting -i pppoe-wan -d > *172.18.16.245/255.255.255.255 -j zone_wan_prerouting > >* iptables -t nat -A delegate_prerouting -i pppoe-wan -d > *172.18.16.245/255.255.255.255 -j zone_wan_prerouting > > Bye, > Hans > > On Thu, Oct 1, 2015 at 10:05 PM, Jo-Philipp Wich <jow at openwrt.org > <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote: > > >* Hi, > *>>* wouldn't this break port forwards to hosts not being within the range of > *>* the on-link lan subnet? > *>>* I also read the patch description three times and still am not sure what > *>* that change attempts to achive. > *>>* Can you further explain the problem please and provide a before/after > *>* "fw3 print" diff so that I better understand your proposed solution? > * > > >* ~ Jow > *>> > >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
