Hi Tom,
thank you for your reply. sorry for the text wrapping as I'm using web mail.
I have attached the gz format of shorewall dump.
To clarify the objective:
I want to redirect traffic from dmz (eth2) to use AC3 (eth1) link and
redirect traffic from loc (eth3) to use I2N (eth0) link.
I've cha
On 9/15/10 5:47 PM, Lito Kusnadi wrote:
> I have been using shorewall for a number of years, but I haven't
> really tried to use packet marking or multiple isp before.
>
> I have a project to build firewall system with 2 isp links. The
> target is to set shorewall with 2 isp link, with vrrp for
I have been using shorewall for a number of years, but I haven't really tried
to use packet marking or multiple isp before.
I have a project to build firewall system with 2 isp links. The target is to
set shorewall with 2 isp link, with vrrp for failover to another shorewall box.
However, I wan
> I think you can probably tell what's been driving me nuts for the
> last few years ! When I started 5 years ago, they were just
> experimenting with VOIP at work - and all the phones were on public
> IPs outside the firewall because they hadn't (at the time) figured
> out how to make them wo
On 9/14/10 7:33 AM, Tom Eastep wrote:
>
> 3) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
> /etc/shorewall/tcinterfaces now accepts an optional burst parameter.
>
> [:]
>
> The default burst is 10kb. A larger burst can help make the
> more accurate; often f
On 9/15/10 4:25 AM, Brian J. Murrell wrote:
> On Mon, 2010-09-13 at 07:53 -0700, Tom Eastep wrote:
>>
>> I resurrected some old code that I had implemented earlier and performed
>> some more testing. Attached is a patch against
>> /usr/share/shorewall/Shorewall/Tc.pm. It applies (with offsets) to
On Mon, 2010-09-13 at 07:53 -0700, Tom Eastep wrote:
>
> I resurrected some old code that I had implemented earlier and performed
> some more testing. Attached is a patch against
> /usr/share/shorewall/Shorewall/Tc.pm. It applies (with offsets) to
> 4.4.11 and later versions.
>
> It adds an OUT-
On Mon, 2010-09-13 at 08:58 -0700, Tom Eastep wrote:
>
> I've found the same gross inaccuracy with the IN-BANDWIDTH as Brian did.
I wonder how widespread (as in across kernel versions) and well-known
this issue is. I've had it in the back of mind to go rattle the cage of
the TC folks to get an
Mr Dash Four wrote:
> > Alternatively, it's more admin but also more reliable to statically
>> configure everything. Manually configure each SIP device to use a
>> different port for it's SIP traffic, and a different port range for
>> it's RTP traffic. Configure them with knowledge of their pub
