The generic tunnel support that I posted about yesterday has been updated: a) A bug that caused [re]start errors has been corrected. b) A list of zones may now be included in the third column of /etc/shorewall/tunnels; the semantics are the same as for ipsec tunnels. In addition, the ADDRESS column in /etc/shorewall/masq may now contain a comma-separated list of IP ranges/addresses. This enables support for a pool of SNAT addresses that are comprised from more than one network (e.g., 206.124.146.2-206.124.146.253,130.252.100.2-130.252.100.253). -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom: Concerning item b) below, how hard was it to add the feature? I wonder if it is becoming easier as you create more high level support functions and then just find more places where you can use them. I hope I am right, but I thought I would ask. -- Steve Herber herber@thing.com work: 206-221-7262 Security Engineer, UW Medicine, IT Services home: 425-454-2399 On 6 Aug 2003, Tom Eastep wrote:> The generic tunnel support that I posted about yesterday has been > updated: > > a) A bug that caused [re]start errors has been corrected. > b) A list of zones may now be included in the third column of > /etc/shorewall/tunnels; the semantics are the same as for ipsec tunnels. > > In addition, the ADDRESS column in /etc/shorewall/masq may now contain a > comma-separated list of IP ranges/addresses. This enables support for a > pool of SNAT addresses that are comprised from more than one network > (e.g., 206.124.146.2-206.124.146.253,130.252.100.2-130.252.100.253). > > -Tom >
On Wed, 6 Aug 2003, Steve Herber wrote:> Tom: Concerning item b) below, how hard was it to add the feature?I finished work at 4PM (I start work at 7AM). I mixed a Martini and started making the enhancement. My wife called (she''s out of town this week). We talked for 20 minutes. I finished and tested the change. I checked IN the change at 4:50> > I wonder if it is becoming easier as you create more high level > support functions and then just find more places where you can use them. > I hope I am right, but I thought I would ask.At this point in Shorewall''s life cycle, the time I spend implementing changes is minimal. My time is spent: a) Supporting Shorewall b) Maintaining the documentation. c) Updating the documentation to reflect enhancements d) Doing releases (bugfix releases, Snapshots, full releases). With this profile, the real challenge is deciding WHAT to implement because I spend an insignificant portion of my "Shorewall" time actually implementing and testing changes. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
I think that I''ve completed the first version of Accounting support in Shoreall. It is based on yesterday''s snapshot and requires that you install the ''firewall'' script from the CVS /Shorewall project in /usr/share/shorewall/firewall and that you add the ''accounting'' file from that project to /etc/shorewall. The /etc/shorewall/accounting file has the following columns: ACTION - What to do when a match is found. COUNT - Simply count the match and continue trying to match the packet with the following accounting rules DONE - Count the match and don''t attempt to match any following accounting rules. <chain> - The name of a chain. Shorewall will create the chain automatically. If the name of the chain is followed by ":DONE" then after control returns from the named chain, the packet will not be matched against any of the following accounting rules. SOURCE - Packet Source The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. DESTINATION - Packet Destination Format the same as the SOURCE column. PROTOCOL A protocol name (from /etc/protocols), a protocol number. DEST PORT Destination Port number Service name from /etc/services or port number. May only be specified if the protocol is TCP or UDP (6 or 17). SOURCE PORT Source Port number Service name from /etc/services or port number. May only be specified if the protocol is TCP or UDP (6 or 17). In all columns except the first, the values "-","any" and "all" are treated as wild-cards. The accounting rules are evaluated in the Netfilter ''filter'' table. This is the same environment where the ''rules'' file rules are evaluated and in this environment, DNAT has already occurred in inbound packets and SNAT has not yet occurred on outbound ones. The accounting rules are placed in a chain called "accounting" and can thus be displayed using "shorewall show accounting". It should be noted that where the ACTION is <chain>:DONE then the entry generates two rules in "accounting"; the first is a jump to the named chain and the second is a RETURN rule which causes the accounting chain to be exited. Happy bean-counting... -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net