The 3.1 Beta is now available -- check the Shorewall home page. -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On 16 May 2002 at 19:18, Tom Eastep wrote:> The 3.1 Beta is now available -- check the Shorewall home page.On this page..... (beta version) http://mail.shorewall.net/1.3/Documentation.htm#Rules Under the rules examples Rule 1 vs Rule 4 What is the significance of the 155.186.235.151 in the address portion of Rule Example 4? You''ve already said it would be DNAT in the action column (which is demonstrated to work in example 1). Is that needed in the case of a single public IP on the FW? ______________________________________ John Andersen NORCOM / Juneau, Alaska http://www.screenio.com/
On Fri, 17 May 2002, John Andersen wrote:> On 16 May 2002 at 19:18, Tom Eastep wrote: > > > The 3.1 Beta is now available -- check the Shorewall home page. > > On this page..... (beta version) > http://mail.shorewall.net/1.3/Documentation.htm#Rules > > Under the rules examples > Rule 1 vs Rule 4 > > What is the significance of the 155.186.235.151 in the > address portion of Rule Example 4? > > You''ve already said it would be DNAT in the action column > (which is demonstrated to work in example 1). > > Is that needed in the case of a single public IP on the FW? >It is not strictly needed in the first rule of the example as you have noted -- it IS needed in the second rule. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On 17 May 2002 at 14:18, Tom Eastep wrote: > > Is that needed in the case of a single public IP on the FW?> > > > It is not strictly needed in the first rule of the example as you have > noted -- it IS needed in the second rule.Well that''s clear as mud. ;-) The concept is not fully explained as to why you need that last column at all. I thought the reason for the DNAT action was to get around the need for that column. The comments in the rules file seem to talk about different concepts than the web page (forwarding vs Snat), and the webpage mentions forwarding not at all. You got two or three things (Port Forwarding, Dnat, Snat) that are being handled by some mysterious combination of uses of that column. Sorry If I''m being dense here. ______________________________________ John Andersen NORCOM / Juneau, Alaska http://www.screenio.com/
On Fri, 17 May 2002, John Andersen wrote:> > Well that''s clear as mud. ;-) > > The concept is not fully explained as to why you need that last > column at all. I thought the reason for the DNAT action was > to get around the need for that column. > > The comments in the rules file seem to talk about different > concepts than the web page (forwarding vs Snat), and the > webpage mentions forwarding not at all. > > You got two or three things (Port Forwarding, Dnat, Snat) > that are being handled by some mysterious combination > of uses of that column. > > Sorry If I''m being dense here. >Think about: a) a system with one external IP b) a system with 10 external IPs c) a system that requires forwarded connections to look like they came from the firewall. Now look at the rule: DNAT net loc:192.168.1.3 tcp 80 Now how is that rule going to handle all of the cases? It can''t! Given that most people who couldn''t understand the old way of doing things only have one interface, and given that automatically detecting an interface''s IP address isn''t that easy given that I don''t have access to half of the crap out there like PPPoE, I made the above rule work as: "Any connection to tcp port 80 that comes to the firewall from the net is going to be sent to 192.168.1.3" Note that''s EXACTLY what the old equivalent rule did: ACCEPT net loc:192.168.1.3 tcp 80 - all Now, consider case b) above. The admin of such a system probably doesn''t want requests on all 10 IP to be forwarded to 192.168.1.3, right? Let''s say that only traffic sent to external IP 1.2.3.4 should go to 192.168.1.3, ok? Now --- what kind of syntax might we come up with? Answer: DNAT net loc:192.68.1.3 tcp 80 - 1.2.3.4 Now there are obscure cases where people not only want to forward http requests send to 1.2.3.4 on to 192.168.1.3 but they want those requests to look to 192.168.1.3 like they came from 192.168.1.254. To do that, you would write: DNAT net loc:192.168.1.3 tcp 80 - 1.2.4.5:192.168.1.254 -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri, 17 May 2002, Tom Eastep wrote: Nice proofreading, Tom -- corrections below:> On Fri, 17 May 2002, John Andersen wrote: > > > > > Well that''s clear as mud. ;-) > > > > The concept is not fully explained as to why you need that last > > column at all. I thought the reason for the DNAT action was > > to get around the need for that column. > > > > The comments in the rules file seem to talk about different > > concepts than the web page (forwarding vs Snat), and the > > webpage mentions forwarding not at all. > > > > You got two or three things (Port Forwarding, Dnat, Snat) > > that are being handled by some mysterious combination > > of uses of that column. > > > > Sorry If I''m being dense here. > > > > Think about: > > a) a system with one external IP > b) a system with 10 external IPs > c) a system that requires forwarded connections to look like they came > from the firewall. > > Now look at the rule: > > DNAT net loc:192.168.1.3 tcp 80 > > Now how is that rule going to handle all of the cases? It can''t! > > Given that most people who couldn''t understand the old way of doing things > only have one interface, and given that automatically detecting an--------- replace with "external IP"> interface''s IP address isn''t that easy given that I don''t have access to > half of the crap out there like PPPoE, I made the above rule work as: > > "Any connection to tcp port 80 that comes to the firewall from the net is > going to be sent to 192.168.1.3" > > Note that''s EXACTLY what the old equivalent rule did: > > ACCEPT net loc:192.168.1.3 tcp 80 - all > > Now, consider case b) above. The admin of such a system probably doesn''t > want requests on all 10 IP to be forwarded to 192.168.1.3, right? Let''s > say that only traffic sent to external IP 1.2.3.4 should go to > 192.168.1.3, ok? Now --- what kind of syntax might we come up with? > Answer: > > DNAT net loc:192.68.1.3 tcp 80 - 1.2.3.4 > > Now there are obscure cases where people not only want to forward http > requests send to 1.2.3.4 on to 192.168.1.3 but they want those requests to > look to 192.168.1.3 like they came from 192.168.1.254. To do that, you > would write: > > DNAT net loc:192.168.1.3 tcp 80 - 1.2.4.5:192.168.1.254------- s/b "1.2.3.4" -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
I started using a Cisco Pix firewall about three years ago and the main problem I had was understanding some of the syntax for the port forwarding rules. What I really liked about shorewall was how simple the configuration files were for the simple cases. But I have always had a problem with the rules file because of the multiple possibilities. Not that the possibilities are bad, but because the syntax, just like the Pix syntax, doesn''t fit the way I look at network connections. I agree with John that lots happens in the file. I really like systems to be regular and consistent. Is there a reason that the order of the fields in the rules file and the tos file are different both in order and in name? The same goes for the policy file where the RESULT field is at the other end of the line and has a different name. And is there a good reason to use SOURCE/DEST some places but CLIENT/SERVER others? The current rules file: RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT_PORT(S) ADDRESS The current tos file: SOURCE DEST PROTOCOL SOURCE_PORTS DEST_PORTS TOS The current policy file: CLIENT SERVER POLICY LOG LEVEL Could these be changed to: The new rules file: POLICY SOURCE(S) DEST(S) PROTO SOURCE_PORT(S) DEST_PORT(S) ADDRESS The new tos file: SOURCE DEST PROTO SOURCE_PORTS DEST_PORTS TOS The new policy file: POLICY SOURCE DEST LOG LEVEL Or, the way I like to read these, left to right: The new rules file: POLICY SOURCE(S) PROTO SOURCE_PORT(S) DEST(S) DEST_PORT(S) ADDRESS The new tos file: SOURCE PROTO SOURCE_PORTS DEST DEST_PORTS TOS The new policy file: POLICY SOURCE DEST LOG LEVEL I don''t have a good name for the ADDRESS filed in the rules file. Maybe NAT_ADDRESS? I know the discussion is about adding the new POLICY types, DNAT, and so on, but I wonder if these changes would help and maybe negate the need for the extra rules? Thanks, -- Steve Herber herber@thing.com work: 206-261-0307 Systems Engineer, AMCIS, UoW home: 425-454-2399 On Fri, 17 May 2002, John Andersen wrote:> On 17 May 2002 at 14:18, Tom Eastep wrote: > > > > Is that needed in the case of a single public IP on the FW? > > > > > > > It is not strictly needed in the first rule of the example as you have > > noted -- it IS needed in the second rule. > > Well that''s clear as mud. ;-) > > The concept is not fully explained as to why you need that last > column at all. I thought the reason for the DNAT action was > to get around the need for that column. > > The comments in the rules file seem to talk about different > concepts than the web page (forwarding vs Snat), and the > webpage mentions forwarding not at all. > > You got two or three things (Port Forwarding, Dnat, Snat) > that are being handled by some mysterious combination > of uses of that column. > > Sorry If I''m being dense here. > > ______________________________________ > John Andersen > NORCOM / Juneau, Alaska > http://www.screenio.com/ > _______________________________________________
Below, (and the subsequent corrections) is a better explanation than
exists on the web. I wonder if the doc team could incorporate that.
Was any consideration gven to some modification of the source zone
designator ("net" in your examples below)?
Off hand I could think of a couple possible alternatives:
1) subzone file which lists for each zone the IPs or interfaces
therein such as:
subzone netA 1.2.3.4.5 1.2.3.4.6
subzone netB eth0 eth1
which would allow this syntax:
DNAT netA loc:192.168.1.3 tcp 80
DNAT netB:152.166.23.45 loc:192.168.3.1 tcp 22
DNAT net loc:129.168.1.5 tcp time
(last one above does not distinguish between
source subzones)
2) OR...Allowing subscripted zone designators
ALLOW net(1.2.3.4.5) .....
(but this gets kludgy when you want to limit the
incoming interfact AND the source IP
Either one of which gets rid of the last column, which is only
there to accommodate the complex setups, and having one
more file for them to use might be easier.
I''m not suggesting a re-write here Tom, just some suggestions
if you were planning to make changes anyway.
Again, your attached explanation is much clearer than
anything in the manual.
On 17 May 2002 at 16:17, Tom Eastep wrote:
> Think about:
>
> a) a system with one external IP
> b) a system with 10 external IPs
> c) a system that requires forwarded connections to look like they came
> from the firewall.
>
> Now look at the rule:
>
> DNAT net loc:192.168.1.3 tcp 80
>
> Now how is that rule going to handle all of the cases? It can''t!
>
> Given that most people who couldn''t understand the old way of
doing things
> only have one interface, and given that automatically detecting an
> interface''s IP address isn''t that easy given that I
don''t have access to
> half of the crap out there like PPPoE, I made the above rule work as:
>
> "Any connection to tcp port 80 that comes to the firewall from the net
is
> going to be sent to 192.168.1.3"
>
> Note that''s EXACTLY what the old equivalent rule did:
>
> ACCEPT net loc:192.168.1.3 tcp 80 - all
>
> Now, consider case b) above. The admin of such a system probably
doesn''t
> want requests on all 10 IP to be forwarded to 192.168.1.3, right?
Let''s
> say that only traffic sent to external IP 1.2.3.4 should go to
> 192.168.1.3, ok? Now --- what kind of syntax might we come up with?
> Answer:
>
> C
>
> Now there are obscure cases where people not only want to forward http
> requests send to 1.2.3.4 on to 192.168.1.3 but they want those requests to
> look to 192.168.1.3 like they came from 192.168.1.254. To do that, you
> would write:
>
> DNAT net loc:192.168.1.3 tcp 80 - 1.2.4.5:192.168.1.254
>
> -Tom
> --
> Tom Eastep \ Shorewall - iptables made easy
> AIM: tmeastep \ http://www.shorewall.net
> ICQ: #60745924 \ teastep@shorewall.net
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@shorewall.net
> http://www.shorewall.net/mailman/listinfo/shorewall-users
>
______________________________________
John Andersen
NORCOM / Juneau, Alaska
http://www.screenio.com/
On Fri, 17 May 2002, John Andersen wrote:> Either one of which gets rid of the last column, which is only > there to accommodate the complex setups, and having one > more file for them to use might be easier.Why? Having a column that is only there for "the complex setups" vs. having a whole new file that is only there for "the complex setups" seems to me to be a clear win for the column. If I add a new file: a) I have to provide a conversion program (or we can put your email address on the web site to have folks send you their configurations for manual conversion :-). b) Bering (floppy-based router) has very primitive tools (no ''awk'' even) so my conversion program gets to be built using these crude tools. c) I get to stay up nights debugging conversion problems. d) The conversion code gets to stay in the product forever (I made that mistake with Seawall, the predecessor of Shorewall). So, I think that the quick start guide shouldn''t even mention the last column and the more detailed documentation should try to explain it in the spirit of my earlier post. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri, 17 May 2002, Steve Herber wrote:> I started using a Cisco Pix firewall about three years ago and the > main problem I had was understanding some of the syntax for the port > forwarding rules. What I really liked about shorewall was how simple > the configuration files were for the simple cases. But I have always > had a problem with the rules file because of the multiple possibilities. > Not that the possibilities are bad, but because the syntax, just like the > Pix syntax, doesn''t fit the way I look at network connections. I agree > with John that lots happens in the file. > > I really like systems to be regular and consistent. Is there a reason that > the order of the fields in the rules file and the tos file are different both > in order and in name? The same goes for the policy file where the RESULT > field is at the other end of the line and has a different name. And is there > a good reason to use SOURCE/DEST some places but CLIENT/SERVER others? >I plead guilty about the names of the columns. Over 32+ years in the industry, I have mentally equated the terms SOURCE, CLIENT and REQUESTER, I''ve also equated DESTINATION and SERVER. In conversation, I use the equated terms more or less interchangably even though there are some subtle differences when they are used in the literature -- sorry. As to the order of the columns, I tried to make the most significant item relative to the algorithms first colunm in the file -- remember, I don''t have a database system here so I put the ''primary key'' at the beginning of the record. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri, 17 May 2002, Tom Eastep wrote:> On Fri, 17 May 2002, John Andersen wrote: > > > Either one of which gets rid of the last column, which is only > > there to accommodate the complex setups, and having one > > more file for them to use might be easier. > > Why? Having a column that is only there for "the complex setups" vs. > having a whole new file that is only there for "the complex setups" > seems to me to be a clear win for the column.Ah, but the column is inflicted on ALL users, many of them newbies like me, who find it confusing. Note that you need that column for virtually any inward routing from net to loc, such as many IM tools. Its not just for complex setups. At least this is so for the current version (not the beta).> > If I add a new file: > > a) I have to provide a conversion program (or we can put your email > address on the web site to have folks send you their configurations for > manual conversion :-). > b) Bering (floppy-based router) has very primitive tools (no ''awk'' > even) so my conversion program gets to be built using these crude tools. > c) I get to stay up nights debugging conversion problems. > d) The conversion code gets to stay in the product forever (I made that > mistake with Seawall, the predecessor of Shorewall).Yes, dragging around baggage from old versions it a pain. Would be easier to still honor the old format along with the new.> So, I think that the quick start guide shouldn''t even mention the last > column and the more detailed documentation should try to explain it in the > spirit of my earlier post.Thats good too. Like I said, your earlier explaination was the most concise i''ve seen on this topic. (But still leaves me wondering why the second line of the 4th example needed the ip in that column). JSA.
> As to the order of the columns, I tried to make the most significant item > relative to the algorithms first colunm in the file -- remember, I don''t > have a database system here so I put the ''primary key'' at the beginning of > the record. > > -TomAnd, I might add in your defense, that those other files are fiddeled with so rarely that they are seldom confusing. Often you set them up once and never deal with them again. JSA
On Fri, 17 May 2002, John Andersen wrote:> > Thats good too. Like I said, your earlier explaination was the most > concise i''ve seen on this topic. (But still leaves me wondering why > the second line of the 4th example needed the ip in that column). >When an internal user types "ftp:\\ftp.microsoft.com" in their browser, they are probably going to be surprised to connect the the ftp server in your DMZ -- that''s what would happen without that IP. A port forwarding rule is actually two rules: a) A rule about how and when to rewrite the destination address in the IP header. b) A rule allowing the rewritten packet to pass through the firewall to it''s destination. This duality is why (as Steve said in an earlier post), port forwarding rules tend to be confusing. Consider: DNAT loc dmz:192.168.2.2 tcp ftp That rule says how to rewrite packets originating from the local zone just like this one does for packets originating in the net zone: DNAT net dmz:192.168.2.2 tcp ftp In the case of the second rule all FTP connection requests that somehow manage to make it through the internet and arrive at your firewall are sent to 192.168.2.2. Now that makes sense when you only have one IP address as I described in the earlier post because if you got the request, it is probably addressed to you (ok -- someone on the same subnet could be playing games such that they are routing requests through your firewall but so what -- we''ll just send all such requests to the DMZ). Now apply that same logic to the first rule. Any FTP connection request that somehow manages to make it through your local network to arrive at your firewall is sent to 192.168.2.2 -- that''s why connection requests that the user wants to go to ftp.microsoft.com end up at the FTP server in the DMZ. Clearly not what you want... So -- the first rule is a little bit to liberal about the "when to rewrite the destination address" part, correct? By adding a qualification that says "only those local FTP connection requests that somehow manage to make it to the firewall AND THAT ARE ACTUALLY ADDRESSED TO THE FIREWALL should be sent to 192.168.2.2. Now notice that you could also add the address to the second rule above and it would still work. Most people don''t though because most people have dynamic IP addresses. With a dynamic address, it is better to use DNS tricks (like Bind 9 views) so that ftp.mydomain.dyndns.org resolves to 192.168.2.2 from the local lan (and from the firewall). That way, the first rule becomes a simple: ACCEPT loc dmz:192.168.2.2 tcp ftp -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Fri, 17 May 2002, Steve Herber wrote:> I started using a Cisco Pix firewall about three years ago and the > main problem I had was understanding some of the syntax for the port > forwarding rules. What I really liked about shorewall was how simple > the configuration files were for the simple cases. But I have always > had a problem with the rules file because of the multiple possibilities. > Not that the possibilities are bad, but because the syntax, just like the > Pix syntax, doesn''t fit the way I look at network connections. I agree > with John that lots happens in the file. >As I just wrote to John, port forwarding rules are confusing because they are actually two rules. If, as iptables does, you make these two rules totally separate then both rules are very easy to understand but then you have to remember to add two rules when you want to port forward rather than just one rule (and you have to remember to delete both rules when you no longer want to port forward).> I really like systems to be regular and consistent. Is there a reason that > the order of the fields in the rules file and the tos file are different both > in order and in name? The same goes for the policy file where the RESULT > field is at the other end of the line and has a different name. And is there > a good reason to use SOURCE/DEST some places but CLIENT/SERVER others? > > The current rules file: > RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT_PORT(S) ADDRESS > > The current tos file: > SOURCE DEST PROTOCOL SOURCE_PORTS DEST_PORTS TOS > > The current policy file: > CLIENT SERVER POLICY LOG LEVEL > > > Could these be changed to: > > The new rules file: > POLICY SOURCE(S) DEST(S) PROTO SOURCE_PORT(S) DEST_PORT(S) ADDRESS >Using POLICY for the the name of the first column is in my view even more confusing -- what is in this column ISN''T a policy but rather it is specifying what action to perform on connection requests that match this rule (that''s why the column is called ACTION in 1.3). Secondly, almost no rules specify SOURCE_PORT(S) -- so placing it before DEST_PORT(S) means that almost every rule is going to have to have "-" in that column (whereas placing it after DEST_PORTS(S) means that most rules can simply ignore it.> The new tos file: > SOURCE DEST PROTO SOURCE_PORTS DEST_PORTS TOS > > The new policy file: > POLICY SOURCE DEST LOG LEVEL > > > Or, the way I like to read these, left to right: > > The new rules file: > POLICY SOURCE(S) PROTO SOURCE_PORT(S) DEST(S) DEST_PORT(S) ADDRESS > > The new tos file: > SOURCE PROTO SOURCE_PORTS DEST DEST_PORTS TOS > > The new policy file: > POLICY SOURCE DEST LOG LEVEL > > > I don''t have a good name for the ADDRESS filed in the rules file. Maybe > NAT_ADDRESS? > > I know the discussion is about adding the new POLICY types, DNAT, and so on, > but I wonder if these changes would help and maybe negate the need for the > extra rules? >For the next beta, I''ll clean up the config files and documentation so that they uniformly use SOURCE and DESTINATION. That will make the code harder to read but for the most part, that''s my problem. Can you do the same with the sample configuration files so that they match the documentation (right now, they come from an assortment of old versions and are woefully out of date)? Thanks, -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811327-1271635655-1021731508=:26317 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 18 May 2002, Tom Eastep wrote:> > For the next beta, I''ll clean up the config files and documentation so > that they uniformly use SOURCE and DESTINATION. That will make the code > harder to read but for the most part, that''s my problem. > > Can you do the same with the sample configuration files so that they match > the documentation (right now, they come from an assortment of old versions > and are woefully out of date)? >Here''s a copy of the new RULES file -- comments are welcome. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net ---1463811327-1271635655-1021731508=:26317 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=rules Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.44.0205180718280.26317@wookie.shorewall.net> Content-Description: Rules File Content-Disposition: attachment; filename=rules Iw0KIyBTaG9yZXdhbGwgdmVyc2lvbiAxLjMgLSBSdWxlcyBGaWxlDQojDQoj IC9ldGMvc2hvcmV3YWxsL3J1bGVzDQojDQojCVJ1bGVzIGluIHRoaXMgZmls ZSBnb3Zlcm4gY29ubmVjdGlvbiBlc3RhYmxpc2htZW50LiBSZXF1ZXN0cyBh bmQNCiMJcmVzcG9uc2VzIGFyZSBhdXRvbWF0aWNhbGx5IGFsbG93ZWQgdXNp bmcgY29ubmVjdGlvbiB0cmFja2luZy4NCiMNCiMJSW4gbW9zdCBwbGFjZXMg d2hlcmUgYW4gSVAgYWRkcmVzcyBvciBzdWJuZXQgaXMgYWxsb3dlZCwgeW91 DQojCWNhbiBwcmVjZWVkIHRoZSBhZGRyZXNzL3N1Ym5ldCB3aXRoICIhIiAo ZS5nLiwgITE5Mi4xNjguMS4wLzI0KSB0bw0KIwlpbmRpY2F0ZSB0aGF0IHRo ZSBydWxlIG1hdGNoZXMgYWxsIGFkZHJlc3NlcyBleGNlcHQgdGhlIGFkZHJl c3Mvc3VibmV0DQojCWdpdmVuLiBOb3RpY2UgdGhhdCBubyB3aGl0ZSBzcGFj ZSBpcyBwZXJtaXR0ZWQgYmV0d2VlbiAiISIgYW5kIHRoZQ0KIwlhZGRyZXNz L3N1Ym5ldC4NCiMNCiMgQ29sdW1ucyBhcmU6DQojDQojDQojCUFDVElPTgkJ QUNDRVBULCBEUk9QLCBSRUpFQ1QsIEROQVQgb3IgUkVESVJFQ1QNCiMNCiMJ CQkJQUNDRVBUICAgLS0gYWxsb3cgdGhlIGNvbm5lY3Rpb24gcmVxdWVzdA0K IwkJCQlEUk9QICAgICAtLSBpZ25vcmUgdGhlIHJlcXVlc3QNCiMJCQkJUkVK RUNUICAgLS0gZGlzYWxsb3cgdGhlIHJlcXVlc3QgYW5kIHJldHVybiBhbg0K IwkJCQkJICAgIGljbXAtdW5yZWFjaGFibGUgb3IgYW4gUlNUIHBhY2tldC4N CiMJCQkJRE5BVCAgICAgLS0gRm9yd2FyZCB0aGUgcmVxdWVzdCB0byBhbm90 aGVyDQojCQkJCQkgICAgc3lzdGVtIChhbmQgb3B0aW9uYWxseSBhbm90aGVy IHBvcnQpLg0KIwkJCQlSRURJUkVDVCAtLSBSZWRpcmVjdCB0aGUgcmVxdWVz dCB0byBhIGxvY2FsDQojCQkJCQkgICAgcG9ydCBvbiB0aGUgZmlyZXdhbGwu DQojDQojCQkJTWF5IG9wdGlvbmFsbHkgYmUgZm9sbG93ZWQgYnkgIjoiIGFu ZCBhIHN5c2xvZyBsb2cNCiMJCQlsZXZlbCAoZS5nLCBSRUpFQ1Q6aW5mbyku IFRoaXMgY2F1c2VzIHRoZSBwYWNrZXQgdG8gYmUNCiMJCQlsb2dnZWQgYXQg dGhlIHNwZWNpZmllZCBsZXZlbC4NCiMNCiMJU09VUkNFCQlIb3N0cyBwZXJt aXR0ZWQgdG8gYmUgY2xpZW50cy4gTWF5IGJlIGEgem9uZSBkZWZpbmVkDQoj CQkJaW4gL2V0Yy9zaG9yZXdhbGwvem9uZXMgb3IgJEZXIHRvIGluZGljYXRl IHRoZQ0KIwkJCWZpcmV3YWxsIGl0c2VsZi4NCiMNCiMJCQlDbGllbnRzIG1h eSBiZSBmdXJ0aGVyIHJlc3RyaWN0ZWQgdG8gYSBsaXN0IG9mIHN1Ym5ldHMN CiMJCQlhbmQvb3IgaG9zdHMgYnkgYXBwZW5kaW5nICI6IiBhbmQgYSBjb21t YS1zZXBhcmF0ZWQNCiMJCQlsaXN0IG9mIHN1Ym5ldHMgYW5kL29yIGhvc3Rz LiBIb3N0cyBtYXkgYmUgc3BlY2lmaWVkDQojCQkJYnkgSVAgb3IgTUFDIGFk ZHJlc3M7IG1hYyBhZGRyZXNzZXMgbXVzdCBiZWdpbiB3aXRoDQojCQkJIn4i IGFuZCBtdXN0IHVzZSAiLSIgYXMgYSBzZXBhcmF0b3IuDQojDQojCQkJZG16 OjE5Mi4xNjguMi4yCQlIb3N0IDE5Mi4xNjguMi4yIGluIHRoZSBETVoNCiMN CiMJCQluZXQ6MTU1LjE4Ni4yMzUuMC8yNAlTdWJuZXQgMTU1LjE4Ni4yMzUu MC8yNCBvbiB0aGUNCiMJCQkJCQlJbnRlcm5ldA0KIw0KIwkJCWxvYzoxOTIu MTY4LjEuMSwxOTIuMTY4LjEuMg0KIwkJCQkJCUhvc3RzIDE5Mi4xNjguMS4x IGFuZA0KIwkJCQkJCTE5Mi4xNjguMS4yIGluIHRoZSBsb2NhbCB6b25lLg0K IwkJCWxvYzp+MDAtQTAtQzktMTUtMzktNzggIEhvc3QgaW4gdGhlIGxvY2Fs IHpvbmUgd2l0aA0KIyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTUFDIGFkZHJlc3MgMDA6QTA6Qzk6MTU6Mzk6Nzgu DQojDQojCQkJQWx0ZXJuYXRpdmVseSwgY2xpZW50cyBtYXkgYmUgc3BlY2lm aWVkIGJ5IGludGVyZmFjZQ0KIwkJCWJ5IGFwcGVuZGluZyAiOiIgZm9sbG93 ZWQgYnkgdGhlIGludGVyZmFjZSBuYW1lLiBGb3INCiMJCQlleGFtcGxlLCBs b2M6ZXRoMSBzcGVjaWZpZXMgYSBjbGllbnQgdGhhdA0KIwkJCWNvbW11bmlj YXRlcyB3aXRoIHRoZSBmaXJld2FsbCBzeXN0ZW0gdGhyb3VnaCBldGgxLg0K Iw0KIwlERVNUCQlMb2NhdGlvbiBvZiBTZXJ2ZXIuIE1heSBiZSBhIHpvbmUg ZGVmaW5lZCBpbg0KIwkJCS9ldGMvc2hvcmV3YWxsL3pvbmVzIG9yICRGVyB0 byBpbmRpY2F0ZSB0aGUgZmlyZXdhbGwNCiMJCQlpdHNlbGYuDQojDQojCQkJ VGhlIHNlcnZlciBtYXkgYmUgZnVydGhlciByZXN0cmljdGVkIHRvIGEgcGFy dGljdWxhcg0KIwkJCXN1Ym5ldCwgaG9zdCBvciBpbnRlcmZhY2UgYnkgYXBw ZW5kaW5nICI6IiBhbmQgdGhlDQojCQkJc3VibmV0LCBob3N0IG9yIGludGVy ZmFjZS4gU2VlIGFib3ZlLg0KIw0KIwkJCVRoZSBwb3J0IHRoYXQgdGhlIHNl cnZlciBpcyBsaXN0ZW5pbmcgb24gbWF5IGJlDQojCQkJaW5jbHVkZWQgYW5k IHNlcGFyYXRlZCBmcm9tIHRoZSBzZXJ2ZXIncyBJUCBhZGRyZXNzIGJ5DQoj CQkJIjoiLiBJZiBvbWl0dGVkLCB0aGUgZmlyZXdhbGwgd2lsbCBub3QgbW9k aWZpeSB0aGUNCiMJCQlkZXN0aW5hdGlvbiBwb3J0Lg0KIw0KIwkJCUV4YW1w bGU6IGxvYzoxOTIuMTY4LjEuMzozMTI4IHNwZWNpZmllcyBhIGxvY2FsDQoj CQkJc2VydmVyIGF0IElQIGFkZHJlc3MgMTkyLjE2OC4xLjMgYW5kIGxpc3Rl bmluZyBvbiBwb3J0DQojCQkJMzEyOC4gVGhlIHBvcnQgbnVtYmVyIE1VU1Qg YmUgc3BlY2lmaWVkIGFzIGFuIGludGVnZXINCiMJCQlhbmQgbm90IGFzIGEg bmFtZSBmcm9tIC9ldGMvc2VydmljZXMuDQojDQojCQkJaWYgdGhlIFJFU1VM VCBpcyBSRURJUkVDVCwgdGhpcyBjb2x1bW4gbmVlZHMgb25seSB0bw0KIwkJ CWNvbnRhaW4gdGhlIHBvcnQgbnVtYmVyIG9uIHRoZSBmaXJld2FsbCB0aGF0 IHRoZSByZXF1ZXN0DQojCQkJc2hvdWxkIGJlIHJlZGlyZWN0ZWQgdG8uDQoj DQojCVBST1RPCQlQcm90b2NvbCAtIE11c3QgYmUgInRjcCIsICJ1ZHAiLCAi aWNtcCIsIGEgbnVtYmVyLA0KIwkJCSJhbGwiIG9yICJyZWxhdGVkIi4gSWYg InJlbGF0ZWQiLCB0aGUgcmVtYWluZGVyIG9mIHRoZQ0KIwkJCWVudHJ5IG11 c3QgYmUgb21pdHRlZCBhbmQgY29ubmVjdGlvbiByZXF1ZXN0cyB0aGF0IGFy ZQ0KIwkJCXJlbGF0ZWQgdG8gZXhpc3RpbmcgcmVxdWVzdHMgd2lsbCBiZSBh Y2NlcHRlZC4NCiMNCiMJREVTVCBQT1JUKFMpICAgIERlc3RpbmF0aW9uIFBv cnRzLiBBIGNvbW1hLXNlcGFyYXRlZCBsaXN0IG9mIFBvcnQNCiMJCQluYW1l cyAoZnJvbSAvZXRjL3NlcnZpY2VzKSwgcG9ydCBudW1iZXJzIG9yIHBvcnQN CiMJCQlyYW5nZXM7IGlmIHRoZSBwcm90b2NvbCBpcyAiaWNtcCIsIHRoaXMg Y29sdW1uIGlzDQojCQkJaW50ZXJwcmV0ZWQgYXMgdGhlIGRlc3RpbmF0aW9u IGljbXAtdHlwZShzKS4NCiMNCiMJCQlUaGlzIGNvbHVtbiBpcyBpZ25vcmVk IGlmIFBST1RPQ09MID0gYWxsIGJ1dCBtdXN0IGJlDQojCQkJZW50ZXJlZCBp ZiBhbnkgb2YgdGhlIGZvbGxvd2luZyBpZWxkcyBhcmUgc3VwcGxpZWQuDQoj CQkJSW4gdGhhdCBjYXNlLCBpdCBpcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIGZp ZWxkIGNvbnRhaW4NCiMJCQkgIi0iDQojDQojCUNMSUVOVCBQT1JUKFMpCShP cHRpb25hbCkgUG9ydChzKSB1c2VkIGJ5IHRoZSBjbGllbnQuIElmIG9taXR0 ZWQsDQojCQkJYW55IHNvdXJjZSBwb3J0IGlzIGFjY2VwdGFibGUuIFNwZWNp ZmllZCBhcyBhIGNvbW1hLQ0KIwkJCXNlcGFyYXRlZCBsaXN0IG9mIHBvcnQg bmFtZXMsIHBvcnQgbnVtYmVycyBvciBwb3J0DQojCQkJcmFuZ2VzLg0KIw0K IwkJCUlmIHlvdSBkb24ndCB3YW50IHRvIHJlc3RyaWN0IGNsaWVudCBwb3J0 cyBidXQgbmVlZCB0bw0KIwkJCXNwZWNpZnkgYW4gQUREUkVTUyBpbiB0aGUg bmV4dCBjb2x1bW4sIHRoZW4gcGxhY2UgIi0iDQojCQkJaW4gdGhpcyBjb2x1 bW4uDQojDQojCU9SSUdJTkFMIERFU1QJKDBwdGlvbmFsIC0tIG9ubHkgYWxs b3dlZCBpZiBBQ1RJT04gaXMgRE5BVCBvciBSRURJUkVDVCkNCiMgICAgICAg ICAgICAgICAgICAgICAgIElmIGluY2x1ZGVkIGFuZCBkaWZmZXJlbnQgZnJv bSB0aGUgSVANCiMJCQlhZGRyZXNzIGdpdmVuIGluIHRoZSBTRVJWRVIgY29s dW1uLCB0aGlzIGlzIGFuIGFkZHJlc3MNCiMJCQlvbiBzb21lIGludGVyZmFj ZSBvbiB0aGUgZmlyZXdhbGwgYW5kIGNvbm5lY3Rpb25zIHRvDQojCQkJdGhh dCBhZGRyZXNzIHdpbGwgYmUgZm9yd2FyZGVkIHRvIHRoZSBJUCBhbmQgcG9y dA0KIwkJCXNwZWNpZmllZCBpbiB0aGUgREVTVCBjb2x1bW4uDQojDQojCQkJ VGhlIGFkZHJlc3MgbWF5IG9wdGlvbmFsbHkgYmUgZm9sbG93ZWQgYnkNCiMJ CQlhIGNvbG9uICgiOiIpIGFuZCBhIHNlY29uZCBJUCBhZGRyZXNzLiBUaGlz IGNhdXNlcw0KIwkJCVNob3Jld2FsbCB0byB1c2UgdGhlIHNlY29uZCBJUCBh ZGRyZXNzIGFzIHRoZSBzb3VyY2UNCiMJCQlhZGRyZXNzIGluIGZvcndhcmRl ZCBwYWNrZXRzLiBTZWUgdGhlIFNob3Jld2FsbA0KIwkJCWRvY3VtZW50YXRp b24gZm9yIHJlc3RyaWN0aW9ucyBjb25jZXJuaW5nIHRoaXMgZmVhdHVyZS4N CiMJCQlJZiBubyBzb3VyY2UgSVAgYWRkcmVzcyBpcyBnaXZlbiwgdGhlIG9y aWdpbmFsIHNvdXJjZQ0KIwkJCWFkZHJlc3MgaXMgbm90IGFsdGVyZWQuDQoj DQojCUV4YW1wbGU6IEFjY2VwdCBTTVRQIHJlcXVlc3RzIGZyb20gdGhlIERN WiB0byB0aGUgaW50ZXJuZXQNCiMNCiMJI0FDVElPTiBTT1VSQ0UJREVTVCBQ Uk9UTwlERVNUICAgIFNPVVJDRQlPUklHSU5BTA0KIwkjICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFBPUlQgICAgUE9SVChTKSBERVNUDQojCUFD Q0VQVAlkbXoJbmV0CSAgdGNwCXNtdHANCiMNCiMJRXhhbXBsZTogRm9yd2Fy ZCBhbGwgc3NoIGFuZCBodHRwIGNvbm5lY3Rpb24gcmVxdWVzdHMgZnJvbSB0 aGUgaW50ZXJuZXQNCiMJCSB0byBsb2NhbCBzeXN0ZW0gMTkyLjE2OC4xLjMN CiMNCiMJI0FDVElPTiBTT1VSQ0UJREVTVCAgICAgICAgICAgIFBST1RPCURF U1QgICAgU09VUkNFCU9SSUdJTkFMDQojCSMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBQT1JUICAgIFBPUlQoUykgREVTVA0KIwlE TkFUCW5ldAlsb2M6MTkyLjE2OC4xLjMgdGNwCXNzaCxodHRwDQojDQojCUV4 YW1wbGU6IFJlZGlyZWN0IGFsbCBsb2NhbGx5LW9yaWdpbmF0aW5nIHd3dyBj b25uZWN0aW9uIHJlcXVlc3RzIHRvDQojCQkgcG9ydCAzMTI4IG9uIHRoZSBm aXJld2FsbCAoU3F1aWQgcnVubmluZyBvbiB0aGUgZmlyZXdhbGwNCiMJCSBz eXN0ZW0pIGV4Y2VwdCB3aGVuIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGlz IDE5Mi4xNjguMi4yDQojDQojCSNBQ1RJT04gIFNPVVJDRQlERVNUICAgICAg UFJPVE8JREVTVCAgICBTT1VSQ0UJT1JJR0lOQUwNCiMJIyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBQT1JUICAgIFBPUlQoUykgREVTVA0KIwlS RURJUkVDVCBsb2MJMzEyOCAgICAgIHRjcAl3d3cJIC0JITE5Mi4xNjguMi4y DQojDQojCUV4YW1wbGU6IEFsbCBodHRwIHJlcXVlc3RzIGZyb20gdGhlIGlu dGVybmV0IHRvIGFkZHJlc3MNCiMgICAgICAgICAgICAgICAgMTMwLjI1Mi4x MDAuNjkgYXJlIHRvIGJlIGZvcndhcmRlZCB0byAxOTIuMTY4LjEuMw0KIw0K IwkjQUNUSU9OICBTT1VSQ0UJREVTVCAgICAgIAlQUk9UTwlERVNUICAgIFNP VVJDRQlPUklHSU5BTA0KIwkjICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAlQT1JUICAgIFBPUlQoUykgREVTVA0KIwlETkFUICAgICAgbmV0CWxv YzoxOTIuMTY4LjEuMyB0Y3AgICAgIDgwICAgICAgLSAgICAgICAxMzAuMjUy LjEwMC42OQ0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoj QUNUSU9OICBTT1VSQ0UJCURFU1QgICAgICAJUFJPVE8JREVTVCAgICBTT1VS Q0UJICAgT1JJR0lOQUwNCiMgICAgICAgICAgICAgICAgICAgICAgIAkgICAg ICAgIAlQT1JUICAgIFBPUlQoUykgICAgREVTVA0KI0xBU1QgTElORSAtLSBB REQgWU9VUiBFTlRSSUVTIEJFRk9SRSBUSElTIE9ORSAtLSBETyBOT1QgUkVN T1ZFDQo---1463811327-1271635655-1021731508=:26317--
On Sat, 18 May 2002, Tom Eastep wrote:> Can you do the same with the sample configuration files so that they match > the documentation (right now, they come from an assortment of old versions > and are woefully out of date)?While watching the Mariner game, I updated the samples. They can be found at http://www.shorewall.net/pub/shorewall/Beta/Samples as well as in CVS. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Sat, 18 May 2002, Tom Eastep wrote:> Now notice that you could also add the address to the second rule above > and it would still work. Most people don''t though because most people have > dynamic IP addresses. With a dynamic address, it is better to use DNS > tricks (like Bind 9 views) so that ftp.mydomain.dyndns.org resolves to > 192.168.2.2 from the local lan (and from the firewall). That way, the > first rule becomes a simple:On this last point, of the un-reliability of hard-codeing a dhcp IP in the last column... Thats a fairly sizeable problem for people with DMZs or who run some services on internal machines. The usual suggestion is to obtain a static ip. But failing that... As I understand it the shorewall syntax does not accept an interface name here (eth0) because you have to specify ip addresses to iptables, and you would have to fetch and insert the current IP(s) in place of the interface name. This would be good only till the IP changed. Is that a correct understanding? If so, could not "shorewall refresh" be used to fetch that new IP, thereby allowing that command to be run from the dhcp-client hooks option?
On Sun, 19 May 2002, John Andersen wrote:> > > On Sat, 18 May 2002, Tom Eastep wrote: > > > Now notice that you could also add the address to the second rule above > > and it would still work. Most people don''t though because most people have > > dynamic IP addresses. With a dynamic address, it is better to use DNS > > tricks (like Bind 9 views) so that ftp.mydomain.dyndns.org resolves to > > 192.168.2.2 from the local lan (and from the firewall). That way, the > > first rule becomes a simple: > > > On this last point, of the un-reliability of hard-codeing a dhcp IP > in the last column... > > Thats a fairly sizeable problem for people with DMZs or who > run some services on internal machines. The usual suggestion > is to obtain a static ip. But failing that... > > As I understand it the shorewall syntax does not accept > an interface name here (eth0) because you have to specify > ip addresses to iptables, and you would have to fetch > and insert the current IP(s) in place of the interface > name. This would be good only till the IP changed. > > Is that a correct understanding? >Yes.> If so, could not "shorewall refresh" be used to > fetch that new IP, thereby allowing that command > to be run from the dhcp-client hooks option? >No -- rule changes require a complete restart as opposed to a refresh. As for the dhcp-client hooks thing -- went through that with Seawall and did NOT want to get into it again with Shorewall. In my view, the ideal firewall is one that you can start BEFORE you bring up your IP interfaces. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
On Sun, 19 May 2002, John Andersen wrote:> > If so, could not "shorewall refresh" be used to > fetch that new IP, thereby allowing that command > to be run from the dhcp-client hooks option? >Note that if you want to, it''s not that hard to place the IP of an interface in arbitrary Shorewall rules without any new support from Shorewall. a) in /etc/shorewall/init, munge the output of your favorite IP utility and set a shell variable to the IP address of your external address such as: ETH1_ADDR=206.124.146.176 b) Now in your /etc/shorewall/rules file, you can place $ETH1_ADDR anywhere your heart desires. c) In your dhcp-client hooks file, include "/sbin/shorewall restart" when you detect that your IP address has changed. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Tom Eastep wrote: [....]> NOT want to get into it again with Shorewall. In my view, the ideal > firewall is one that you can start BEFORE you bring up your IP interfaces. >Full ACK! -- Ein Kreis ist ein rundes Quadrat. netzwerkplanet. -- Düsseldorf fon: 0211-9764091 mail: contact@netzwerkplanet.de PGP Key available