I tried that before I dropped a message.
I just went back to 3.2.6 and things started to work again like magic,
again with no
changes to any config files.
There must be a difference but I am happy that it at least works this much.
Let's pick this one up after the holidays.. it will be there... :)
I am with you there.
I don't want to stay here either :)
Shorewall Guy wrote:
> Mark Rutherford wrote:
>
>> Well, I did the upgrade and now I have had a total failure.
>> None of the port forwarding is working, and trying to browse to any
>> website times out (squid runs on the firewall)
>> I
Mark Rutherford wrote:
> Well, I did the upgrade and now I have had a total failure.
> None of the port forwarding is working, and trying to browse to any
> website times out (squid runs on the firewall)
> I can traceroute out, RPD out, etc
> I ended up with version 4.0.15
> Should I try to re
Mark Rutherford wrote:
> Well, I did the upgrade and now I have had a total failure.
> None of the port forwarding is working, and trying to browse to any
> website times out (squid runs on the firewall)
> I can traceroute out, RPD out, etc
> I ended up with version 4.0.15
> Should I try to re
Well, I did the upgrade and now I have had a total failure.
None of the port forwarding is working, and trying to browse to any
website times out (squid runs on the firewall)
I can traceroute out, RPD out, etc
I ended up with version 4.0.15
Should I try to remove it and go back to 3.3 or try t
Time to upgrade... I will do that.
I will have to see about getting newer packages (this is a Debian)
I guess I was bitten by a few bugs.
I really appreciate the help guys.
Shorewall Guy wrote:
> Mark Rutherford wrote:
>
>> I am seeing something here that may explain my troubles.
>> When you
Jerry Vonau wrote:
>
> This looks funny
>
> Routing Rules
>
> 0:from all lookup 255
> 1000: from all iif eth2 lookup Twc <
> 1000: from all iif lo lookup Nuvox
> 10001:from all fwmark 0x1 lookup Nuvox
> 10002:from all fwmark 0x2 lookup Twc
> 11000:fr
Mark Rutherford wrote:
> I am seeing something here that may explain my troubles.
> When you said that it was duplicated and I saw that it was in the
> dump... it was not in the file.
> I was changing it from one to the other but the entries in the file were
> never there at the same time with th
Shorewall Guy wrote:
> Mark Rutherford wrote:
>> Thanks for taking a crack at it.
>> Here is the updated dump.
>> I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy.
>
> Sigh -- I wanted you to CHANGE THE PRIORITY to 11000, not duplicate the
> rule. *It never makes any sense t
I am seeing something here that may explain my troubles.
When you said that it was duplicated and I saw that it was in the
dump... it was not in the file.
I was changing it from one to the other but the entries in the file were
never there at the same time with the same priority.
I don't know if
On Wed, 2008-12-31 at 15:58 -0500, Mark Rutherford wrote:
> Thanks for taking a crack at it.
> Here is the updated dump.
> I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy.
>
>
> Shorewall Guy wrote:
> > Shorewall Guy wrote:
> >
> >> Mark Rutherford wrote:
> >>
> >>
Mark Rutherford wrote:
> Thanks for taking a crack at it.
> Here is the updated dump.
> I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy.
Sigh -- I wanted you to CHANGE THE PRIORITY to 11000, not duplicate the
rule. *It never makes any sense to have exactly the same rule wit
Thanks for taking a crack at it.
Here is the updated dump.
I tried port 80 and 21 from 70.60.208.84 to 216.176.235.187 with no joy.
Shorewall Guy wrote:
Shorewall Guy wrote:
Mark Rutherford wrote:
No change.
Should I send another dump?
What you have now should be correct. I pe
Shorewall Guy wrote:
> Mark Rutherford wrote:
>> No change.
>> Should I send another dump?
>
> What you have now should be correct. I personally have no more ideas.
>
But if you send another one, maybe someone else will see something...
--
Mark Rutherford wrote:
> No change.
> Should I send another dump?
What you have now should be correct. I personally have no more ideas.
--
___
Shorewall-users mailing list
S
No change.
Should I send another dump?
Shorewall Guy wrote:
> Mark Rutherford wrote:
>
>> Ouch! Ok, I got it now... that took too long to register.
>> Problem now is that the port forwarding traffic is not working.
>> I am trying to connect to port 21 on 216.176.235.187 from (oustside)
>> 70.6
Mark Rutherford wrote:
> Ouch! Ok, I got it now... that took too long to register.
> Problem now is that the port forwarding traffic is not working.
> I am trying to connect to port 21 on 216.176.235.187 from (oustside)
> 70.60.208.84
> It never connects and simply times out.
> If I force the traff
Ouch! Ok, I got it now... that took too long to register.
Problem now is that the port forwarding traffic is not working.
I am trying to connect to port 21 on 216.176.235.187 from (oustside)
70.60.208.84
It never connects and simply times out.
If I force the traffic back thru that network it wor
Mark Rutherford wrote:
> I am at a loss as to what I need to change.
> I tried inverting the priority numbers in route_rules and changing the
> order of the entries in the file and
> it seems to have no effect.
Your rule for eth1 at pri 1000 is nonsense.
Your rule for eth2 at pri 1000 should spec
I am at a loss as to what I need to change.
I tried inverting the priority numbers in route_rules and changing the
order of the entries in the file and
it seems to have no effect.
Shorewall Guy wrote:
> Mark Rutherford wrote:
>
>> Ok, I hope this is it...
>> I did the reset as requested and w
Mark Rutherford wrote:
> Ok, I hope this is it...
> I did the reset as requested and we tried the connection.
> A machine on the local network is trying to connect to 208.60.147.148
> from 10.1.1.67 on port 22 (tcp)
> The machine on the other end is expecting us to connect from 70.61.215.98
> Basic
Ok, I hope this is it...
I did the reset as requested and we tried the connection.
A machine on the local network is trying to connect to 208.60.147.148
from 10.1.1.67 on port 22 (tcp)
The machine on the other end is expecting us to connect from 70.61.215.98
Basically, I think the remote system
Mark Rutherford wrote:
> I sent along with my first message the output of shorewall dump
> The issue is that we have to transmit files via SFTP and it has to
> originate from a certain address.
> Otherwise, everything works as intended.
> People can browse the internet, port forwarding works, etc
I sent along with my first message the output of shorewall dump
The issue is that we have to transmit files via SFTP and it has to
originate from a certain address.
Otherwise, everything works as intended.
People can browse the internet, port forwarding works, etc etc.
If that dump is no good I c
Mark Rutherford wrote:
> Ok, well the thing about the top 2 lines was inaccurate.
> It does work regardless of those.
>
> However, it still matters not what I put in there.
> If I take those out and leave
>
> 1:P 0.0.0.0/0
> 1 $FW
>
> In tcrules it changes nothing, brea
Ok, well the thing about the top 2 lines was inaccurate.
It does work regardless of those.
However, it still matters not what I put in there.
If I take those out and leave
1:P 0.0.0.0/0
1 $FW
In tcrules it changes nothing, breaks nothing.
still routes everything over is
Mark Rutherford wrote:
> I am trying to force (all) traffic over one isp.
> I have the following in tcrules:
>
> 1 eth070.61.215.87/29
> 2 eth1216.176.235.184/29
> 1:P 0.0.0.0/0
> 1 $FW
>
> I want everything unless otherwise directed f
27 matches
Mail list logo
