Hi, Recently We have added an wireless network attached through a gateway in LAN(loc) We have edited the zones, interface, policy, hosts to make it work. All machines in loc hae default route to 192.168.168.1 We can ping from both size (wlan <--> loc) When we ping from loc --> wlan, the packet was first send to fw, and fw return an icmp redirect to host 192.168.168.49 The client machine routing table now have the key added. However, when we ping from wlan to loc, the packet goes from wlan --> wlanfw --> loc --> fw --> wlanfw -->wlan It doesn''t send an icmp redirect, and this is the problem. We want the fw to send an icmp redirect and the loc machines talk with the wlanfw directly, how? Thanks in advance, Martin Chan ------------------ ------------------ ----------- | loc | ---------- | fw | --------| net | |192.168.168.0/24| | 192.168.168.1 | | | ------------------ ------------------ ----------- | | | ------------------ |192.168.168.49 | | wlanfw | | 192.168.11.1 | ------------------ | | ------------------ | wlan | | 192.168.11.0/26| -------------------
On Tue, 17 Jun 2003 14:49:15 +0800, Martin Chan <martinc@milliontech.com> wrote:> Hi, > > Recently We have added an wireless network attached through a gateway in > LAN(loc) > We have edited the zones, interface, policy, hosts to make it work. > All machines in loc hae default route to 192.168.168.1 > > We can ping from both size (wlan <--> loc) > When we ping from loc --> wlan, the packet was first send to fw, and fw > return an icmp redirect to host 192.168.168.49 > The client machine routing table now have the key added. > > However, when we ping from wlan to loc, the packet goes from > wlan --> wlanfw --> loc --> fw --> wlanfw -->wlanHuh? Are you doing any SNAT/MASQ between loc and wlan?> It doesn''t send an icmp redirect, and this is the problem. > We want the fw to send an icmp redirect and the loc machines talk with > the > wlanfw directly, how? Thanks in advance,Please forward the following: a) output of "route -n" b) output of "shorewall show nat" c) your /etc/shorewall/interfaces file. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
[root@gw root]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 210.17.151.186 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 210.17.151.187 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 210.17.151.184 0.0.0.0 255.255.255.248 U 0 0 0 eth0 210.17.151.184 0.0.0.0 255.255.255.248 U 0 0 0 ipsec0 192.168.11.0 192.168.168.49 255.255.255.192 UG 0 0 0 eth1 192.168.4.0 210.17.151.185 255.255.255.0 UG 0 0 0 ipsec0 192.168.2.0 210.17.151.185 255.255.255.0 UG 0 0 0 ipsec0 192.168.168.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 210.17.151.185 0.0.0.0 UG 0 0 0 eth0 [root@gw root]# shorewall show nat Shorewall-1.4.2 NAT at gw.hk.milliontech.com - Wed Jun 18 10:11:42 HKT 2003 Counters reset Tue Jun 17 14:29:33 HKT 2003 Chain PREROUTING (policy ACCEPT 766K packets, 71M bytes) pkts bytes target prot opt in out source destination 1284 94371 ipsec0_in all -- ipsec0 * 0.0.0.0/0 0.0.0.0/0 40868 4188K eth1_in all -- eth1 * 0.0.0.0/0 0.0.0.0/0 4133 353K net_dnat all -- eth0 * 0.0.0.0/0 0.0.0.0/0 36796 3853K loc_dnat all -- eth1 * 192.168.168.0/24 0.0.0.0/0 22525 1893K dmz_dnat all -- eth2 * 0.0.0.0/0 0.0.0.0/0 1 73 wlan_dnat all -- eth1 * 192.168.11.0/26 0.0.0.0/0 Chain POSTROUTING (policy ACCEPT 380K packets, 22M bytes) pkts bytes target prot opt in out source destination 68 4080 SNAT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 to:210.17.151.186 1447 121K ipsec0_out all -- * ipsec0 0.0.0.0/0 0.0.0.0/0 225 16409 eth1_out all -- * eth1 0.0.0.0/0 0.0.0.0/0 8904 540K eth0_masq all -- * eth0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 73855 packets, 5800K bytes) pkts bytes target prot opt in out source destination Chain dmz_dnat (1 references) pkts bytes target prot opt in out source destination 271 18456 REDIRECT udp -- * * 0.0.0.0/0 !192.168.168.1 udp dpt:53 redir ports 53 0 0 REDIRECT tcp -- * * 0.0.0.0/0 !192.168.168.1 tcp dpt:53 redir ports 53 Chain eth0_masq (1 references) pkts bytes target prot opt in out source destination 74 4452 SNAT all -- * * 192.168.168.0/24 0.0.0.0/0 to:210.17.151.189 8384 503K SNAT all -- * * 192.168.10.0/24 0.0.0.0/0 to:210.17.151.189 0 0 SNAT all -- * * 192.168.11.0/26 0.0.0.0/0 to:210.17.151.189 Chain eth1_in (1 references) pkts bytes target prot opt in out source destination 3787 282K DNAT all -- * * 0.0.0.0/0 192.168.168.81 to:192.168.10.81 0 0 DNAT all -- * * 0.0.0.0/0 192.168.168.20 to:192.168.168.1 Chain eth1_out (1 references) pkts bytes target prot opt in out source destination 8 7546 SNAT all -- * * 192.168.10.81 0.0.0.0/0 to:192.168.168.81 9 411 SNAT all -- * * 192.168.168.1 0.0.0.0/0 to:192.168.168.20 Chain ipsec0_in (1 references) pkts bytes target prot opt in out source destination 896 53760 DNAT all -- * * 0.0.0.0/0 192.168.168.81 to:192.168.10.81 Chain ipsec0_out (1 references) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 192.168.10.81 0.0.0.0/0 to:192.168.168.81 Chain loc_dnat (1 references) pkts bytes target prot opt in out source destination 1579 124K REDIRECT udp -- * * 0.0.0.0/0 !192.168.168.1 udp dpt:53 redir ports 53 0 0 REDIRECT tcp -- * * 0.0.0.0/0 !192.168.168.1 tcp dpt:53 redir ports 53 0 0 REDIRECT udp -- * * 0.0.0.0/0 !192.168.168.1 udp dpt:37 redir ports 37 80 3524 REDIRECT tcp -- * * 0.0.0.0/0 !192.168.168.1 tcp dpt:37 redir ports 37 Chain net_dnat (1 references) pkts bytes target prot opt in out source destination 2263 125K DNAT tcp -- * * 0.0.0.0/0 210.17.151.186 tcp dpt:80 to:192.168.10.81 226 12088 DNAT tcp -- * * 0.0.0.0/0 210.17.151.186 tcp dpt:25 to:192.168.10.81 77 3696 DNAT tcp -- * * 0.0.0.0/0 210.17.151.187 tcp dpt:80 to:192.168.10.187 0 0 DNAT tcp -- * * 210.66.152.158 210.17.151.189 tcp dpt:1720 to:192.168.10.2 Chain wlan_dnat (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT udp -- * * 0.0.0.0/0 !192.168.168.1 udp dpt:53 redir ports 53 0 0 REDIRECT tcp -- * * 0.0.0.0/0 !192.168.168.1 tcp dpt:53 redir ports 53 #ZONE INTERFACE BROADCAST OPTIONS net $NET_IF $NET_BCAST dropunclean,logunclean,norfc1918 #loc $LOCAL_IF $LOCAL_BCAST dmz $DMZ_IF $DMZ_BCAST vpn $VPN_IF detect - $LOCAL_IF $LOCAL_BCAST,$WLAN_BCAST logunclean #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE #ZONE HOST(S) OPTIONS loc $LOCAL_IF:$LOCAL_SUBNET wlan $LOCAL_IF:$WLAN_SUBNET routeback #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE Tom Eastep wrote:> On Tue, 17 Jun 2003 14:49:15 +0800, Martin Chan > <martinc@milliontech.com> wrote: > >> Hi, >> >> Recently We have added an wireless network attached through a gateway in >> LAN(loc) >> We have edited the zones, interface, policy, hosts to make it work. >> All machines in loc hae default route to 192.168.168.1 >> >> We can ping from both size (wlan <--> loc) >> When we ping from loc --> wlan, the packet was first send to fw, and fw >> return an icmp redirect to host 192.168.168.49 >> The client machine routing table now have the key added. >> >> However, when we ping from wlan to loc, the packet goes from >> wlan --> wlanfw --> loc --> fw --> wlanfw -->wlan > > > Huh? Are you doing any SNAT/MASQ between loc and wlan? > >> It doesn''t send an icmp redirect, and this is the problem. >> We want the fw to send an icmp redirect and the loc machines talk >> with the >> wlanfw directly, how? Thanks in advance, > > > Please forward the following: > > a) output of "route -n" > b) output of "shorewall show nat" > c) your /etc/shorewall/interfaces file. > > -Tom
On Wed, 18 Jun 2003, Martin Chan wrote:> #ZONE INTERFACE BROADCAST OPTIONS > net $NET_IF $NET_BCAST dropunclean,logunclean,norfc1918 > #loc $LOCAL_IF $LOCAL_BCAST > dmz $DMZ_IF $DMZ_BCAST > vpn $VPN_IF detect > - $LOCAL_IF $LOCAL_BCAST,$WLAN_BCAST logunclean > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > > #ZONE HOST(S) OPTIONS > loc $LOCAL_IF:$LOCAL_SUBNET > wlan $LOCAL_IF:$WLAN_SUBNET routeback > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVEThat''s pretty worthless without your /etc/shorewall/params file, wouldn''t you agree? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Right, I forgotten it. NET_IF=eth0 NET_BCAST=210.17.151.191 NET_SUBNET=210.17.151.184/29 NET_IP=210.17.151.190 SNAT_IP=210.17.151.189 MAIL_SERVER_IP=210.17.151.186 LOCAL_IF=eth1 LOCAL_BCAST=192.168.168.255 LOCAL_SUBNET=192.168.168.0/24 LOCAL_IP=192.168.168.1 DMZ_IF=eth2 DMZ_BCAST=192.168.10.255 DMZ_SUBNET=192.168.10.0/24 DMZ_IP=192.168.10.1 WLAN_SUBNET=192.168.11.0/26 WLAN_BCAST=192.168.11.63 VPN_IF=ipsec0 UPLINK_SPEED=420 DOWNLINK_SPEED=1480 Tom Eastep wrote:>On Wed, 18 Jun 2003, Martin Chan wrote: > > > >>#ZONE INTERFACE BROADCAST OPTIONS >>net $NET_IF $NET_BCAST dropunclean,logunclean,norfc1918 >>#loc $LOCAL_IF $LOCAL_BCAST >>dmz $DMZ_IF $DMZ_BCAST >>vpn $VPN_IF detect >>- $LOCAL_IF $LOCAL_BCAST,$WLAN_BCAST logunclean >>#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >> >> >>#ZONE HOST(S) OPTIONS >>loc $LOCAL_IF:$LOCAL_SUBNET >>wlan $LOCAL_IF:$WLAN_SUBNET routeback >>#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE >> >> > >That''s pretty worthless without your /etc/shorewall/params file, wouldn''t >you agree? > >-Tom >-- >Tom Eastep \ Shorewall - iptables made easy >Shoreline, \ http://www.shorewall.net >Washington USA \ teastep@shorewall.net > >
On Wed, 18 Jun 2003, Martin Chan wrote:> Right, I forgotten it. > > > NET_IF=eth0 > NET_BCAST=210.17.151.191 > NET_SUBNET=210.17.151.184/29 > NET_IP=210.17.151.190 > SNAT_IP=210.17.151.189 > MAIL_SERVER_IP=210.17.151.186 > LOCAL_IF=eth1 > LOCAL_BCAST=192.168.168.255 > LOCAL_SUBNET=192.168.168.0/24 > LOCAL_IP=192.168.168.1 > DMZ_IF=eth2 > DMZ_BCAST=192.168.10.255 > DMZ_SUBNET=192.168.10.0/24 > DMZ_IP=192.168.10.1 > WLAN_SUBNET=192.168.11.0/26 > WLAN_BCAST=192.168.11.63 > VPN_IF=ipsec0 > UPLINK_SPEED=420 > DOWNLINK_SPEED=1480 >Thanks -- now -- what pair of hosts exhibit the behavior that you are reporting (ICMP redirect in one direction and routing in the other). e.g., what are their IP addresses? Thanks, -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
1. ping from 192.168.168.60 -> 192.168.11.26, 192.168.168.60 received icmp redirect. 2. ping from 192.168.11.26 -> 192.168.168.60, 192.168.168.60 received icmp redirect. Both cases have no problem and added routing key to 192.168.168.60 automatically. For TCP connection: When 192.168.11.26:xxxx-->192.168.168.60:80, 192.168.168.60 received the request and reply with ACK (SYN/ACK) to 192.168.11.26:xxxx throough default route (192.168.168.1). 192.168.168.1 received the packet and sliently drop it, and it doesn''t send 192.168.168.60 an icmp redirect. Tom Eastep wrote:>On Wed, 18 Jun 2003, Martin Chan wrote: > > > >>Right, I forgotten it. >> >> >>NET_IF=eth0 >>NET_BCAST=210.17.151.191 >>NET_SUBNET=210.17.151.184/29 >>NET_IP=210.17.151.190 >>SNAT_IP=210.17.151.189 >>MAIL_SERVER_IP=210.17.151.186 >>LOCAL_IF=eth1 >>LOCAL_BCAST=192.168.168.255 >>LOCAL_SUBNET=192.168.168.0/24 >>LOCAL_IP=192.168.168.1 >>DMZ_IF=eth2 >>DMZ_BCAST=192.168.10.255 >>DMZ_SUBNET=192.168.10.0/24 >>DMZ_IP=192.168.10.1 >>WLAN_SUBNET=192.168.11.0/26 >>WLAN_BCAST=192.168.11.63 >>VPN_IF=ipsec0 >>UPLINK_SPEED=420 >>DOWNLINK_SPEED=1480 >> >> >> > >Thanks -- now -- what pair of hosts exhibit the behavior that you are >reporting (ICMP redirect in one direction and routing in the other). e.g., >what are their IP addresses? > >Thanks, >-Tom >-- >Tom Eastep \ Shorewall - iptables made easy >Shoreline, \ http://www.shorewall.net >Washington USA \ teastep@shorewall.net > >
On Wed, 18 Jun 2003, Martin Chan wrote:> 1. ping from 192.168.168.60 -> 192.168.11.26, 192.168.168.60 received > icmp redirect. > 2. ping from 192.168.11.26 -> 192.168.168.60, 192.168.168.60 received > icmp redirect. > Both cases have no problem and added routing key to 192.168.168.60 > automatically. > > For TCP connection: > When 192.168.11.26:xxxx-->192.168.168.60:80, 192.168.168.60 received the > request and reply with ACK (SYN/ACK) > to 192.168.11.26:xxxx throough default route (192.168.168.1). > 192.168.168.1 received the packet and sliently drop it, and it doesn''t > send 192.168.168.60 an icmp redirect.See if setting NEWNOTSYN=Yes in shorewall.conf helps. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Yes, it works. But can we use it only on one interface. I''m worry about it will affect the security on my firewall from the Internet side.>See if setting NEWNOTSYN=Yes in shorewall.conf helps. > >-Tom >-- >Tom Eastep \ Shorewall - iptables made easy >Shoreline, \ http://www.shorewall.net >Washington USA \ teastep@shorewall.net > >
On Wed, 18 Jun 2003, Martin Chan wrote:> Yes, it works. > But can we use it only on one interface. I''m worry about it will affect > the security on my firewall from the Internet side. >If it was available on an interface basis, I would have recommended that approach to you. Any routing scheme that sends packets out the same interface that they came in on is braindead in my opinion; if that''s what you want to do, setting NEWNOTSYN=Yes is the price you pay if you want to use Shorewall. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2003-06-17 at 20:21, Tom Eastep wrote:> On Wed, 18 Jun 2003, Martin Chan wrote: > > > Yes, it works. > > But can we use it only on one interface. I''m worry about it will affect > > the security on my firewall from the Internet side. > > > > If it was available on an interface basis, I would have recommended that > approach to you. Any routing scheme that sends packets out the same > interface that they came in on is braindead in my opinion; if that''s > what you want to do, setting NEWNOTSYN=Yes is the price you pay if you > want to use Shorewall. >I realized in the night that there is one interface-specific thing that you can try. a) Restore NEWNOTSYN=No b) In /etc/shorewall/init, add: echo 0 > /proc/sys/net/ipv4/conf/$LOCAL_IF/send_redirects -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
On Wed, 2003-06-18 at 06:00, Tom Eastep wrote:> > I realized in the night that there is one interface-specific thing that > you can try. > > a) Restore NEWNOTSYN=No > b) In /etc/shorewall/init, add: > > echo 0 > /proc/sys/net/ipv4/conf/$LOCAL_IF/send_redirectsI have also realized that providing per-interface control for NEWNOTSYN is clean and easy. The code in the CVS "Shorewall/" project implements a ''newnotsyn'' interface option. It allows you to set NEWNOTSYN=No in shorewall.conf and then override that setting for packets arriving on particular interfaces. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
It works when we connect from loc to wlan, but still fail when connect from wlan to loc. Tom Eastep wrote:>I realized in the night that there is one interface-specific thing that >you can try. > >a) Restore NEWNOTSYN=No >b) In /etc/shorewall/init, add: > > echo 0 > /proc/sys/net/ipv4/conf/$LOCAL_IF/send_redirects > >-Tom > >
Does it mean that it will include in next release? Thanks. Tom Eastep wrote:>On Wed, 2003-06-18 at 06:00, Tom Eastep wrote: > > > >>I realized in the night that there is one interface-specific thing that >>you can try. >> >>a) Restore NEWNOTSYN=No >>b) In /etc/shorewall/init, add: >> >> echo 0 > /proc/sys/net/ipv4/conf/$LOCAL_IF/send_redirects >> >> > >I have also realized that providing per-interface control for NEWNOTSYN >is clean and easy. > >The code in the CVS "Shorewall/" project implements a ''newnotsyn'' >interface option. It allows you to set NEWNOTSYN=No in shorewall.conf >and then override that setting for packets arriving on particular >interfaces. > >-Tom > >
On Thu, 19 Jun 2003 11:03:55 +0800, Martin Chan <martinc@milliontech.com> wrote:> Does it mean that it will include in next release?Yes -- and it''s available now in the snapshot that I announced today. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Tom, That''s very great. Thanks. Tom Eastep wrote:> On Thu, 19 Jun 2003 11:03:55 +0800, Martin Chan wrote: > >> Does it mean that it will include in next release? > > > Yes -- and it''s available now in the snapshot that I announced today. > > -Tom