similar to: Norfc1918 Blocks all (even with additional rule)

Hi all Is it possible to just forward port to local computer but not give open access for that port? If I''ve understood right that this rule does give ACCESS from net to loc too: DNAT net loc:192.168.1.5 udp 7777 What I''m trying to say is that it would work so that everything that''s coming from net to that local computers port is DROPed or REJECTed if it''s

The rule: ACCEPT loc $FW::3128 tcp www doesn''t work propertly, the http access does not redirect to squid but directly exit. what''s wrong? Thanks ------- Dario Lesca (d.lesca@ivrea.osra.it) -------------------------------------- @@@@@@@ this is my shorewall-1.2.13 config: #[/etc/shorewall/common.def]-----------------------------------------------

I''m beginning to believe that the use of the last column in the rules file to designate redirection/forwarding is too subtle for many users. For 1.3, I think I''ll do something like the following: Current rule: ACCEPT net loc:192.168.1.3 tcp 80 - all New rule: FORWARD net loc:192.168.1.3 tcp 80 Current rule: ACCEPT net fw::3128 tcp 80 - all New rule: REDIRECT net

Hi, I''m trying to enable ssh (when that works, want to add:pop3s,smtp,web) from the internet to the firewall but it does not work. I managed to DNAT ftp to a host in the loc network (192.168.0.50) successful but I don''t know why SSH: Does not work for me: ACCEPT net fw tcp 22 Works from the loc network: ACCEPT loc fw tcp 22 I have tried also with (no success): AllowSSH

Hello Tom. Sorry, don't answer on my previouse letter, i forget to set subject. I fix this in current. And now about my question. I ask you before about method of stopping RFC1918 traffic on external interface and you advised me follow rule: REJECT! all net:$RFC1918_NETS Can i replace this rule by 'norfc1918' option in 'interfaces' file for this interface?

Hello all, Yesterday I noticed that my system was "leaking" traffic towards the 10/8 network, I have shorewall installed on multiple machines ranging from single interface devices to ones with 10+ interfaces. I tested all the boxes and they are showing the same behavior. All systems are CentOS 3.4, 2.4.21-27.0.2.ELsmp. Shorewall version: 2.2.1 For the host mentioned is a single

Hello , The folllowing is the error problem: Validating interfaces file... ERROR: The ''norfc1918'' option may not be specified on an interface with an RFC 1918 address. Interface:eth2 The shorewall interface file: net eth2 detect tcpflags,routefilter,norfc1918,nosmurfs,logmartians P.S. I tried to remove norfc1918 from interface

Hi, Using shorewall for the first time (a woody .deb of version 1.2.12). After reading the docs, I still have a couple of questions regarding some parameters from the interfaces file. 1) Is rfc1918 not just a specific implementation of routefilter ? The sample file in two-interface.tgz uses them both, but they seem to at least overlap. Since my internal network will be 192.168.1.0/24, will

Hi to all, I''d like to cut some log in /var/log/messages, as of netbios and ping entries. There are some particular rules in shorewall 1.4.5? I''ve tried with "run_iptables -A common -p udp --sport 138 -mstate --state NEW -j DROP" but it contiunes to send to log every netbios attempt. Also I don''t want to disable ping from loc to net, and from fw to net. Thanks

i have no idea how to definie for a parallel zone the host file if the second zone (net) should be the composition of the first zone (dmz). i tried all the following combinations in the interface and host files: interface: - eth0 - (variante 1) - eth0 192.168.0.255,255,255,255,255 (variante 2) - eth0 192.168.0.255,!192.168.0.255 (variante 3)

Hi all, I was trying to test ROUTE specific code with a multi-isp serviced box. There is a bug somewhere, but I''m not able to understand what the real problem is: when I issue a "shorewall show capabilities" I get: Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... Shorewall has

Ok, I give up. I tried, really hard, before asking but I must be the most stupid shorewall user on the planet :( My laptop runs a single eth0 interface and knows Net and Firewall as zones and the default "inbound" policies are Net->Any DROP and >ny->Any REJECT. Now at home I have my trusted 192.168.174.240/29 subnet which hosts my very trusted 192.168.174.242 host and I

Hi all, The first couple of xen machines we setup used the default xen bridging setup for dom0. I am sure there are many other people out there with this setup. Now that I know a bit more there are probably better ways out there to configure the xen box for firewalling, most notably assigning the red card to a domU and running shorewall in there. But in the meantime I would like to further

I have defined a Home zone and placed it before the Net zone. Defined a host 192.168.174.242 as a trusted host. Now if I ping from 242 to my fw it works just fine (also tweaked the norfc1918 file). Thing I do not understand is why if I try pinging or FTPing from FW to 242 I hit the all2all reject rule ! I tried reading the rules and from the INPUT chain I see a eth0_in chain which in turn

Rafa³ Dutko has just discovered a potentially serious bug in version 1.3.0 and 1.3.1. In both versions, where an interface option appears on multiple interfaces, the option may only be applied to the first interface on which it appears. A corrected firewall script for 1.3.1 is available at: http://www.shorewall.net/pub/shorewall/errata/1.3.1/firewall and

Hi, I''ve attached a patch which fixes a logging problem with log_rule_limit in custom actions. E.g. this action: ,----[ Whitelist ] | if [ -n "$LEVEL" ]; then | run_iptables -N ${CHAIN}Add | log_rule_limit $LEVEL ${CHAIN}Add WhitelistAdd DROP "$LOG_LIMIT" $TAG | run_iptables -A ${CHAIN}Add -j DROP | run_iptables -N ${CHAIN}Del | log_rule_limit

This is a minor release of Shorewall. WARNING: This release introduces incompatibilities with prior releases. See http://www.shorewall.net/upgrade_issues.htm. Changes are: a) There is now a new NONE policy specifiable in /etc/shorewall/policy. This policy will cause Shorewall to assume that there will never be any traffic between the source and destination zones. b) Shorewall no longer

I made the following adjustments to /etc/shorewall/common.def (1.3.13 with all relevant patches). ############################################################################ # Shorewall 1.3 -- /etc/shorewall/common.def # # This file defines the rules that are applied before a policy of # DROP or REJECT is applied. In addition to the rules defined in this file, # the firewall will also define a

I am not subscribed to the list, so if you could CC me on replies, it would be appreciated. Hi there. I am running 2.0.8 on a linux 2.6 kernel with ipsec (i.e. no ipsec<n> interfaces). Since ipsec traffic comes in on the same interface as "net" traffic, I have been looking at the rules for "eth0_in" on my ipsec gateway/firewall. I see that "norfc1918" is

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.