Hi, I have a lot of records similar to this in the my shorewall log almost every second. Shorewall:fw2dmz:ACCEPT:IN= OUT=eth1 SRC=xxx.xxx.xxx.254 DST=xxx.xxx.xxx.226 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=28067 PROTO=ICMP TYPE=3 CODE=1 [SRC=xxx.xxx.xxx.226 DST=217.230.127.130 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=3318 WINDOW=0 RES=0x00 ACK RST URGP=0 ] Shorewall:fw2dmz:ACCEPT:IN= OUT=eth1 SRC=xxx.xxx.xxx.254 DST=xxx.xxx.xxx.45 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=49087 PROTO=ICMP TYPE=3 CODE=1 [SRC=xxx.xxx.xxx.45 DST=80.37.28.163 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=4894 WINDOW=0 RES=0x00 ACK RST URGP=0 ] The above record is copied exactly from the log and the xxx.xxx.xxx.xxx/24 is our network. The firewall ext. interface(eth0) is on a /30 is connected to router with a crossover cable. The dmz interface(xxx.xxx.xxx.254/24) connects to the class C network. Presently there is only one IP address used in the class C network to test the firewall(xxx.xxx.xxx.1), but there are so many similar requests made on all other IP addresses which have not been assigned in the same class. The destination addresses 217.230.127.130,80.37.28.163 in the square brackets is from somewhere outside and does not belong to our network. I am using shorewall-1.4.8-1 on a Cobalt RaQ4 running redhat linux 8.0 with kernel 2.4.20-18.8 patched for cobalt. The NIC on cobalt is an Intel pro100 and the dmz interface where this requests are made has about 20-30% packet loss when I try to ping from dmz to xxx.xxx.xxx.254. There is very less possibility that the NIC has a problem. Could this packet loss be occuring as a result of lot of those requests mentioned in the log ? The policy file : fw net ACCEPT info fw dmz ACCEPT info net fw DROP info all all REJECT info #LAST LINE -- DO NOT REMOVE The rules file : ### Rules for DMZ -> FW ACCEPT dmz:xxx.xxx.xxx.1 fw tcp 22 ### Rules for DMZ -> NET # DNS ACCEPT dmz net tcp 53 ACCEPT dmz net udp 53 # SSH ACCEPT dmz net tcp 22 # HTTP/HTTPS ACCEPT dmz net tcp 80 ACCEPT dmz net tcp 443 # SMTP/POP3/IMAP ACCEPT dmz net tcp 25 ACCEPT dmz net tcp 110 ACCEPT dmz net tcp 143 # FTP ACCEPT dmz net tcp 21 ACCEPT dmz net tcp 20 # TELNET ACCEPT dmz net tcp 23 # AUTH/IDENT DROP dmz net tcp 113 DROP dmz net udp 113 # SMB/NMB DROP dmz net udp 137 DROP dmz net udp 138 ### Rules for NET -> DMZ # DNS ACCEPT net dmz tcp 53 ACCEPT net dmz udp 53 # HTTP/HTTPS ACCEPT net dmz tcp 80 ACCEPT net dmz tcp 443 # SMTP/POP3/IMAP ACCEPT net dmz tcp 25 ACCEPT net dmz tcp 110 ACCEPT net dmz tcp 143 # FTP ACCEPT net dmz tcp 21 ACCEPT net dmz tcp 20 # SSH allowed only for yyy.yyy.yyy.yyy/24 ACCEPT net:yyy.yyy.yyy.yyy/24 dmz tcp 22 # Radius AUTH/ACCT ACCEPT net dmz udp 1645 ACCEPT net dmz udp 1646 # Pinging to and from fw and dmz ACCEPT fw all icmp 8 ACCEPT dmz:xxx.xxx.xxx.1 fw icmp 8 Regards, Bhavin.
Hi, I have a lot of records similar to this in the my shorewall log almost every second. Shorewall:fw2dmz:ACCEPT:IN= OUT=eth1 SRC=xxx.xxx.xxx.254 DST=xxx.xxx.xxx.226 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=28067 PROTO=ICMP TYPE=3 CODE=1 [SRC=xxx.xxx.xxx.226 DST=217.230.127.130 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=3318 WINDOW=0 RES=0x00 ACK RST URGP=0 ] Shorewall:fw2dmz:ACCEPT:IN= OUT=eth1 SRC=xxx.xxx.xxx.254 DST=xxx.xxx.xxx.45 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=49087 PROTO=ICMP TYPE=3 CODE=1 [SRC=xxx.xxx.xxx.45 DST=80.37.28.163 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=445 DPT=4894 WINDOW=0 RES=0x00 ACK RST URGP=0 ] The above record is copied exactly from the log and the xxx.xxx.xxx.xxx/24 is our network. The firewall ext. interface(eth0) is on a /30 is connected to router with a crossover cable. The dmz interface(xxx.xxx.xxx.254/24) connects to the class C network. Presently there is only one IP address used in the class C network to test the firewall(xxx.xxx.xxx.1), but there are so many similar requests made on all other IP addresses which have not been assigned in the same class. The destination addresses 217.230.127.130,80.37.28.163 in the square brackets is from somewhere outside and does not belong to our network. I am using shorewall-1.4.8-1 on a Cobalt RaQ4 running redhat linux 8.0 with kernel 2.4.20-18.8 patched for cobalt. The NIC on cobalt is an Intel pro100 and the dmz interface where this requests are made has about 20-30% packet loss when I try to ping from dmz to xxx.xxx.xxx.254. There is very less possibility that the NIC has a problem. Could this packet loss be occuring as a result of lot of those requests mentioned in the log ? The policy file : fw net ACCEPT info fw dmz ACCEPT info net fw DROP info all all REJECT info #LAST LINE -- DO NOT REMOVE The rules file : ### Rules for DMZ -> FW ACCEPT dmz:xxx.xxx.xxx.1 fw tcp 22 ### Rules for DMZ -> NET # DNS ACCEPT dmz net tcp 53 ACCEPT dmz net udp 53 # SSH ACCEPT dmz net tcp 22 # HTTP/HTTPS ACCEPT dmz net tcp 80 ACCEPT dmz net tcp 443 # SMTP/POP3/IMAP ACCEPT dmz net tcp 25 ACCEPT dmz net tcp 110 ACCEPT dmz net tcp 143 # FTP ACCEPT dmz net tcp 21 ACCEPT dmz net tcp 20 # TELNET ACCEPT dmz net tcp 23 # AUTH/IDENT DROP dmz net tcp 113 DROP dmz net udp 113 # SMB/NMB DROP dmz net udp 137 DROP dmz net udp 138 ### Rules for NET -> DMZ # DNS ACCEPT net dmz tcp 53 ACCEPT net dmz udp 53 # HTTP/HTTPS ACCEPT net dmz tcp 80 ACCEPT net dmz tcp 443 # SMTP/POP3/IMAP ACCEPT net dmz tcp 25 ACCEPT net dmz tcp 110 ACCEPT net dmz tcp 143 # FTP ACCEPT net dmz tcp 21 ACCEPT net dmz tcp 20 # SSH allowed only for yyy.yyy.yyy.yyy/24 ACCEPT net:yyy.yyy.yyy.yyy/24 dmz tcp 22 # Radius AUTH/ACCT ACCEPT net dmz udp 1645 ACCEPT net dmz udp 1646 # Pinging to and from fw and dmz ACCEPT fw all icmp 8 ACCEPT dmz:xxx.xxx.xxx.1 fw icmp 8 Thanks, Bhavin.
On Wednesday 03 March 2004 03:09 pm, Bhavin Modi wrote:> > Shorewall:fw2dmz:ACCEPT:IN= OUT=eth1 SRC=xxx.xxx.xxx.254 DST=xxx.xxx.xxx.45 > LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=49087 PROTO=ICMP TYPE=3 CODE=1 > [SRC=xxx.xxx.xxx.45 DST=80.37.28.163 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 > DF PROTO=TCP SPT=445 DPT=4894 WINDOW=0 RES=0x00 ACK RST URGP=0 ]> > The policy file : > fw net ACCEPT info > fw dmz ACCEPT infoIt is my opinion that anyone who logs ACCEPT policies should know enough about IP to be able to understand the messages that are going to be logged. Nevertheless, FAQ #21 may give you a hint... -Tom PS -- and please don''t repost your question every hour when you don''t get a response. If you want immediate response to your support questions, buy a commercial firewall. -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Hello, I looking for possibility how to handle this case. I have 2 interfaces on my router. One is conected to local network, second to internet. I have NAT set properly. I have several several subnets in my local network. I have some users at my local network. I generate ACCEPT rules to permit traffic from theirs IP addreses to internet. For the rest of non listed IP addresses I want redirect rule - redirect traffic originaly destined to port 80 proto TCP to firewall itself, port 80. I created redirect rule. Problem is, that this rule is proccessed in prerouting chain and ACCEPT rules are proccesed in forwarding chain. It means that all traffic destined to port 80 is redirected to the network, doesn''t matter on source ip. Then I tried to exclude permited IP from redirect rule by source_zone!host,host,host syntax. Unfortunately seems that my rule: REDIRECT unh!192.168.140.68/32,192.168.140.69/32,192.168.140.70/32,192.168.140.71 /32,192.168.141.198/32,192.168.141.2/32,192.168.142.2/32,192.168.150.198 /32,192.168.140.198/32,192.168.141.78/32,192.168.140.206/32,192.168.140. 210/32,192.168.140.202/32,192.168.141.218/32,192.168.141.202/32,192.168. 141.214/32,192.168.143.2/32,192.168.141.70/32,192.168.141.210/32,192.168 .143.8/32,192.168.143.26/32,192.168.143.14/32,192.168.143.6/32,192.168.1 42.8/32,192.168.142.4/32,192.168.142.10/32,192.168.142.12/32,192.168.143 .18/32,192.168.143.20/32,192.168.141.246/32,192.168.141.74/32,192.168.15 0.230/32,192.168.150.234/32,192.168.150.222/32,192.168.150.4/32,192.168. 150.210/32,192.168.150.202/32,192.168.150.250/32,192.168.141.242/32,192. 168.141.206/32,192.168.141.226/32,192.168.141.230/32,192.168.141.238/32, 192.168.141.234/32,192.168.140.218/32,192.168.140.251/32,192.168.143.10/ 32,192.168.140.250/32,192.168.141.222/32,192.168.150.218/32,192.168.143. 22/32,192.168.142.14/32,192.168.140.214/32,192.168.143.198/32,192.168.14 3.24/32,192.168.150.226/32 80 tcp http - !192.168.140.2 won''t work - it can''t be proccesed by shorewall - probadly because after exclude sign - !there should be hosts listed from /etc/shorewall/hosts file. But také a look how many ip I need to redirect. And there are changing dynmicaly. So I don''t want to fill hosts file each time. I probably missed some elagant solution how to handle this case. Please can you help me to find it out? Thank you. Regards litin
On Wednesday 03 March 2004 03:39 pm, Dominik Strnad wrote:> Hello, > I looking for possibility how to handle this case. > > I have 2 interfaces on my router. One is conected to local network, > second to internet. I have NAT set properly. I have several several > subnets in my local network. > > I have some users at my local network. I generate ACCEPT rules to permit > traffic from theirs IP addreses to internet. For the rest of non listed > IP addresses I want redirect rule - redirect traffic originaly destined > to port 80 proto TCP to firewall itself, port 80. > > I created redirect rule. Problem is, that this rule is proccessed in > prerouting chain and ACCEPT rules are proccesed in forwarding chain. > It means that all traffic destined to port 80 is redirected to the > network, doesn''t matter on source ip. > > Then I tried to exclude permited IP from redirect rule by > > source_zone!host,host,hostThat is NOT the syntax -- the syntax is: source_zone!zone,... Each of the zones listed needs to be defined -- probably using /etc/shorewall/hosts.> But také a look how many ip I need to redirect. And there are changing > dynmicaly. So I don''t want to fill hosts file each time. > > I probably missed some elagant solution how to handle this case. Please > can you help me to find it out?I''m afraid that it is an ugly problem that requires an ugly solution. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net