Hi,
I''d like to ask how to properly support more subnets added to single
interface by the "up route add" lines in /etc/network/interfaces:
iface eth1 inet static
address 194.108.5.129
netmask 255.255.255.128
network 194.108.5.128
broadcast 194.108.5.255
up /sbin/route add -net 194.108.6.0/29 gw 194.108.5.164
up /sbin/route add -net 194.108.6.8/30 gw 194.108.5.175
I am running Shorewall 1.4.7 so I went to the hosts file and added the
following entry there:
usr eth1:194.108.5.128/25,194.108.6.0/29,194.108.6.8/30
Then I played in the interfaces file - replaced the zone name for eth1
with "-", replaced the broadcast "detect" with list of
broadcast
addresses etc but it somehow didn''t work. At last I gave up and defined
more zones in the hosts file:
usr eth1:194.108.5.128/25
usr2 eth1:194.108.6.0/29
usr3 eth1:194.108.6.8/30
And of course updated the policy file with a bunch of rules that allowed
usr<->usr2<->usr3 traffic.
This is of course not elegant (to say the least) so I''d be grateful for
pointing me in the right direction. I''d swear I read Tom''s
post about
the additional routes but I couldn''t find it in the mailing list
archives :-(
Thanks.
Petr
On Mon, 2004-02-16 at 15:15, Petr Stehlik wrote:> I''d like to ask how to properly support more subnets added to single > interface by the "up route add" lines in /etc/network/interfaces: > > iface eth1 inet static > address 194.108.5.129 > netmask 255.255.255.128 > network 194.108.5.128 > broadcast 194.108.5.255 > up /sbin/route add -net 194.108.6.0/29 gw 194.108.5.164 > up /sbin/route add -net 194.108.6.8/30 gw 194.108.5.175 > > I am running Shorewall 1.4.7 so I went to the hosts file and added the > following entry there: > > usr eth1:194.108.5.128/25,194.108.6.0/29,194.108.6.8/30 > > Then I played in the interfaces file - replaced the zone name for eth1 > with "-", replaced the broadcast "detect" with list of broadcast > addresses etc but it somehow didn''t work. At last I gave up and defined > more zones in the hosts file: > > usr eth1:194.108.5.128/25 > usr2 eth1:194.108.6.0/29 > usr3 eth1:194.108.6.8/30I have just happened to make them all one line (as I tried before) but what I had to do was to add a policy "usr usr ACCEPT" (which according to documentation shouldn''t be necessary since 1.4.1). I must be doing something wrong anyway since ping between hosts in different subnets of eth1 works but telnet to smtp port does not :-( Any help is greatly appreciated. Petr
On Monday 16 February 2004 06:15 am, Petr Stehlik wrote:> Hi, > > I''d like to ask how to properly support more subnets added to single > interface by the "up route add" lines in /etc/network/interfaces: > > iface eth1 inet static > address 194.108.5.129 > netmask 255.255.255.128 > network 194.108.5.128 > broadcast 194.108.5.255 > up /sbin/route add -net 194.108.6.0/29 gw 194.108.5.164 > up /sbin/route add -net 194.108.6.8/30 gw 194.108.5.175 > > I am running Shorewall 1.4.7 so I went to the hosts file and added the > following entry there: > > usr eth1:194.108.5.128/25,194.108.6.0/29,194.108.6.8/30 > > Then I played in the interfaces file - replaced the zone name for eth1 > with "-", replaced the broadcast "detect" with list of broadcast > addresses etc but it somehow didn''t work.What does "it didn''t work" mean? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Monday 16 February 2004 07:45 am, Petr Stehlik wrote:> On Mon, 2004-02-16 at 15:15, Petr Stehlik wrote: > > I''d like to ask how to properly support more subnets added to single > > interface by the "up route add" lines in /etc/network/interfaces: > > > > iface eth1 inet static > > address 194.108.5.129 > > netmask 255.255.255.128 > > network 194.108.5.128 > > broadcast 194.108.5.255 > > up /sbin/route add -net 194.108.6.0/29 gw 194.108.5.164 > > up /sbin/route add -net 194.108.6.8/30 gw 194.108.5.175 > > > > I am running Shorewall 1.4.7 so I went to the hosts file and added the > > following entry there: > > > > usr eth1:194.108.5.128/25,194.108.6.0/29,194.108.6.8/30 > > > > Then I played in the interfaces file - replaced the zone name for eth1 > > with "-", replaced the broadcast "detect" with list of broadcast > > addresses etc but it somehow didn''t work. At last I gave up and defined > > more zones in the hosts file: > > > > usr eth1:194.108.5.128/25 > > usr2 eth1:194.108.6.0/29 > > usr3 eth1:194.108.6.8/30 > > I have just happened to make them all one line (as I tried before) but > what I had to do was to add a policy "usr usr ACCEPT" (which according > to documentation shouldn''t be necessary since 1.4.1). > > I must be doing something wrong anyway since ping between hosts in > different subnets of eth1 works but telnet to smtp port does not :-( Any > help is greatly appreciated.What does "shorewall show connections" show about the SMTP connection after you try to establish it? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Mon, 2004-02-16 at 17:08, Tom Eastep wrote:> > I must be doing something wrong anyway since ping between hosts in > > different subnets of eth1 works but telnet to smtp port does not :-( Any > > help is greatly appreciated. > > What does "shorewall show connections" show about the SMTP connection after > you try to establish it?it''s not in the list of connections. Petr
On Mon, 2004-02-16 at 17:06, Tom Eastep wrote:> > Then I played in the interfaces file - replaced the zone name for eth1 > > with "-", replaced the broadcast "detect" with list of broadcast > > addresses etc but it somehow didn''t work. > > What does "it didn''t work" mean?Honestly I can''t remember exactly since I''ve been working on it for 6 hours already and tried many different combinations but I think I was either getting usr2all DROP messages in the log file or it was quiet but pinging didn''t work. My followup on my own post indicates that I managed to fix it later by adding "usr usr ACCEPT" to POLICY file. Petr
On Monday 16 February 2004 08:14 am, Petr Stehlik wrote:> On Mon, 2004-02-16 at 17:08, Tom Eastep wrote: > > > I must be doing something wrong anyway since ping between hosts in > > > different subnets of eth1 works but telnet to smtp port does not :-( > > > Any help is greatly appreciated. > > > > What does "shorewall show connections" show about the SMTP connection > > after you try to establish it? > > it''s not in the list of connections. >Then please submit the information requested in the Shorewall Support Guide -- in particular, the information in the paragraph which begins "This is Important!". -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Mon, 2004-02-16 at 16:45, Petr Stehlik wrote:> > address 194.108.5.129 > > netmask 255.255.255.128 > > network 194.108.5.128 > > broadcast 194.108.5.255 > > up /sbin/route add -net 194.108.6.0/29 gw 194.108.5.164 > > up /sbin/route add -net 194.108.6.8/30 gw 194.108.5.175 > > > > usr eth1:194.108.5.128/25,194.108.6.0/29,194.108.6.8/30 > > > I must be doing something wrong anyway since ping between hosts in > different subnets of eth1 works but telnet to smtp port does not :-( Any > help is greatly appreciated.There is one more thing to add: I have just tried to stop the shorewall with "/etc/init.d/shorewall stop" and the problem with "telnet timeout" was still there so maybe it''s not a problem with shorewall config, I don''t know. Feel free to send me to /dev/null. If you''re willing to help me anyway here is the information Tom asked for: # shorewall version 1.4.7 # ip addr show 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:01:02:10:14:28 brd ff:ff:ff:ff:ff:ff inet 194.108.196.210/30 brd 194.108.196.211 scope global eth0 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:30:4f:06:7d:6f brd ff:ff:ff:ff:ff:ff inet 194.108.5.129/25 brd 194.108.5.255 scope global eth1 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:4f:21:d7:51 brd ff:ff:ff:ff:ff:ff inet 194.108.5.1/26 brd 194.108.5.63 scope global eth2 5: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:c0:b8:af:93 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth3 # ip route show 194.108.196.208/30 dev eth0 proto kernel scope link src 194.108.196.210 194.108.6.8/30 via 194.108.5.175 dev eth1 194.108.6.0/29 via 194.108.5.164 dev eth1 194.108.6.16/29 via 194.108.5.132 dev eth1 194.108.5.80/29 via 194.108.5.159 dev eth1 194.108.5.72/29 via 194.108.5.159 dev eth1 194.108.6.32/28 via 194.108.5.136 dev eth1 194.108.5.96/27 via 194.108.5.250 dev eth1 194.108.5.0/26 dev eth2 proto kernel scope link src 194.108.5.1 194.108.5.128/25 dev eth1 proto kernel scope link src 194.108.5.129 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.1 default via 194.108.196.209 dev eth0 As for "shorewall status > /tmp/status.txt" after "shorewall reset" and "telnet 194.108.5.163 25", I did that, the output is 511kB long but there is no single line related to the stmp connection I was trying to make so I am not sure if attaching such a beast would be useful to anybody. Well, actually there is one line but it''s the accounting info: 3 180 RETURN all -- eth1 * 194.108.5.163 0.0.0.0/0 0 0 RETURN all -- * eth1 0.0.0.0/0 194.108.5.163 Petr
On Monday 16 February 2004 08:42 am, Petr Stehlik wrote:> On Mon, 2004-02-16 at 16:45, Petr Stehlik wrote: > > > address 194.108.5.129 > > > netmask 255.255.255.128 > > > network 194.108.5.128 > > > broadcast 194.108.5.255 > > > up /sbin/route add -net 194.108.6.0/29 gw 194.108.5.164 > > > up /sbin/route add -net 194.108.6.8/30 gw 194.108.5.175 > > > > > > usr eth1:194.108.5.128/25,194.108.6.0/29,194.108.6.8/30 > > > > I must be doing something wrong anyway since ping between hosts in > > different subnets of eth1 works but telnet to smtp port does not :-( Any > > help is greatly appreciated. >> default via 194.108.196.209 dev eth0 > > As for "shorewall status > /tmp/status.txt" after "shorewall reset" and > "telnet 194.108.5.163 25", I did that, the output is 511kB longPlease sent it to me -- I wouldn''t have asked for it if I didn''t want to see all 511kb. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
V Po, 16. 02. 2004 v 19:06, Tom Eastep píše:> If you totally turn off Shorewall (shorewall clear), can you connect between > the local networks?yes! So shorewall clear is different from shorewall stop? Anyway, I am glad the routing is correct and that it''s up to me now to correct the shorewall setup and so get it working. A little more info (this is with shorewall active): if I telnet from 6.2 to 5.163, tcpdump on .163 shows 19:21:33.783953 www.sophics.cz.47929 > ns.salixtesneni.cz.smtp: S 1267848547:1267848547(0) win 5840 <mss 1460,sackOK,timestamp 321096016 0,nop,wscale 0> (DF) [tos 0x10] and the telnet is "Trying 194.108.5.163.." until it timeouts. if I telnet from 5.163 to 6.2, tcpdump on 6.2 shows 19:25:01.318725 ns.salixtesneni.cz.45495 > mail.sophics.cz.smtp: S 850012332:850012332(0) win 5840 <mss 1460,sackOK,timestamp 729990470 0,nop,wscale 0> (DF) [tos 0x10] and the telnet is "Connected to www.sophics.cz. Escape character is ''^]''." But the SMTP prompt doesn''t appear. Petr
On Monday 16 February 2004 10:34 am, Petr Stehlik wrote:> V Po, 16. 02. 2004 v 19:06, Tom Eastep píše: > > If you totally turn off Shorewall (shorewall clear), can you connect > > between the local networks? > > yes! So shorewall clear is different from shorewall stop? Anyway, I am > glad the routing is correct and that it''s up to me now to correct the > shorewall setup and so get it working. > > A little more info (this is with shorewall active): > > if I telnet from 6.2 to 5.163, tcpdump on .163 shows > 19:21:33.783953 www.sophics.cz.47929 > ns.salixtesneni.cz.smtp: S > 1267848547:1267848547(0) win 5840 <mss 1460,sackOK,timestamp 321096016 > 0,nop,wscale 0> (DF) [tos 0x10] > > and the telnet is "Trying 194.108.5.163.." until it timeouts. > > if I telnet from 5.163 to 6.2, tcpdump on 6.2 shows > 19:25:01.318725 ns.salixtesneni.cz.45495 > mail.sophics.cz.smtp: S > 850012332:850012332(0) win 5840 <mss 1460,sackOK,timestamp 729990470 > 0,nop,wscale 0> (DF) [tos 0x10] > > and the telnet is "Connected to www.sophics.cz. > Escape character is ''^]''." But the SMTP prompt doesn''t appear. >I don''t know what to tell you -- your Shorewall configuration is a complicated mess when seen through "shorewall status". If you tar up your /etc/shorewall directory and forward it, I''ll try to give you some advice... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Monday 16 February 2004 10:39 am, Tom Eastep wrote:> > Escape character is ''^]''." But the SMTP prompt doesn''t appear. > > I don''t know what to tell you -- your Shorewall configuration is a > complicated mess when seen through "shorewall status". If you tar up your > /etc/shorewall directory and forward it, I''ll try to give you some > advice... >Note that part of the "mess" is mine -- you are running 1.4.7 which generated a lot of extra rules for configurations like yours; if you would upgrade just to 1.4.7c, your ruleset would be a lot smaller in some areas. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
V Po, 16. 02. 2004 v 21:11, Tom Eastep píše:> > V Po, 16. 02. 2004 v 20:40, Tom Eastep píše: > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > > > > Dear Tom, it WORKS!!!<cut>> WARNING: What this means is this; the routing between the two internal > networks that you were using to test is asymmetric! In one direction, traffic > is going through the Shorewall box and in the other direction it isn''t. You > need to check the configuration of the internal routers.You''ve seen the routing: the eth1 is set up as 5.129 with .128/25 netmask primarily but we also want some additional subnets (like 6.0/29) to route via this eth1:5.164. It is set up with the "up" option "route add -net 6.0/29 gw 5.164" at the ifup time. Now if I can return to the subject of this thread: is it possible for shorewall to detect that 6.0/29 goes via the eth1 and so is in the same zone "usr" as the 5.128/25 automatically using the "detectnets" shorewall option (I would have to upgrade shorewall first to get to this option) or do I have to use the hosts file and list there all subnets on the eth1? Also, do I have to list all broadcasts in the interfaces file, like 5.255,6.7? Or is it possible to omit them.. You know, maintenance nightmare.. You see I assume the routing itself is not messed up but I might be wrong. Perhaps I need to change something at the other side? At the 6.0/29 server? The route there is set up so that everything goes to 5.129... Thanks for all your help. Petr
On Monday 16 February 2004 12:28 pm, Petr Stehlik wrote:> V Po, 16. 02. 2004 v 21:11, Tom Eastep píše: > > > V Po, 16. 02. 2004 v 20:40, Tom Eastep píše: > > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > > > > > > Dear Tom, it WORKS!!! > > <cut> > > > WARNING: What this means is this; the routing between the two internal > > networks that you were using to test is asymmetric! In one direction, > > traffic is going through the Shorewall box and in the other direction it > > isn''t. You need to check the configuration of the internal routers. > > You''ve seen the routing: the eth1 is set up as 5.129 with .128/25 > netmask primarily but we also want some additional subnets (like 6.0/29) > to route via this eth1:5.164. It is set up with the "up" option "route > add -net 6.0/29 gw 5.164" at the ifup time.The routing on the Shorewall box isn''t the problem -- it is one of the internal routers (such as 5.164) that is wrong.> > Now if I can return to the subject of this thread: is it possible for > shorewall to detect that 6.0/29 goes via the eth1 and so is in the same > zone "usr" as the 5.128/25 automatically using the "detectnets" > shorewall option (I would have to upgrade shorewall first to get to this > option) or do I have to use the hosts file and list there all subnets on > the eth1? > > Also, do I have to list all broadcasts in the interfaces file, like > 5.255,6.7? Or is it possible to omit them.. You know, maintenance > nightmare.. >Simply: /etc/shorewall/zones: usr /etc/shorewall/interfaces: usr eth1 detect routeback That''s *all there is too it* -- you don''t even have to enumerate the various internal networks. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
V Po, 16. 02. 2004 v 21:43, Tom Eastep píše:> > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > /etc/shorewall/interfaces: > usr eth1 detect routebackCool, ''detect'' is back :-) ''routeback'' also makes sense. And I dug in the docs and at last added newnotsyn there to rememeber me that the routing on eth1 is not OK (so in shorewall.conf I have the NEWNOTSYN back to default No). And when I was at it, I added also tcpflags and routefilter, as you suggest for WiFi.> The routing on the Shorewall box isn''t the problem -- it is one of >the internal routers (such as 5.164) that is wrong. just FYI, ip route show 194.108.6.0/29 dev eth0 proto kernel scope link src 194.108.6.1 194.108.5.128/25 dev eth2 proto kernel scope link src 194.108.5.164 default via 194.108.5.129 dev eth2 metric 1 Petr
On Monday 16 February 2004 02:45 pm, Petr Stehlik wrote:> V Po, 16. 02. 2004 v 21:43, Tom Eastep píše: > > > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > > > > /etc/shorewall/interfaces: > > usr eth1 detect routeback > > Cool, ''detect'' is back :-) ''routeback'' also makes sense. And I dug in > the docs and at last added newnotsyn there to rememeber me that the > routing on eth1 is not OK (so in shorewall.conf I have the NEWNOTSYN > back to default No). And when I was at it, I added also tcpflags and > routefilter, as you suggest for WiFi. > > > The routing on the Shorewall box isn''t the problem -- it is one of > > > the internal routers (such as 5.164) that is wrong. > > just FYI, ip route show > 194.108.6.0/29 dev eth0 proto kernel scope link src 194.108.6.1 > 194.108.5.128/25 dev eth2 proto kernel scope link src 194.108.5.164 > default via 194.108.5.129 dev eth2 metric 1 >Here''a a log message from your "shorewall status": Feb 16 15:42:25 usr2usr2:ACCEPT:IN=eth1 OUT=eth1 SRC=194.108.5.163 DST=194.108.6.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=28772 DF PROTO=TCP SPT=45487 DPT=25 WINDOW=5840 RES=0x00 SY N URGP=0 It shows that traffic from 194.108.5.163 to 194.108.6.2 is going through your Shorewall box; I think that traffic in the other direction is NOT going through your Shorewall box. Does 194.108.6.2 have it''s own route to 194.108.5.128/25? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom and others, sorry to getting back to this issue but unfortunately the easy setup without the hosts file did not work, see below: V Po, 16. 02. 2004 v 21:43, Tom Eastep píše:> > > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > > > > Dear Tom, it WORKS!!!> > > WARNING: What this means is this; the routing between the two internal > > > networks that you were using to test is asymmetric! In one direction, > > > traffic is going through the Shorewall box and in the other direction it > > > isn''t. You need to check the configuration of the internal routers. > > > > You''ve seen the routing: the eth1 is set up as 5.129 with .128/25 > > netmask primarily but we also want some additional subnets (like 6.0/29) > > to route via this eth1:5.164. It is set up with the "up" option "route > > add -net 6.0/29 gw 5.164" at the ifup time. > > The routing on the Shorewall box isn''t the problem -- it is one of the > internal routers (such as 5.164) that is wrong.Please note that originally the network setup was as follows: 5.129/25 eth1 -- Cisco router ~~ wifi ~~ 5.164 -- 6.0/29 They''ve taken out the Cisco router from the path and connected the wifi APs to the eth1 directly (well, via a hub). Since then the routing between 6.2 and others in the wifi 5.129/25 got broken if shorewall was active. There was no change at the 5.164 side and it used to work just fine for a long time so I thought that the routing there was OK. Weird that after removing the Cisco it broke and I had to start reconfiguring the Shorewall.> > Now if I can return to the subject of this thread: is it possible for > > shorewall to detect that 6.0/29 goes via the eth1 and so is in the same > > zone "usr" as the 5.128/25 automatically using the "detectnets"> Simply: > /etc/shorewall/interfaces: > usr eth1 detect routeback > > That''s *all there is too it* -- you don''t even have to enumerate the various > internal networks.Unfortunately this does not work, as I found out lately. One direction, the 6.2 -> 5.163 worked fine with the setup you suggest above, but the other direction (5.163->6.2) did not work - Shorewall at 5.129 reported "usr2all DROP" which means that it considered the additional 6.0/29 subnet as an alien thing and not part of the eth1 ''usr'' zone as the ''detect'' suggested. I had to go back to enumerating all subnets in the hosts file and, what''s even weirder, had to add a rule "usr usr ACCEPT" in the policy. I don''t know why the "detect" missed the additional eth1 subnets but before going further I am ready to upgrade to latest 1.4 version of Shorewall if you feel bored by me using old-ish 1.4.7 version. Petr
V Út, 17. 02. 2004 v 00:09, Tom Eastep píše:> > > The routing on the Shorewall box isn''t the problem -- it is one of > > > the internal routers (such as 5.164) that is wrong. > > > > just FYI, ip route show > > 194.108.6.0/29 dev eth0 proto kernel scope link src 194.108.6.1 > > 194.108.5.128/25 dev eth2 proto kernel scope link src 194.108.5.164 > > default via 194.108.5.129 dev eth2 metric 1> Here''a a log message from your "shorewall status": > > Feb 16 15:42:25 usr2usr2:ACCEPT:IN=eth1 OUT=eth1 SRC=194.108.5.163 > DST=194.108.6.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=28772 DF PROTO=TCP > SPT=45487 DPT=25 WINDOW=5840 RES=0x00 SY > N URGP=0 > > It shows that traffic from 194.108.5.163 to 194.108.6.2 is going through your > Shorewall box; I think that traffic in the other direction is NOT going > through your Shorewall box.Please look at the time of the log message - 15:42 - that was long time before you started helping me (17:07) so the log message shows only that at that time I was experiencing with separate zones - "usr" to "usr2" traffic (I had the 6.0/29 as a separate zone). I don''t know why "shorewall reset" didn''t clear these old and invalid log entries but they are definitely obsolete and just confusing.> Does 194.108.6.2 have it''s own route to > 194.108.5.128/25?As I show in another mail posted before a minute, the 6.2 is a server behind the 5.164 router (which is also a shorewall box, what else? :). The router has 5.164 at the wifi internet end and at the other end it is 6.1/29. So the 6.2 has basically one single route: everything but 6.0/29 goes to 6.1 (i.e. the 5.164 router): 194.108.6.0 0.0.0.0 255.255.255.248 U 0 0 0 eth2 0.0.0.0 194.108.6.1 0.0.0.0 UG 0 0 0 eth2 It may look weird at first but we obviously used to have one IP (5.164) and then we wanted more so we got assigned a 6.0/29 subnet that is routed via the 5.164 to us. And this was working OK until the Cisco router at the other side was removed from the chain 5.129 to WiFi APs. And it is still working fine as long as the shorewall at the 5.129/25 server is either cleared (shorewall clear) or the hosts files enumerate the additional subnets, shorewall.conf contains NEWNOTSYN=Yes and policy contains "usr usr ACCEPT" rule. I know you said the routing is wrong because the packets seems to go different paths forward and backward in one connection but I don''t know what could be wrong. I am still suspecting the additional subnets at 5.129 eth1 are not OK - guessing from the fact that the Shorewall there does not auto-detect them properly. Thanks. Petr
On Wednesday 18 February 2004 12:07 pm, Petr Stehlik wrote:> Tom and others, > > sorry to getting back to this issue but unfortunately the easy setup > without the hosts file did not work, see below: > > V Po, 16. 02. 2004 v 21:43, Tom Eastep píše: > > > > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > > > > > > > > > > Dear Tom, it WORKS!!! > > > > > > > > WARNING: What this means is this; the routing between the two > > > > internal networks that you were using to test is asymmetric! In one > > > > direction, traffic is going through the Shorewall box and in the > > > > other direction it isn''t. You need to check the configuration of the > > > > internal routers. > > > > > > You''ve seen the routing: the eth1 is set up as 5.129 with .128/25 > > > netmask primarily but we also want some additional subnets (like > > > 6.0/29) to route via this eth1:5.164. It is set up with the "up" option > > > "route add -net 6.0/29 gw 5.164" at the ifup time. > > > > The routing on the Shorewall box isn''t the problem -- it is one of the > > internal routers (such as 5.164) that is wrong. > > Please note that originally the network setup was as follows: > > 5.129/25 eth1 -- Cisco router ~~ wifi ~~ 5.164 -- 6.0/29I don''t understand what that diagram is showing.> > They''ve taken out the Cisco router from the path and connected the wifi > APs to the eth1 directly (well, via a hub). Since then the routing > between 6.2 and others in the wifi 5.129/25 got broken if shorewall was > active. There was no change at the 5.164 side and it used to work just > fine for a long time so I thought that the routing there was OK. Weird > that after removing the Cisco it broke and I had to start reconfiguring > the Shorewall. > > > > Now if I can return to the subject of this thread: is it possible for > > > shorewall to detect that 6.0/29 goes via the eth1 and so is in the same > > > zone "usr" as the 5.128/25 automatically using the "detectnets" > > > > Simply: > > /etc/shorewall/interfaces: > > usr eth1 detect routeback > > > > That''s *all there is too it* -- you don''t even have to enumerate the > > various internal networks. > > Unfortunately this does not work, as I found out lately. One direction, > the 6.2 -> 5.163 worked fine with the setup you suggest above, but the > other direction (5.163->6.2) did not work - Shorewall at 5.129 reported > "usr2all DROP" which means that it considered the additional 6.0/29 > subnet as an alien thing and not part of the eth1 ''usr'' zone as the > ''detect'' suggested.More evidence that the routing is messed up but since I don''t understand the network topology, I can''t help you. Is there a graphic available on the net that shows an *accurate* schematic diagram of your network?> > I had to go back to enumerating all subnets in the hosts file and, > what''s even weirder, had to add a rule "usr usr ACCEPT" in the policy. > > I don''t know why the "detect" missed the additional eth1 subnets but > before going further I am ready to upgrade to latest 1.4 version of > Shorewall if you feel bored by me using old-ish 1.4.7 version.It''s now going to help so long as I don''t understand your network topology, It''s clear from the symptoms that traffic is moving through your network in ways that you don''t expect but that''s all I can say. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wednesday 18 February 2004 12:09 pm, Petr Stehlik wrote:> V Út, 17. 02. 2004 v 00:09, Tom Eastep píše: > > > > The routing on the Shorewall box isn''t the problem -- it is one of > > > > > > > the internal routers (such as 5.164) that is wrong. > > > > > > just FYI, ip route show > > > 194.108.6.0/29 dev eth0 proto kernel scope link src 194.108.6.1 > > > 194.108.5.128/25 dev eth2 proto kernel scope link src 194.108.5.164 > > > default via 194.108.5.129 dev eth2 metric 1 > > > > Here''a a log message from your "shorewall status": > > > > Feb 16 15:42:25 usr2usr2:ACCEPT:IN=eth1 OUT=eth1 SRC=194.108.5.163 > > DST=194.108.6.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=28772 DF PROTO=TCP > > SPT=45487 DPT=25 WINDOW=5840 RES=0x00 SY > > N URGP=0 > > > > It shows that traffic from 194.108.5.163 to 194.108.6.2 is going through > > your Shorewall box; I think that traffic in the other direction is NOT > > going through your Shorewall box. > > Please look at the time of the log message - 15:42 - that was long time > before you started helping me (17:07) so the log message shows only that > at that time I was experiencing with separate zones - "usr" to "usr2" > traffic (I had the 6.0/29 as a separate zone). I don''t know why > "shorewall reset" didn''t clear these old and invalid log entries but > they are definitely obsolete and just confusing.Shorewall reset just resets the counters maintined by Netfilter in memory -- it doesn''t have anything to do with log messages. A "shorewall status" just prints the last 10 Shorewall messages in your log -- it couldn''t care less when they were produced. The time that the counters were last set is printed at the top so that you can tell which messages were created since then.> > > Does 194.108.6.2 have it''s own route to > > 194.108.5.128/25? > > As I show in another mail posted before a minute, the 6.2 is a server > behind the 5.164 router (which is also a shorewall box, what else? :). > The router has 5.164 at the wifi internet end and at the other end it is > 6.1/29. So the 6.2 has basically one single route: everything but 6.0/29 > goes to 6.1 (i.e. the 5.164 router): > > 194.108.6.0 0.0.0.0 255.255.255.248 U 0 0 0 > eth2 > 0.0.0.0 194.108.6.1 0.0.0.0 UG 0 0 0 > eth2 >Again, I need to see an accurate picture of this network.> It may look weird at first but we obviously used to have one IP (5.164) > and then we wanted more so we got assigned a 6.0/29 subnet that is > routed via the 5.164 to us. And this was working OK until the Cisco > router at the other side was removed from the chain 5.129 to WiFi APs. > And it is still working fine as long as the shorewall at the 5.129/25 > server is either cleared (shorewall clear) or the hosts files enumerate > the additional subnets, shorewall.conf contains NEWNOTSYN=Yes and policy > contains "usr usr ACCEPT" rule. > > I know you said the routing is wrong because the packets seems to go > different paths forward and backward in one connection but I don''t know > what could be wrong. I am still suspecting the additional subnets at > 5.129 eth1 are not OK - guessing from the fact that the Shorewall there > does not auto-detect them properly.What do you mean "Shorewall does not auto-detect them properly"? The version of Shorewall that you are running only "auto-detects" for the purposes of: a) Suppressing annoying messages due to subnet-level broadcasts. b) Masquerading/SNAT when you specify an interface name in the second column of /etc/shorewall/masq. Are broadcasts generating log messages or is masquerading from internal networks not working? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wednesday 18 February 2004 12:07 pm, Petr Stehlik wrote:> > Unfortunately this does not work, as I found out lately. One direction, > the 6.2 -> 5.163 worked fine with the setup you suggest above, but the > other direction (5.163->6.2) did not work - Shorewall at 5.129 reported > "usr2all DROP" which means that it considered the additional 6.0/29 > subnet as an alien thing and not part of the eth1 ''usr'' zone as the > ''detect'' suggested. >''detect'' in an /etc/shorewall/interfaces record means that Shorewall should detect broadcast addresses on the interface for the purpose of suppressing annoying messages due to policy logging; that''s all it does!!! The fact that traffic is getting dropped under ''usr2all'' means that the traffic came from the ''usr'' zone and didn''t match any rule specifying that zone as the source. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wednesday 18 February 2004 12:15 pm, Tom Eastep wrote:> On Wednesday 18 February 2004 12:07 pm, Petr Stehlik wrote: > > Tom and others, > > > > sorry to getting back to this issue but unfortunately the easy setup > > without the hosts file did not work, see below: > > > > V Po, 16. 02. 2004 v 21:43, Tom Eastep píše: > > > > > > > Try setting NEWNOTSYN=Yes in shorewall.conf. > > > > > > > > > > > > Dear Tom, it WORKS!!! > > > > > > > > > > WARNING: What this means is this; the routing between the two > > > > > internal networks that you were using to test is asymmetric! In one > > > > > direction, traffic is going through the Shorewall box and in the > > > > > other direction it isn''t. You need to check the configuration of > > > > > the internal routers. > > > > > > > > You''ve seen the routing: the eth1 is set up as 5.129 with .128/25 > > > > netmask primarily but we also want some additional subnets (like > > > > 6.0/29) to route via this eth1:5.164. It is set up with the "up" > > > > option "route add -net 6.0/29 gw 5.164" at the ifup time. > > > > > > The routing on the Shorewall box isn''t the problem -- it is one of the > > > internal routers (such as 5.164) that is wrong. > > > > Please note that originally the network setup was as follows: > > > > 5.129/25 eth1 -- Cisco router ~~ wifi ~~ 5.164 -- 6.0/29 > > I don''t understand what that diagram is showing.Ok -- I''ve read some more and pasted your various posts up on the wall and here is what I think the picture is: <shorewall router 1> eth1 (5.129) | |-------------- (5.163) Box X | eth? (5.164) <shorewall router 2> eth? (6.?/29) | | 6.2 Traffic from 6.2->5.163 never touches Shorewall router 1 Traffic from 6.163->6.2 goes through Shorewall router 1 since 5.129 is it''s default gateway. Hence, your routing is asymmetric. I suspect that the Cicso was routing all traffic from the 6.0/29 network to the 5.128/25 network through Shorewall router 1. When you removed that router, you broke the routing symmetry. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wed, 2004-02-18 at 21:24, Tom Eastep wrote:> > 5.129 eth1 are not OK - guessing from the fact that the Shorewall there > > does not auto-detect them properly. > > What do you mean "Shorewall does not auto-detect them properly"? The version > of Shorewall that you are running only "auto-detects" for the purposes of: > > a) Suppressing annoying messages due to subnet-level broadcasts.I see. My fault. I forgot that it''s in the broadcast column. Actually I was completely wrong (explaining in another message of this thread). Sorry.> Are broadcasts generating log messages or is masquerading from internal > networks not working?Not at all. See my other replies. And sorry for not replying earlier (yesterday night) but my wireless internet at home went down (yes, we are all wireless here ;) Petr
On Wed, 2004-02-18 at 22:23, Tom Eastep wrote:> Ok -- I''ve read some more and pasted your various posts up on the wall and > here is what I think the picture is: > > <shorewall router 1> > eth1 (5.129) > | > |-------------- (5.163) Box X > | > eth2 (5.164) > <shorewall router 2> > eth0 (6.1/29) > | > | > 6.2Exactly (I added the numbers in place of the ?). And the connection between 5.129, 5.163 and 5.164 is wireless, so there are several WAPs connected to the eth1, 5.163 and 5.164 are Orinoco cards etc. Doesn''t matter, hopefully (but perhaps explains why I couldn''t see the routing clearly before you made this simple schema).> Traffic from 6.2->5.163 never touches Shorewall router 1 > Traffic from 6.163->6.2 goes through Shorewall router 1 since 5.129 is it''s > default gateway. Hence, your routing is asymmetric.At last I can see it! The 5.163 does not know about my 6.0 subnet hooked to the wifi via the 5.164 and so it has to go through the default gateway 5.129, that''s correct. But in my 5.164 router I am doing a shortcut and routing to 5.163 directly even packets originating in the 6.0 subnet. And that''s the source of the problems. It''s so clear now. Thank you a lot, Tom. I''ll try to fix the 5.164 routing tonight. Petr
On Wed, 2004-02-18 at 22:11, Tom Eastep wrote:> ''detect'' in an /etc/shorewall/interfaces record means that Shorewall should > detect broadcast addresses on the interface for the purpose of suppressing > annoying messages due to policy logging; that''s all it does!!!Right, I apologized in previous reply.> The fact that traffic is getting dropped under ''usr2all'' means that the > traffic came from the ''usr'' zone and didn''t match any rule specifying that > zone as the source.I thought that 5.163 -> 6.2 would be an interzone traffic which should be allowed by default. Shorewall did not consider 6.2 the ''usr'' zone, though. It probably can''t guess it from the additional routes, or I have still something wrong (apart from the wrong routing at 6.0, of course!). Adding 6.0/26 to hosts helped to fix the usr2all DROP (well, it also required usr2usr ACCEPT rule): my policy: usr usr ACCEPT usr net ACCEPT usr all DROP debug I understand now that the routing from 6.2 to 5.163 is wrong and will fix it when the traffic goes low tonight. I am almost sure that it will allow me to set NEWNOTSYN option back to No. However, I am not sure if this helps shorewall to know that the 6.2 is to be in the ''usr'' zone. Maybe the best I can do now is to fix the routing first, then report back if there is still this problem. Thanks. Petr
On Thursday 19 February 2004 07:01 am, Petr Stehlik wrote:> > However, I am not sure if this helps shorewall to know that the 6.2 is > to be in the ''usr'' zone. Maybe the best I can do now is to fix the > routing first, then report back if there is still this problem.Yes -- let''s fix the known problem first. Then if you have problems with the simple configuration, please capture the information requested in the Shorewall Support Guide so that we have something to go on. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thu, 2004-02-19 at 16:08, Tom Eastep wrote:> > However, I am not sure if this helps shorewall to know that the 6.2 is > > to be in the ''usr'' zone. Maybe the best I can do now is to fix the > > routing first, then report back if there is still this problem. > > Yes -- let''s fix the known problem first. Then if you have problems with the > simple configuration, please capture the information requested in the > Shorewall Support Guide so that we have something to go on.Tom, I have added a great bunch of host routes to my 5.164 machine that ensure that traffic from 6.2 goes always via the 5.129 gateway (sorry I couldn''t think of anything smarter). Now the NEWNOTSYN is back to No and it works. Hosts file has no entry, Interfaces has just "detect" and "routeback" for eth1, and it still works. So far so good! The final problem with "usr2all DROP" I solved the best possible way: I re-read Shorewall''s excellent documentation, re-read it again, thought for a while and then re-read it for the third time and finally I got it: the "IntraZone Traffic" paragraph is clear - if I have a "usr all DROP" rule (which is in fact an "explicit policy governing traffic from that zone to itself" in my policy file, I have to specify "usr usr ACCEPT" as well, right? I am telling you, it''s clear (well, after I realized that "usr all DROP" includes also "usr usr DROP" :-)) So now I am done. Thank you a lot again. Petr
On Thursday 19 February 2004 11:10 am, Petr Stehlik wrote:> On Thu, 2004-02-19 at 16:08, Tom Eastep wrote: > > > However, I am not sure if this helps shorewall to know that the 6.2 is > > > to be in the ''usr'' zone. Maybe the best I can do now is to fix the > > > routing first, then report back if there is still this problem. > > > > Yes -- let''s fix the known problem first. Then if you have problems with > > the simple configuration, please capture the information requested in the > > Shorewall Support Guide so that we have something to go on. > > Tom, I have added a great bunch of host routes to my 5.164 machine that > ensure that traffic from 6.2 goes always via the 5.129 gateway (sorry I > couldn''t think of anything smarter).Define the primary address on the 5.128/25 as a /32. Add a host route to the other shorewall box and make that the default.> > Now the NEWNOTSYN is back to No and it works. Hosts file has no entry, > Interfaces has just "detect" and "routeback" for eth1, and it still > works. So far so good! > > The final problem with "usr2all DROP" I solved the best possible way: I > re-read Shorewall''s excellent documentation, re-read it again, thought > for a while and then re-read it for the third time and finally I got it: > the "IntraZone Traffic" paragraph is clear - if I have a "usr all DROP" > rule (which is in fact an "explicit policy governing traffic from that > zone to itself" in my policy file, I have to specify "usr usr ACCEPT" as > well, right?Yes.> I am telling you, it''s clear (well, after I realized that > "usr all DROP" includes also "usr usr DROP" :-))Yep :-)> > So now I am done. > > Thank you a lot again.You are welcome -- it was an interesting problem. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thursday 19 February 2004 12:46 pm, Tom Eastep wrote:> > Yes. > > > I am telling you, it''s clear (well, after I realized that > > "usr all DROP" includes also "usr usr DROP" :-)) > > Yep :-) >Actually, that''s not true -- Even in Shorewall 1.4.7, "usr all DROP" did not add a "usr usr DROP" rule. What output does "shorewall show usr2usr" produce? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
V Čt, 19. 02. 2004 v 22:05, Tom Eastep píše:> Actually, that''s not true -- Even in Shorewall 1.4.7, "usr all DROP" did not > add a "usr usr DROP" rule.Without "usr usr ACCEPT" it didn''t work, I _swear_: Feb 19 19:57:16 fw kernel: Shorewall:usr2all:DROP:IN=eth1 OUT=eth1 SRC=194.108.5.163 DST=194.108.6.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=43448 DF PROTO=TCP SPT=45773 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0> What output does "shorewall show usr2usr" produce?Shorewall-1.4.7 Chain usr2usr at fw - Thu Feb 19 22:23:51 CET 2004 Counters reset Thu Feb 19 20:12:56 CET 2004 Chain usr2usr (1 references) pkts bytes target prot opt in out source destination 3060 736K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 newnotsyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02 0 0 ACCEPT tcp -- * * 194.108.6.2 194.108.5.2 1 state NEW tcp dpt:80 60124 3421K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 BTW, what the heck is the 194.108.6.2 to 194.108.5.2 line? There is no http server on the 5.2 DNS machine so what does this mean? Has somebody hacked my 6.2 server and is now scanning other machines'' http ports? Weird. Even weirder since 5.2 is not usr zone at all! Petr
On Thursday 19 February 2004 01:31 pm, Petr Stehlik wrote:> V Čt, 19. 02. 2004 v 22:05, Tom Eastep píše: > > Actually, that''s not true -- Even in Shorewall 1.4.7, "usr all DROP" did > > not add a "usr usr DROP" rule. > > Without "usr usr ACCEPT" it didn''t work, I _swear_: > > Feb 19 19:57:16 fw kernel: Shorewall:usr2all:DROP:IN=eth1 OUT=eth1 > SRC=194.108.5.163 DST=194.108.6.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 > ID=43448 DF PROTO=TCP SPT=45773 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 > > > What output does "shorewall show usr2usr" produce? > > Shorewall-1.4.7 Chain usr2usr at fw - Thu Feb 19 22:23:51 CET 2004 > > Counters reset Thu Feb 19 20:12:56 CET 2004 > > Chain usr2usr (1 references) > pkts bytes target prot opt in out source > destination > > 3060 736K ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 > state RELATED,ESTABLISHED > 0 0 newnotsyn tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 > state NEW tcp flags:!0x16/0x02 > 0 0 ACCEPT tcp -- * * 194.108.6.2 > 194.108.5.2 > 1 state NEW tcp dpt:80 > 60124 3421K ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > BTW, what the heck is the 194.108.6.2 to 194.108.5.2 line? There is no > http server on the 5.2 DNS machine so what does this mean? Has somebody > hacked my 6.2 server and is now scanning other machines'' http ports? > Weird. Even weirder since 5.2 is not usr zone at all!Look at your rules file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
V Čt, 19. 02. 2004 v 22:32, Tom Eastep píše:> > > Actually, that''s not true -- Even in Shorewall 1.4.7, "usr all DROP" did > > > not add a "usr usr DROP" rule. > > > > Without "usr usr ACCEPT" it didn''t work, I _swear_: > > > > 0 0 ACCEPT tcp -- * * 194.108.6.2 > > 194.108.5.2 > > 1 state NEW tcp dpt:80 > > 60124 3421K ACCEPT all -- * * 0.0.0.0/0 > > 0.0.0.0/0 > > > > BTW, what the heck is the 194.108.6.2 to 194.108.5.2 line? There is no > > http server on the 5.2 DNS machine so what does this mean? Has somebody > > hacked my 6.2 server and is now scanning other machines'' http ports? > > Weird. Even weirder since 5.2 is not usr zone at all! > > Look at your rules file.I am getting confused now - are we working on anything yet? The last info was that "usr usr DROP" shouldn''t have been necessary because of my policy file. It seems that I have something in my rules file that causes the "usr usr ACCEPT" to be necessary. The "IntraZone Routing" talks also about "rules concerning connections from that zone to itself"... hmmm - oh, I can see it! There is one small hidden rule with symbolic names so it wasn''t apparent at a first glance: ACCEPT $NET_SOPHICS $USR_RT tcp http Well, you''re a detective. I would have never found this, I am sure. The 6.2 -> 5.2 issue is still unclear to me, there is no rule between NET_SOPHICS and DMZ_NS but that must be my fault as I haven''t tried to understand the shorewall show output. Well, it might be something as simple as wrong copy&paste so that the USR_RT''s IP ".251" got into "2\n1". Yeah, that would explain it. Oh yes, I have just run the command again. It''s 6.2 -> 5.251, i.e. the very ACCEPT line above. Thanks again. Shorewall show usr2usr is a powerful thing. Petr