similar to: Redirect loc::80 to fw::3128 not work

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, on a system RedHat 8.0, only on this, not on other various RedHat8.0, I have see the follow strange error in /var/log/{messages,boot.log} ..... After the boot all it seems to work, the modules is loads.... I have already tried to install other versions of kernel but the problem is always the same one :-(( Someone has some idea of what is happening? Thanks... Dario Lesca

I''ve installed a bering box acting as a firewall for a lan; the lan is 192.168.1.0/24 the bering box is 192.168.1.254 I''ve installed a squid server 192.168.1.1 It is possible to configure shorewall for a transparent proxy to the squid server? I''ve tryed with REDIRECT loc loc:192.168.1.1:3128 tcp www - !192.168.1.1 in the rules file I get this error: Error:

Warning .... The two interface samples contain samples of the three interface... [root@multilinux temp]# tar xvfz samples-1.4.4/two-interfaces.tgz three-interfaces/ three-interfaces/interfaces three-interfaces/routestopped three-interfaces/masq three-interfaces/policy three-interfaces/rules three-interfaces/zones ------- Dario Lesca (d.lesca@ivrea.osra.it)

Hello, on my old system I''m using ipchains. Can anyone help me with converting rule /sbin/ipchains -A forward -j MASQ -s source_addr -d destination_addr 443 -p tcp to shorewall. I know that I can write eth0 source_addr to /etc/shorewall/masq file but I can''t found where I can specify the destination address. The reason for this is to allow one user (computer) access only to

It seems to me that ipsecnat tunnel type is not complete. Latest drafts of ipsec nat-traversal use udp port 4500 for nat-traversal communications. (It''s called port floating). That is needed to get rid of ugly ipsec passthru devices. Now ipsecnat opens port udp/500 from any source port. And I think ipsecnat won''t work at all with gw zone defined? I''m not sure about

While I''m in temporary retirement, I''ve decided spend a little time experimenting with new things and making some updates to the web site. The biggest result of this effort to date has been: http://shorewall.sf.net/Shorewall_Squid_Usage.html This outlines how to use Squid as a transparent proxy running on the firewall, in the DMZ or in the local network. In the latter two

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

Version 1.0 of the Quick Start Guide and accompanying sample configurations is available at: http://www.shorewall.net/shorewall_quickstart_guide.htm. Comments and suggestions are most welcome. Thanks, -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net

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

This article describes how to implement "Port Knocking" in Shorewall. http://shorewall.net/PortKnocking.html -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key

Il giorno gio, 05/03/2020 alle 15.07 +0000, Rowland penny via samba ha scritto: > I think I said use either the dhcp script or allow your clients to > update their own records. The problem is, if you previously used the > DHCP script, the clients records no longer belong to the clients, so > they will not be able to update them. Try deleting the records and > allow > the

On Tue Feb 17 11:14:15 GMT 2004, Andrew Bartlett wrote: >> Any suggestions for things to try (or even a guaranteed solution ;-) ) would >> be very much appreciated. >> server signing = no >Try this as yes. How did you get it work? I've tried the "server signing = yes or auto", but it didn't work. Could you kindly tell us how to set the XP to get it

Hi, I'm doing some tests of samba DC 4.12.0 + MIT (experimental) Kerberos + Bind DNS + Dhcpd + Chronyd on Fedora 32 beta. All work fine except this issue: The dhcp work, and the script for record the name of clients into dns is disable (like Rowland suggest). https://lists.samba.org/archive/samba-technical/2020-February/134875.html If I join a new windows client to domain all work fine and

Dear list members, Masquerading does''not work for me. This is a Mandrake Linux 10 system, but I use another kernel, that included in the original distribution (original: 2.6.3, now used 2.6.8 because of a lot of suck with OpenSwan with kernels prior 2.6.4). The problem seems to be similar or identical mentioned here:

hello , i''m currently trying to set-up Traffic Shapping with Shorewall and I have strong feelings that I found a bug. I may be mistaken, but I tried everything and can''t get it to work. I''ve turned ON TC_ENABLED=Yes and CLEAR_TC=Yes when i start shorewall ( shorewall start ), i get this message : Setting up Traffic Control Rules... TC Rule "2 eth1 0.0.0.0/0 tcp

Hello, I wonder if someone could use the TPROXY with Shorewall and transparent Squid  with using the routing rules on shorewall (tcrules) for hosts / networks (LAN) with multiples providers (WANs) directly from the internal network on port 80 (with TPROXY transparent squid or REDIRECT). On this issue, the routing rules is not work propertly because the source is the

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

> -----Original Message----- > From: Tom Eastep [mailto:teastep@shorewall.net] > Sent: Tuesday, May 14, 2002 1:15 PM > To: Shorewall Development > Subject: [Shorewall-devel] [Shorewall-users] Redirect loc::80 to > fw::3128 not work (fwd) > > > I''m beginning to believe that the use of the last column in the rules > file to designate redirection/forwarding is

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