similar to: newnotsyn responsible for sporadic delays?

Hello, I''ve been doing some tests on a firewall system running Shorewall 1.4, and have been getting some unexpected behavior when enabling the "newnotsyn" option. In the test setup, I have: ---------------------------------------- /etc/shorewall/interfaces net eth0 detect routefilter,tcpflags,blacklist loc eth1 10.0.0.255 dhcp,tcpflags,newnotsyn

Hi, I''m running shorewall-2.0.8-1mdk with iptables-1.2.9-7.1.101mdk on kernel-2.4.22-30mdk, Mandrake 10.1 (kernel-2.6.8.1.10mdk-1-1mdk is installed, but I haven''t rebooted yet). I get a significant number of newnotsyn packet denials from existing, valid connections. Most of these seem to be on port 80 and port 25, and directionality doesn''t seem to matter (I run

Hi, I have shorewall version 1.4.10g on Redhat 9 Local clients are on eth1 in subnet 192.168.3.0/24. eth0 is for the outside (over xdsl with includes a ppp0 interface). Nessus (nessusd) is installed *on the firewall* and managed trough nessus (the client or frontend) running on one of the internal machines. When I was running a scan against 194.152.181.36 I observed several entries like

Hi Guys, I need some help. I''ve been using shorewall for a while now and it''s been running beautifully, but I''m now experiencing some problems. It seems that connections are getting dropped much like the behavior described by the NEWNOTSYN=no option in the shorewall.conf file, but I have NEWNOTSYN=Yes in my file. The messages I see in my logs are things like:

Hi! Shorewall Users May I know ..what does it means ? Nov 5 12:43:34 netgw kernel: Shorewall:newnotsyn:DROP:IN=eth0 OUT= MAC=00:05:5d:4e:fc:62:00:d0:95:7a:d5:f1:08:00 SRC=210.59.230.239 DST=211.24.146.50 LEN=52 TOS=0x00 PREC=0x00 TTL=48 ID=36787 PROTO=TCP SPT=80 DPT=20291 WINDOW=65160 RES=0x00 ACK FIN URGP=0 Best Regards, Support

I''m attempting to setup Squid as shown on: http://shorewall.sourceforge.net/Shorewall_Squid_Usage.html#DMZ The firewall is a Bering 1.0 firewall running Shorewall 1.3.11, Red Hat 7.2 on the server in the DMZ. I''m not seeing the requests come in to the server using tcpdump. The server is 192.168.2.1 connecting to eth2 on the firewall, the local traffic I''m trying to

Hi, I have a big "name problem" with my internal mail server (10.0.0.152). It is "seen" on the internet through DNAT (213.58.230.27). Also there is a MX record pointing to the machine. Everything works fine from the outside. However i can''t set the mail clients on the lan pointing to the mx record, because this one points to 213.58.230.27 and the firewall

I have what strikes me as an odd problem with shorewall. Let me describe my setup. My desktop (alfred) is connected to the network through an ADSL modem. I am running rp-pppoe, and this works perfectly. I have a small home network, with two LANs; an Ethernet LAN (including a machine running Windows XP), and a WiFi LAN, including the laptop (william) I am using now. All the computers except for

Problems Corrected: 1) A problem seen on RH7.3 systems where Shorewall encountered start errors when started using the "service" mechanism has been worked around. 2) A problem introduced in earlier snapshots has been corrected. This problem caused incorrect netfilter rules to be created when the destination zone in a rule was qualified by an address in CIDR format.

What''s the difference between a newnotsyn DROP and a blacklist DROP? Also, there''s a web site (SRC=62.193.203.132) that has been trying to connect to port 25 for a couple of weeks now. Is there a way to get someone upstream to add a block to that site for a small fish like me?

It''s now been over a week, and we are nearly at wits end trying to track down our performance issues here. We now have a P3/667 (single CPU! SMP was definitely the source of previous lockups) with 256Mb RAM. It is running along with a load avg of less than 0.1 even at peak times. Max ip_conntrack is around 1500-2000. Sounds fine, but, we have also tried 3 different squid proxies (2

I have just installed shorewall 2.2.0 beta 1 on a fedora core 1 box using ./install.sh to upgrade my existing install. shorewall check gave: Determining Zones... /usr/share/shorewall/firewall: line 2753: check_dupliate_zones: command not found Zones: net loc wifi dmz Fix in /usr/share/shorewall/firewall 2753c2753 < check_duplicate_zones --- > check_dupliate_zones Regards

In the panic of replacing our firewall(s) earlier in the week, we ended up moving our original shorewall 1.4 config onto a machine with 2.0.10 already installed, overwriting all the 2.0.10 config files. Most things seem to work fine, except for our masq entries. I''ve examined the default 2.0.10 files compared with our 1.4 files, and can''t spot the problem. What am I missing?

I have /bin/ash from rh8 installation and I have following error when I tried to change using ash instead of sh with shorewall-1.4.7: + eval options=$tap0_options + options= + list_search newnotsyn + local e=newnotsyn + [ 1 -gt 1 ] + return 1 + run_user_exit newnotsyn + find_file newnotsyn + [ -n -a -f /newnotsyn ] + echo /etc/shorewall/newnotsyn + local user_exit=/etc/shorewall/newnotsyn + [

I have had to replace an existing setup which has a bunch of IPs Proxy-NAT''ed onto the loc segment. While I do eventually want to move them to their own segment, I have to deal with this for the next few weeks. My problem is that from a loc system I can ping the public IP of a system being proxy-ARP''d but I can''t hit it via HTTP. Nothing is being blocked according

Hi, I''m using the same set of firewall rules of 2.0.x (sorry, I can''t remember the exact minor version) and put it to work with 2.0.9. And now I can''t do passive ftp (was working before). I see that my NEWNOTSYN is set to Yes, and the loc->net rule is blocking 1024:65535. But I believe with the ip_conntrack_ftp, the passive mode would be allowed, since

Shorewall 1.4.9 is now available. http://shorewall.net/pub/shorewall/shorewall-1.4.9 ftp://shorewall.net/pub/shorewall/shorewall-1.4.9 Unless something urgent comes up, this will be the last release of Shorewall 1.x. Release notes are attached. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \

I *think* we are finally making some progress in tracking our elusive performance problems. After employing a second 10Mb link from our ISP, along with another firewall box and proxy, we were able to determine the problem *is* our firewall. We don''t know exactly why yet, but our sporadic slow web access seems to have gone away since swapping a new firewall in this morning. The

The first Beta Version is available at: http://www.shorewall.net/pub/shorewall/Beta ftp://ftp.shorewall.net/pub/shorewall/Beta New features include: 1) "shorewall refresh" now reloads the traffic shaping rules (tcrules and tcstart). 2) "shorewall debug [re]start" now turns off debugging after an error occurs. This places the point of the failure near the end of the

There has been a low continuing level of confusion over the terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all instances of "Static NAT" have been replaced with "One-to-one NAT" on the web site and in the CVS configuration files (Shorewall/ project). The documentation in 1.4.9 will also contain this change. -Tom -- Tom Eastep \