Jerry Vonau wrote:
Getting the "squid in loc" to work with "loose" took a bit of effort
but that works now. Give me a bit, I'll have some config info that
worked for me if you want.
Please -- I haven't tested that configuration.
Just a quick summary..
providers:
ETH11 1
Tom Eastep wrote:
> Jerry Vonau wrote:
>
>>
>> Ok, is been more that a couple of days. ;-) With 4.2, is the reason
>> behind the shorewall test layout, using main 999, is for backwards
>> compatibility?
>
> Yes.
>
>>
>> Getting the "squid in loc" to work with "loose" took a bit of effort
>> b
Tom Eastep wrote:
> On Sun, 2008-07-13 at 17:05 -0500, Jerry Vonau wrote:
>
>> Guess it's a bug... off to file it.. fyi:
>> libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.i386
>> iptables-1.4.1.1-1.fc9.i386
>> 2.6.25.9-76.fc9.i686
>
> I can confirm the bug in Fedora 9:
>
> [EMAIL PROTECTED] ~]# i
On Sun, 2008-07-13 at 17:05 -0500, Jerry Vonau wrote:
> Guess it's a bug... off to file it.. fyi:
> libnetfilter_conntrack-0.0.89-0.1.svn7356.fc9.i386
> iptables-1.4.1.1-1.fc9.i386
> 2.6.25.9-76.fc9.i686
I can confirm the bug in Fedora 9:
[EMAIL PROTECTED] ~]# iptables -t nat -N foo
[EMAIL PROTE
Tom Eastep wrote:
> Jerry Vonau wrote:
>
...
>>
>> Getting the "squid in loc" to work with "loose" took a bit of effort
>> but that works now. Give me a bit, I'll have some config info that
>> worked for me if you want.
>
> Please -- I haven't tested that configuration.
>
I'll paste together
Tom Eastep wrote:
Jerry Vonau wrote:
One a side note:
Running /sbin/iptables-restore...
iptables-restore v1.4.1.1: host/network `!' not found
Error occurred at line: 134
Try `iptables-restore -h' or 'iptables-restore --help' for more
information.
ERROR: iptables-restore Failed. Input is in
Jerry Vonau wrote:
Ok, is been more that a couple of days. ;-) With 4.2, is the reason
behind the shorewall test layout, using main 999, is for backwards
compatibility?
Yes.
Getting the "squid in loc" to work with "loose" took a bit of effort but
that works now. Give me a bit, I'll hav
Tom Eastep wrote:
> Jerry Vonau wrote:
>
>>
>> OK, for those of us that are playing along at home ;-), to condense the
>> thought, what we(?) would be looking at is a single "bal" table that has
>> the default routes. The routing rules needed would point to the "main"
>> routing table for the rout
Jerry Vonau wrote:
The routing rules are in the same order, just with different values, I'm
wondering if the "from lookup " rules are even need/wanted.
When a connection is from the fw to a host that is on the same lan as a
gateway, I not sure with out testing, if that would mess up the the ip
On Tue, 2008-07-01 at 11:17 -0700, Tom Eastep wrote:
> Jerry Vonau wrote:
>
> >
> > OK, for those of us that are playing along at home ;-), to condense the
> > thought, what we(?) would be looking at is a single "bal" table that has
> > the default routes. The routing rules needed would point to
Jerry Vonau wrote:
On Sat, 2008-07-05 at 08:46 -0700, Tom Eastep wrote:
I decided to call the option ROUTE_BALANCE although I can still be
talked into another name.
How about "USE_DEFAULT_TABLE", or maybe "GW_IN_DEFAULT_TABLE"?
USE_DEFAULT_TABLE would work.
Thanks,
-Tom
--
Tom Eastep
On Sat, 2008-07-05 at 08:46 -0700, Tom Eastep wrote:
> Brian J. Murrell wrote:
> > On Wed, 2008-07-02 at 07:05 -0700, Tom Eastep wrote:
>
> >
> >> I'm not sure that I want to give users that much rope to hang
> >> themselves.
>
> For those who are brave, there is a preview of Beta3 available at
Brian J. Murrell wrote:
On Wed, 2008-07-02 at 07:05 -0700, Tom Eastep wrote:
I'm not sure that I want to give users that much rope to hang
themselves.
For those who are brave, there is a preview of Beta3 available at
http://www.shorewall.net/pub/shorewall/development/staging/4.2/shorewall
On Wed, 2008-07-02 at 07:05 -0700, Tom Eastep wrote:
>
> The issue is not trying to figure out what the user wants but rather
> what should happen. We can't leave the user's default route(s) in the
> main table; about all we can do is to try to move it (them) to the
> default table, I guess.
I
Brian J. Murrell wrote:
I've thought of that approach (adding a provider option)
You mean a new field/option to the provider table, yes?
Yes -- a new option.
but what happens if
part of the entries have the new option and part don't?
s/part/some/
i.e. so some providers entries have
On Tue, 2008-07-01 at 18:57 -0700, Tom Eastep wrote:
>
> No, we aren't -- we are proposing to require that two fields (DUPLICATE and
> COPY) be empty when the new behavior applies.
Ahhh. OK. I see.
> Brian, we can't just remove
> columns from configuration files between releases. Users often
Brian J. Murrell wrote:
So the new behavior is definitely different and incompatible with the old
behavior.
I wonder if a new field (yeah, not terribly desirable, but we are
proposing removing a field at the same time)
No, we aren't -- we are proposing to require that two fields (DUPLICATE
On Tue, 2008-07-01 at 11:59 -0700, Tom Eastep wrote:
>
> Consider the case of a transparent Squid proxy in the local net.
Indeed. This is one use-case I've never played with. I'm surprised to
discover that it's achieved using a "provider", but can see how/why.
> The
> recommended rule there i
Brian J. Murrell wrote:
Is it "two models" or just a re-implementation of the existing model?
What if the only change was to do the route rules re-ordering so that
applications populating the main table would get what they want? Does
anything "user visible" (i.e. anything in /etc/shorewall/) r
Jerry Vonau wrote:
OK, for those of us that are playing along at home ;-), to condense the
thought, what we(?) would be looking at is a single "bal" table that has
the default routes. The routing rules needed would point to the "main"
routing table for the routes that would be "local" to the bo
On Tue, 2008-07-01 at 07:12 -0700, Tom Eastep wrote:
> Brian J. Murrell wrote:
> > On Mon, 2008-06-30 at 20:45 -0700, Tom Eastep wrote:
> >> I'm still willing to be convinced; but the 'provider tables contain
> >> only default routes' approach is a dead end as far as I'm able to see.
> >
> > Yeah
On Tue, 2008-07-01 at 07:12 -0700, Tom Eastep wrote:
>
> Brian,
>
> I owe you an apology.
No worries. I was not totally convinced myself that it would work (or I
would have been more persistent, but to have been more that it would
work I would have had to find the time to do an implemenation) a
Brian J. Murrell wrote:
On Mon, 2008-06-30 at 20:45 -0700, Tom Eastep wrote:
I'm still willing to be convinced; but the 'provider tables contain
only default routes' approach is a dead end as far as I'm able to see.
Yeah, it very well could be. I do recognize you are the word of
experience he
On Mon, 2008-06-30 at 20:45 -0700, Tom Eastep wrote:
> Brian J. Murrell wrote:
> > On Mon, 2008-06-30 at 16:45 -0700, Tom Eastep wrote:
> >> I think that adding routing rules for things that need to use the main
> >> table
> >> is more straightforward.
> >
> > Indeed, if you know ahead of time a
Brian J. Murrell wrote:
On Mon, 2008-06-30 at 16:45 -0700, Tom Eastep wrote:
I think that adding routing rules for things that need to use the main table
is more straightforward.
Indeed, if you know ahead of time and are able/willing to reload your
firewall to deal with changes.
Brian,
You'
On Mon, 2008-06-30 at 16:45 -0700, Tom Eastep wrote:
>
> I think that adding routing rules for things that need to use the main table
> is more straightforward.
Indeed, if you know ahead of time and are able/willing to reload your
firewall to deal with changes.
> Plus your scheme would be incom
Brian J. Murrell wrote:
On Sun, 2008-06-29 at 14:06 -0700, Tom Eastep wrote:
I believe that it doesn't work at all. You have to know where a packet is
going before you mark it.
Does changing up the order of the routing table traversal change that?
Actual marking is done in the mangle table rig
On Sun, 2008-06-29 at 14:06 -0700, Tom Eastep wrote:
>
> I believe that it doesn't work at all. You have to know where a packet is
> going before you mark it.
Does changing up the order of the routing table traversal change that?
Actual marking is done in the mangle table right? In my case for
Brian J. Murrell wrote:
Do you think my proposed routing rules/tables reorganization would not
achieve that, or not work at all?
I believe that it doesn't work at all. You have to know where a packet is
going before you mark it. Try creating marking rules that work in your
scheme where the f
On Sun, 2008-06-29 at 10:47 -0700, Tom Eastep wrote:
>
> If your OpenVPN server is going to add routes to hosts in the 192.168.2.0/24
> network then simply add this line to your route_rules file:
>
> -192.168.2.0/242541001
>
> Solving the OpenVPN routing problem was one of the main
Brian J. Murrell wrote:
To provide a real-world use case, imagine a MultiISP shorewall and
openvpn configuration where the multiple ISP links are tracked and
balanced. This all works fine as long as nothing comes along and adds
routes to the "main" routing table after shorewall has made it's
pe
31 matches
Mail list logo
