http://blog.gmane.org/gmane.comp.security.shorewall hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.security.shorewall/29710 <pre>I need some help here. I'm setting up an OpenVPN Connection point-to-point, every configuration looks allright, but I got one problem. Here's the schema: clients --- SERVER A ------ tunnel 1 (50.0.24.1) --- SERVER B (shorewall) --- tunnel 1 (50.0.24.2) --- clients (LAN) PS: I don't have access to the server A, the IT team from there just sent me the OpenVPN configuration to make the tunnel. IPs*trough the VPN connection. (50.0.24.2), but I can't ping the other side of the tunnel (50.0.24.1) and the other clients in that side. Here my confs: */etc/shorewall/interfaces* vpn tun+ detect */etc/shorewall/zones* vpn ipv4 */etc/shorewall/tunnels* openvpn:5024 net 0.0.0.0/0 */etc/shorewall/policy* loc loc ACCEPT $FW all ACCEPT vpn all ACCEPT all vpn ACCEPT net all DROP ULOG all all REJECT ULOG I don't think this is a problem with the OpenVPN configuration, 'cause from my Shorewall I can reach the other side of VPN. I guess it's just some detail in my rules. Thanks in advance. ____________________________ Jonatas Baldin de Oliveira Consultor de TI ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev</pre> Jonatas Baldin 2013-06-17T17:36:22 http://comments.gmane.org/gmane.comp.security.shorewall/29708 <pre>Hi, to debug something, I want to log everything from/to a specific IPv4, shorewall (iptables) sees. iptrace -s 1.2.3.4' should do the job. I verified the raw tables: # iptables -L -v -t raw -n Chain PREROUTING (policy ACCEPT 286 packets, 21942 bytes) pkts bytes target prot opt in out source destination 5 374 TRACE all -- * * 1.2.3.4 0.0.0.0/0 0 0 TRACE all -- * * 0.0.0.0/0 1.2.3.4 Chain OUTPUT (policy ACCEPT 265 packets, 61940 bytes) pkts bytes target prot opt in out source destination 0 0 TRACE all -- * * 1.2.3.4 0.0.0.0/0 8 14764 TRACE all -- * * 0.0.0.0/0 1.2.3.4 But /var/log/syslog, /var/log/messages and /var/log/kern.log is empty. Other messages from shorewall (for example I log connections from blacklist sources) I see in /var/log/kern.log, so I think logging at all should be working. Am I doing something wrong? I am using shorewall 4.5.17.1. </pre> Igor Sverkos 2013-06-16T21:53:08 http://comments.gmane.org/gmane.comp.security.shorewall/29707 <pre>Hello all, I'm using a Debian based system with Shorewall 4.5.5.3 and am trying to configure a setup with multiple public KVM-VMs; currently they are "brouted". I'm using the two-interface example config with the routeback option set in: /etc/shorewall/interfaces and /etc/shorewall/routestopped on the host. My host "/etc/network/interfaces" is as follows: auto eth0 iface eth0 inet static address (Main-Public-IP) netmask 255.255.255.255 pointopoint (Gateway-IP) gateway (Gateway-IP) auto vbr0 iface vbr0 inet static address (Main-Public-IP) netmask 255.255.255.255 pre-up ovs-vsctl add-br vbr0 pre-up ip link set up vbr0 pre-up ovs-vsctl set-controller vbr0 ptcp: pre-up ovs-vsctl set bridge vbr0 stp_enable=false up ip route add (Another-Public-IP)/32 dev vbr0 down ip route del (Another-Public-IP)/32 dev vbr0 up ip route add (Yet-Another-Public-IP)/32 dev vbr0 down ip route del (Yet-Another-Public-IP)/32 dev vbr0 The guests are using their own Shorewall instance with the one-interface example without routestopped. The guests "/etc/network/interfaces" are configured as follows: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address (Another-Public-IP) netmask 255.255.255.224 gateway (Main-Public-IP) Ok, this seems to be working (I haven't checked into ipsec, world-zones or bport-types...), but what I really need, is layer2 isolation, so that all my VMs (they don't need to "see" one another) can have the same mac-address. This can be done using QEMU/KVMs user mode networking (slirp) but the performance is poor. Now to my question, can someone on this list give me a real world working example, or at least more information, then "this should be doable with ovs-flows or vlans"; not that I am not willing to try using ovs-flows, or vlans, but without an explicit example, I'm bound to fail with my limited knowledge. I've tried using ovs-vlans, but couldn't get dhcp working with dnsmasq. I am well aware, that this is not the ovs-list, but I'm not necessarily looking for an ovs solution; maybe GRE-tunnels, point-to-point, etc. Any experts willing to help? Thanks and Regards, TF ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev</pre> Trebor Forban 2013-06-16T11:12:51 http://comments.gmane.org/gmane.comp.security.shorewall/29699 <pre>Hi, I was reading document http://shorewall.net/MultiISP.html#idp3634200. Inspired by the document I was trying to establish the following changes: * one additional interface: COMA_IF * COM[A,B,C]_IF interfaces request IP address via DHCP * all non-RFC 1918 destined trafic is NATed from INT_IF to COMA_IF * all non-RFC 1918 destined trafic from GW is routed via COMB_IF by default * non-RFC 1918 destined trafic from GW is possible to route via COMA_IF or COMC_IF if necessary Content of provider file: ComcastA 1 0x10000 - COMA_IF detect loose,fallback ComcastB 2 0x20000 - COMB_IF detect loose,fallback ComcastC 3 0x30000 - COMC_IF detect loose,fallback Content of tcrules file: 1:P 0.0.0.0/0 2 $FW At the moment all non-RFC 1918 destined trafic from GW is routed via eth1.10 which is not what I want. How do I correct that? Tero M ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev </pre> Tero M 2013-06-13T17:14:44 http://comments.gmane.org/gmane.comp.security.shorewall/29698 <pre>I have recently started blacklisting by accumulating lines in the blrules file, e.g. DROP net:200.62.170.200 all The number of lines is growing fairly quickly, so it occurred to me that I could improve maintenance by defining a macro to hide the fixed elements of these lines. I read http://shorewall.net/Macros.html carefully, but found it somewhat confusing because of the changes to macro support in recent releases. I thought I could code my entries very simply like this: KillHost 200.62.170.200 I am running shorewall 4.5.5.3, so I tried to use the format1 style in my macro.KillHost as follows: #ACTION SOURCE DEST DROP net:PARAM all ... but that was rejected "unknown destination zone (all)". Although this message does not really describe my syntax error, I take it to mean that I can only associate PARAM with the first field (ACTION). Is that correct? I read the section titled "Shorewall 4.4.16 and Later". I found the description of multiple parameters and default values confusing. I tried several permutations, although I am unsure what features would be acceptable (because I don't have 4.5.10), e.g. #ACTION SOURCE DEST DEFAULT 1 DROP $1 net:$2 all Could you help me with the correct syntax? If you are confident that something like this should work, I will try upgrading to a newer version. Thanks, Brian ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev </pre> Brian Burch 2013-06-13T14:32:08 http://comments.gmane.org/gmane.comp.security.shorewall/29691 <pre>Hi everybody, This is not strictly a Shorewall question, so please feel free to point me at the right book, technical something to consume. This will be TCP traffic and my TCP knowledge is weak. I have a possible scenario coming up like this: SiteA -- MPLS&lt; at &gt;3mb/s -- SiteB -- Internet&lt; at &gt;50mb/s Obviously I want to route traffic between Internet and SiteA. The owner of SiteB is concerned that we'll eat up more than our 3mb/s allowance because it's impossible to control the amount of requested data. If I apply policing at SiteB and drop packets going over the 3mb/s limit, I understand TCP will retry and get the data there eventually, but does that, in real-world terms limit the inbound traffic to a little over 3mb/s or can it just go wild on the inbound side. I have the ability to signal SiteA's firewall from SiteB so I can do things like modify rate limiting at SiteA based on SiteB's performance, but am clueless as to what will, if anything, work effectively. Anybody have experience with this? Thanks -- lee ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j</pre> Lee Brown 2013-06-09T01:18:29 http://comments.gmane.org/gmane.comp.security.shorewall/29689 <pre>Hello Everyone, We have a standalone Debian Wheezy box for game/web/VoIP server. My problem is that somehow the inbound traffic is limited to 4kbit/s to 8kbit/s by default whereas it's set to 3*full/10 with 9*full/10 ceiling. The interface is set to 100Mbit/sec and it actually gives that performance with the corresponding outbound traffic limits. Naturally when I stop shorewall this phantom limit disappears. I think I did everything by the book but I might have missed something. So I would like to set the default outbound limit to what's in the tcclasses and certain inbound ports to their appropriate values. (The dump files are in the attachment with the config files). There is another favour I'd like to ask: I never had the chance to show my firewall settings to anyone with more experiences and I am not very confident whether they are good enough. We have had a targeted DoS in the past straight after this box was set up in the last year but apparently these settings have solved that issue. May I ask you guys to please have a look at the files and share your suggestions if there is any. Many thanks in advance Regards Tony ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j</pre> Tony Sprader 2013-06-08T11:23:12 http://comments.gmane.org/gmane.comp.security.shorewall/29685 <pre>Hi, I'm using Shorewall and LSM to load-balance 3 ISPs. My configuration works, but when an ISP is disabled, LSM is unable to ping from the associated interface. I understand why it happens : when `shorewall disable isp1` is called, Shorewall flushes the routing table isp1, and removes the nexthop in the balance table. So when I want to ping 8.8.8.8 from eth1, no rule allows it. I've STFW'd, but the only trick I found is to add a default route to eth1 in the default table. The problem is, this only works with 1 ISP, as I can't add 3 default routes. So what is the best way to manage this ? Thanks for your attention. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j</pre> timothée cocault 2013-06-06T09:47:15 http://comments.gmane.org/gmane.comp.security.shorewall/29679 <pre>I've been successfully using shorewall to support dnat and snat for my configuration ever since an ancient cisco pix died 2 years ago. This linux firewall (hostname kerner) runs ubuntu 12.04 LTS, and so has the 3.2.0-32.51-generic kernel, iptables 1.4.12 and shorewall 4.4.26.1. Until a few weeks ago my static internet subnet (mask 255.255.255.240) was hosted by my ADSL router, running routertech linux-based firmware. I had been hand-crafting iptables rules for the router to act as a coarse filter for incoming traffic to my internet-facing hosts, but it did not do any natting. I decided I needed to use blacklisting in the coarse filter and realised that iptables maintenance would have become too arduous. I decided to move my static subnet onto a second linux system, which runs shorewall and pppd, so now the ADSL router runs as a simple pppoe bridge to my single ISP. This coarse filter system (hostname chenin) has been running well for the last 3 weeks. It has ubuntu 12.10, with a custom built 3.5.0-28-generic kernel, iptables 1.4.12 and shorewall 4.5.5.3. I started to add blacklisting rules: forbidden ports to identify attackers, then forbidden hosts to DROP all traffic from known attackers. As the kernel iptables log files became less noisy, I noticed clusters of messages reporting the arrival of martians from my original natting firewall. The source addresses corresponded to only two hosts on my safe lan, both with 10.1.252.x addresses. I ran wireshark (with various capture filters because there is a LOT of legitimate traffic) on both firewalls. There was no evidence of the martians on the natting system because ALL traffic had source addresses on my safe lan - the nat mechanism appears to happen downstream of the wireshark probe point. The martians appeared on the inside (static internet subnet) interface of the coarse filter firewall, along with legitimate traffic from the same hosts (my capture filter here selected the destination host), i.e. the same source host communications to the same internet server included a mixture of natted and martian packets. I started reading the shorewall FAQ and troubleshooting guides, as well general googling. The best advice seemed to check the status of reverse path filtering - rp_filter is set to 1 on both interfaces of both firewalls when shorewall status is "running". I don't think I have a problem with my shorewall rules on the natting system, but I wonder whether the kernel is actually using the rp_filter logic. I would have expected the natted outbound martian packets to be dropped at source, but perhaps rp_filter logic happens before nat? I don't want to drag anyone into my problem at this stage (which is why I have not attached all the appropriate configurations). I feel I have to bring the kernel and shorewall (on the natting firewall) more up to date first, then see whether the problem goes away. I will schedule the upgrade to 12.10 for some time in the next week. My main reasons for making this initial post are to document the current symptoms and see whether this is a well-known problem that I've failed to discover with my searches. I don't want to waste anyone's time (yet!) So (I hear you asking)... what are the martian packets? Here are my preliminary observations: 1. The two client source hosts are running ubuntu desktop 12.04 and 12.10 (see kernel notes above). They each have single network interfaces and have totally-open iptables. 2. The traffic associated with martians appears to be http and https from firefox. With parallel connections and many tabs open, there can be a lot of traffic to analyse! 3. Clusters of martians /seem/ to be associated with these machines "coming back from idle". The user of one system (a notepad) tends to close the lid, which suspends the system - martians appear when the lid is opened and the system resumes. The other system is a desktop which is never suspended, but the martians appear when the user reauthenticates a timer-locked session. (I am unsure whether martians originate from these two systems at times other than reauthentication). 4. My installation has several other systems, but I have not yet noticed martians originating from any of them. 5. The small sample of useful traces I have analysed show all the martian packets are FIN/ACK's associated with source ports different to those carrying properly natted data. The FIN/ACK's are retried with exponentially increasing timeouts until the connection presumably gets thrown away. (Because the packets are martians, the coarse filter firewall is discarding them, so the remote server never sees them to have an opinion about replying). 6. The remote hosts are legitimate web servers, so there is no malicious traffic involved. I suppose these web servers (e.g. facebook) run javascript on the browsers to keep event notification sessions alive. The firewall conntrack entries probably expire when the client systems become idle. I realise I could just shrug and ignore the martians. They are being detected and discarded, so they are doing no harm. However, I want to understand what is going on first, just in case it turns out to be a manifestation of a more significant problem. Thanks for an excellent product... and for listening, Brian ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j </pre> Brian Burch 2013-06-04T10:08:37 http://comments.gmane.org/gmane.comp.security.shorewall/29670 <pre>Due to a couple of defects in 4.5.17, I have uploaded 4.5.17.1. It is at www1.shorewall.net/ipv6.shorewall.net now and will be replicated to the mirrors over the next hour. Problems Corrected: 1) The following warning message may be emitted inappropriately when running shorewall 4.5.17. The message is no longer issued. The rule(s) generated by this entry are unreachable and have been discarded 2) Rules intended to increment nfacct objects would previously be optimized away when they immediately preceded an unconditional jump to the same target. Such rules are now retained. 3) A bug in the optimizer in 4.5.17 can cause 'set' and 'geoip' matches to be dropped. That has been corrected. I apologize for the inconvenience. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with &lt;2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2</pre> Tom Eastep 2013-06-02T22:16:53 http://comments.gmane.org/gmane.comp.security.shorewall/29668 <pre>So, at the end of my long list of (old-style) accounting rules I have a "catch-all": acc_unknown - $CGCOIF br-lan:0.0.0.0/0 acc_unknown - br-lan:0.0.0.0/0 $CGCOIF DONE--br-lan:0.0.0.0/0 DONE-br-lan:0.0.0.0/0 COUNT acc_unknown $CGCOIF br-lan COUNT acc_unknown br-lan $CGCOIF meant to account for anything that didn't get accounted for above it. The accounting rule above that are all working just fine, however this catch-all doesn't seem to get anything in it as you can see: Chain acc_unknown (2 references) pkts bytes target prot opt in out source destination 0 0 all -- eth1 br-lan 0.0.0.0/0 0.0.0.0/0 0 0 all -- br-lan eth1 0.0.0.0/0 0.0.0.0/0 Chain accounting (3 references) pkts bytes target prot opt in out source destination ... 0 0 acc_unknown all -- eth1 br-lan 0.0.0.0/0 0.0.0.0/0 0 0 acc_unknown all -- br-lan eth1 0.0.0.0/0 0.0.0.0/0 11988 941K RETURN all -- * br-lan 0.0.0.0/0 0.0.0.0/0 786 36304 RETURN all -- br-lan * 0.0.0.0/0 0.0.0.0/0 0 0 LOG all -- eth1 * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `Shorewall:acct:DROP:' 0 0 LOG all -- * eth1 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `Shorewall:acct:DROP:' Am I doing something wrong? Cheers, b. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with &lt;2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2</pre> Brian J. Murrell 2013-06-02T13:50:28 http://comments.gmane.org/gmane.comp.security.shorewall/29667 <pre>The Shorewall team is pleased to announce the availability of Shorewall 4.5.17. ---------------------------------------------------------------------------- I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E ---------------------------------------------------------------------------- 1) When INLINE was used in the tcrules file and no target ('-j' part) is included in the free-form part of the rule, an invalid iptables rule was generated. 2) Thanks to Roberto Sanchez, many typos in the manpages have been corrected. 3) A number of issues have been corrected in the Debian and Redhat/Fedora Shorewall-init SysV init scripts: a) Settings in ${SHAREDIR}/vardir are now handled correctly. b) Exit status is now returned correctly. c) Stale lock files are avoided. 4) When the compiled firewall script is run directly, it no longer attempts to copy itself onto itself using the 'cp' utility. 5) An optimizer defect that could leave unreferenced chains in the configuration has been corrected. 6) Unreferenced chains in the IPV6 nat table are now omitted. 7) Rules with trivial exclusion (a single net or ipset preceded by '!') now generate the iptables matches in the correct order. Previously, the exclusion match(es) was(were) placed at the end. This is important in rules that auto-increment nfacct objects. 8) Previously, conntrack helpers were enabled by the 'stop' command. Now, these helpers are only enabled by the 'clear' command. 9) Previously, an interface label (e.g., dev:N) could be specified as the 'physical' interface in /etc/shorewall/interfaces. This is now disallowed. 10) The Perl function 'shorewall' was not previously exported by Shorewall::Config, with the result that the function had to be called as Shorewall::Config::shorewall(...). the function is now exported and can be called from ?BEGIN PERL blocks as simply shorewall(...). 11) Previously, two ICMPv6 type names were mis-translated. address-unreachable was translated to 1/2; should be 1/3 port-unreachable was translated to 1/3; should be 1/4 These translations have been corrected. 12) If a TPROXY IPv6 address was specified in /etc/shorewall6/tcrules using the [&lt;address&gt;]/vlsm form (e.g., 'TPROXY(0x100,3129,[2001:470:b:227::44]/64)') then an 'Invalid Address' error was issued. This has been corrected. ---------------------------------------------------------------------------- I I. K N O W N P R O B L E M S R E M A I N I N G ---------------------------------------------------------------------------- 1) On systems running Upstart, shorewall-init cannot reliably secure the firewall before interfaces are brought up. ---------------------------------------------------------------------------- I I I. N E W F E A T U R E S I N T H I S R E L E A S E ---------------------------------------------------------------------------- 1) Route types 'blackhole', 'unreachable' and 'prohibit' are no longer copied to provider routing tables by default when USE_DEFAULT_RT=No. You may cause them to be copied by including 'blackhole', 'unreachable' and/or 'prohibit' in the COPY list along with interface names. 2) Previously, the generated script always added a host route to a provider's gateway in the provider's routing table. Beginning with this release, the 'noautosrc' provider option can be used to inhibit this behavior. 'noautosrc' must be used with care since the absense of such a route can cause start/restart runtime failures. 3) A '-c' (conditional) option has been added to the 'compile' command. This option causes compilation to proceed if: a) The specified (or defaulted) firewall script does not exist; or b) A file on the CONFIG_PATH (including any directory specified in the command) is newer than the existing script. 4) A new interface option has been added. destonly Causes the compiler to omit rules to handle traffic arriving on the interface. 5) It is now possible to use 'all+' in the SOURCE and DEST columns of /etc/shorewall[6]/policy file. It has the same meaning as in the rules file in that it can override default intra-zone ACCEPT policies. 6) Beginning with this release, most special handling of 'Auth' (TCP port 113) has been removed. In particular, the Drop default action will no longer default to silently REJECTing Auth requests but will rather simply process them like other tcp packets. 7) Traditionally, Shorewall has treated the loopback interface ('lo') as follows: - It deals with firewall-to-firewall, firewall-to-vserver, vserver-to-firewall, and vserver-to-vserver traffic. - All filtering is done in the OUTPUT flow; all traffic arriving on 'lo' is silently accepted. - If no firewall-to-firewall policy or rules are defined, then a simple ACCEPT rule is also included in the OUTPUT chain for 'lo' (after any vserver-oriented jumps). Beginning with this release, the handling of firewall-to-firewall traffic can be altered by adding a zone of type 'loopback'. - 'loopback' zones must be associated with the loopback device in the interfaces and/or hosts file. /etc/shorewall/zones #ZONETYPE looploopback /etc/shorewall/interfaces ?FORMAT 2 #ZONE INTERFACEOPTIONS loop lo... When this is done, the ACCEPT jumps for 'lo' in the INPUT and OUTPUT chains are omitted and replaced with jumps to the loop2fw and fw2loop (loop-fw and fw-lop) chains respectively. This provides a model similar to other zones for fireall-to-firewall traffic. 8) A new 'local' zone TYPE has been added to /etc/shorewall[6]/zones. A 'local' zone is similar to an 'ipv4' ('ipv6') zone, except that rules and policies to/from a 'local' zone may only be to/from the firewall zone and vserver zones. Thank you for using Shorewall, -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with &lt;2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 </pre> Tom Eastep 2013-05-31T18:57:41 http://comments.gmane.org/gmane.comp.security.shorewall/29661 <pre>hello, i have a setup which worked without a problem on debian squeeze (shorewall 4.4.11.6-3) and now don't work any more on debian wheezy (shorewall 4.5.5.3-3). the setup inlcudes 2 bridges br0 which briges to eth0 and br1 which bridges all virtual machines in a virtual lan. bridge name bridge id STP enabled interfaces br0 8000.001517ee821c no eth0 br1 8000.fe54365c6402 no vnet0 vnet1 vnet2 if i try to ping/connect the lan machines i get drops. Shorewall:FORWARD:DROP:IN=br1 OUT=br1 PHYSIN=vnet0 PHYSOUT=vnet2 MAC=52:54:36:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=10.12.10.5 DST=10.12.10.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=2686 SEQ=187 /etc/shorewall/policy ..... lan$FWACCEPTinfo lannetACCEPTinfo lanlanACCEPTinfo .... /etc/shorewall/shorewall.conf .... #this is set to Keep on squeeze and it is working IP_FORWARDING=Yes .... /etc/sysctl.conf .... net.ipv4.ip_forward=1 .... it's quite strange because, as i said before, the same setup works for me on squeeze (i am deploying with puppet). if i disable filtering the vmachines can ping each other. /etc/sysctl.conf .... net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 .... any ideas? regards julian ------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may </pre> dev< at >c33s.net 2013-05-23T19:54:59 http://comments.gmane.org/gmane.comp.security.shorewall/29656 <pre>Hi guys! I'm having a little problem. The scenario is: * Ubuntu 12.10 * 2 ADSL (PPPoE) connections. One on eth1 and the other on eth2 * I run pppd and get both working ok. * In /etc/default/shorewall put "wait interface ppp0 ppp1" for wait both connections on reboot. * I have a tcinterfaces for each ppp and tcclasses and tcfilters too. The problems occurs when the system has been rebooted for an update and one interface never goes up again. I move on /etc/default/shorewall the line "wait interface ppp0 ppp1" to "wait interface ppp0" and reboot again to see what happend and problem still there! What happend? The problem was the tcinterfaces, tcclasses and tcfilters have "ppp1" rules and because this link was down every time i start Shorewall. Shorewall says "start failed". I have to manually delete all lines on tc_ with ppp1 reference and then i can get shorewall up and running again. Is there any way to get this working without have to create 2 different /etc/shorewall/* files for both cases? Something like "shorewall disable tc ISP1" Best regards and thanks for read this email. </pre> Emiliano Vazquez 2013-05-23T02:57:24 http://comments.gmane.org/gmane.comp.security.shorewall/29651 <pre>Hi all: I see a lot of these messages: ######################### May 19 06:25:54 munin kernel: [3093836.996827] Shorewall:net2fw:DROP:IN=eth0 OUT = MAC=48:5b:39:ac:1b:5e:00:12:da:a4:14:bf:08:00 SRC=77.247.156.58 DST=x.x.x.x LEN=76 TOS=0x00 PREC=0x00 TTL=53 ID=32900 PROTO=UDP SPT=51327 DPT=38 LEN=56 May 19 06:27:03 munin kernel: [3093906.026783] Shorewall:net2fw:DROP:IN=eth0 OUT = MAC=48:5b:39:ac:1b:5e:00:12:da:a4:14:bf:08:00 SRC=77.247.156.58 DST=x.x.x.x LEN=76 TOS=0x00 PREC=0x00 TTL=53 ID=32901 PROTO=UDP SPT=51327 DPT=38 LEN=56 May 19 06:28:12 munin kernel: [3093975.060379] Shorewall:net2fw:DROP:IN=eth0 OUT = MAC=48:5b:39:ac:1b:5e:00:12:da:a4:14:bf:08:00 SRC=77.247.156.58 DST=x.x.x.x LEN=76 TOS=0x00 PREC=0x00 TTL=53 ID=32902 PROTO=UDP SPT=51327 DPT=38 LEN=56 ######################### At the time of writing 3096 entries and counting... I have filtered out my IP (DST=) UDP 38 is unknown to me and /etc/services did not give me a clue either. What's going on? Thanks - Øyvind ------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may </pre> Øyvind Lode 2013-05-21T16:12:59 http://comments.gmane.org/gmane.comp.security.shorewall/29647 <pre>Hi Is there any way to insert L7 rules by using the ndpi-netfilter module? /GH ------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may </pre> Göran Höglund 2013-05-21T08:37:34 http://comments.gmane.org/gmane.comp.security.shorewall/29646 <pre>Hi all, I have tried to figure out how to do this one but I think I have just confused myself more. My firewall is a 2 interface setup, the same box is my router to my uplink. I'm not using nat at all and have a public IP range behind this machine. net = eth0 loc = eth1 Most of my rules are mainly the basic HTTP(ACCEPT) net loc:111.111.111.112 SMTP(ACCEPT) net loc:111.111.111.113 etc This time around though I wish to just redirect (or is it translate) a port but because I'm not using nat etc I'm not sure if this is possible. I have a mail server behind my firewall that already has a rule in place SMTP(ACCEPT) net loc:111.1111.111.111 So this allows inbound port 25 connections to the machine on loc no issues at all. What I want to do is have an incoming connection on port 26 to 111.111.111.111 BUT redirect it to 111.111.111.111 but on port 25, is this possible? Cheers Adam ------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may</pre> adstar< at >genis-x.com 2013-05-21T05:53:19 http://comments.gmane.org/gmane.comp.security.shorewall/29643 <pre> On 5/1/13 9:48 AM, "rblake3" &lt;rblake3&lt; at &gt;hotmail.com&gt; wrote: Hello, I am currently attempting to masquerade traffic behind an internal interface (eth0) destined for the default gateway to go out of a firewall device located at the other end of an ipsec tunnel. I have attempted to use the providers feature to do this, but I can not figure out how to keep the ipsec tunnel up while having the traffic forwarded. At this point, the only thing I can think of is to exclude the far end IP address of the ipsec tunnel and leave everything else to pass through the other device. However, I was hoping there was a much simpler alternative. Quick overview of network: [The Internet] &lt;-----&gt; [Corporate HQ - IPSec Device &amp; Firewall (internal: 10.1.0.1)] &lt;—ipsec—&gt; [The Internet] &lt;—ipsec—&gt; [Remote Location – eth1] &lt;—shorewall--&gt; [Remote Location – eth0 (10.2.0.1)] &lt;---&gt; [Internal Network (10.2.0.0/24)] I went through the shorewall documentation and was unable to find anywhere that shows this particular example. I have tried using several configurations in the masq file, but to no avail: #INTERFACE SOURCE ADDRESS ... eth0 192.168.1.0/24 1.1.1.1 That rule says that packets routed out of eth0 with SOURCE IP in 192.168.1.0/24 should have their SOURCE IP changed to 1.1.1.1 #And also tried: eth0:10.1.0.1 eth0 That rule is meaningless. I am hoping the first example above is the correct format; however, that IP is on a far-end device. Also, I do not have an ipsec0 device since I am using spdadd rules with raccoon that create the static routes of the internal network at headquarters. I am certain this is a very simple issue and a solution will be as well, but I cannot seem to wrap my mind around it. I have included the shorewall &amp; kernel versions below for reference. Shorewall version: 4.4.24.1 Kernel version: 3.4.33-2.24-default (SMP x64) It might help us if you posted the output of 'shorewall dump' so we can see what your gateway configuration looks like. Be sure that ipsec-tools are installed before you capture the output. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. Thank you for your reply. I had a feeling both of the commands would not help, but I was being hopeful. At least now I'm certain of what the SOURCE ADDRESS implies (binding to a specific IP on an interface). Please see attached shorewall dump. Any assistance would be greatly appreciated. Ryan ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d</pre> rblake3 2013-05-20T18:06:00 http://comments.gmane.org/gmane.comp.security.shorewall/29632 <pre>Hi to everyone on the list! I`m having a problem creating a static route. Let me explain the escenary. I have a PC on the LAN (IP 192.168.1.8) who has conected to another network. I need to send all request to subnet 192.200.9.0/24 to 192.168.1.8 Is there any way to put this line into Shorewall ? i wan`t to do this because when shorewall restarts loose this route. Best regards. </pre> Emiliano Vazquez 2013-05-16T15:23:49 http://comments.gmane.org/gmane.comp.security.shorewall/29631 <pre>Hello List! I got a small (50mbits or so) application layer ddos attack against a few name servers (thousands of IPs sending lots of bogus A record requests - weird) - one of the name servers was behind a shorewall firewall. That firewall was running a 2.6.18-194.11.1.el5 kernel and shorewall-4.4.11.1-1. I noticed that the shorewall host had ksoftirqd using 100% of the CPU during the attack and was kind of slow in general as a result - I think this may have affected traffic to other hosts behind that firewall as well. Any ideas what would cause this? I was hoping to avoid this scenario in the future if possible since I plan on deploying some other name servers behind shorewall (latest stable on 2.6.32-358.0.1.el6.x86_64) as a result of this incident, but would ideally have a fix for this in place. I should probably point out that the blacklist file had around 500 entries in it - not sure that would have any effect on things. During the attack, the kernel logged a bunch of these: ip_conntrack: table full, dropping packet - Possibly the result of connection tracking? Does netfilter even track UDP "connections"? I thought UDP was connectionless. Is the only workaround for cases like this just to have larger connection tracking values in the kernel? Does that help with the ksoftirqd CPU use? Or is it best in this case to just not have it track connection state for DNS traffic at all and just forward the packets along? How is the ideal solution for this case implemented? Any help is appreciated! Michael P.S. The attack ended up coming from a bunch of networks mostly in Taiwan - had my provider drop traffic from those networks and the problem was solved. ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d </pre> Michael McCallister 2013-05-16T07:05:15 http://comments.gmane.org/gmane.comp.security.shorewall/29619 <pre>I have a zone (lets call it "net"), which has more than one network device attached to it (all interfaces within that zone are optional) and also have a catch-all statement in my "policy" file "all all DROP", which, I assumed, will produce a DROP rule at the end of each zone2zone chain not explicitly defined in that file. That is indeed the case for 99% of the zones, but for the net2net chain I have ACCEPT rule at the end, not DROP. I am certain I do not have any such rule either in my "rules" or "policy" files, so I am wondering what is the cause for this? ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may </pre> Dash Four 2013-05-11T22:08:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.shorewall