If these are the only chains that are impacted by this problem then it
sounds good. Will give us the flexibility we need.
Thanks
David
On Mon, Jul 16, 2012 at 6:30 PM, Lonnie Abelbeck
wrote:
> Hi David,
>
> Well, I wouldn't necessarily call it a "dumb idea" :-) and I explained
> Arno's reasoni
Hi David,
Well, I wouldn't necessarily call it a "dumb idea" :-) and I explained Arno's
reasoning years ago.
I have commit privileges to the AIF SVN, so with Arno's approval we and
implement any great idea we can come up with.
One idea Arno and I had was to add 3 new variables to AIF:
--
# (1
Oh dear, I opened a can of worms. I have to say that changing default
behavior as a side effect of adding an allow rule feels like a dumb idea.
How hard would it be for iptables to be modified such that a final default
chain rule can be specified -- which could override a hard coded default
rule f
Sigh, now I remember why we didn't previously support "Pass LAN->EXT" and "Pass
DMZ->EXT" in the Firewall tab...
First, my suggestion to David in this thread for using LAN_INET_HOST_OPEN_UDP
does what you expect *but* has the side effect of changing the LAN->EXT default
policy from ALLOW to DRO
David,
Arno's Firewall (AIF) automatically places the "Pass LAN->EXT" rules (if any)
before the "Deny LAN->EXT" rules.
So, no ordering by the user is required.
Lonnie
On Jul 16, 2012, at 9:16 AM, David Kerr wrote:
> When this is all implemented does it matter in what order the rules are
> e
When this is all implemented does it matter in what order the rules are
entered? For example if iptables comes across a deny that matches the
request does it keep on going through the table looking for a rule that
might never-the-less permit the request or does it stop -- in which case
the rule pe
On Jul 16, 2012, at 2:53 AM, Michael Keuter wrote:
>
> Am 16.07.2012 um 01:39 schrieb Lonnie Abelbeck:
>
>> David,
>>
>> With the general DNS block in place...
>>
>> LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
>>
>> will allow the internal 192.168.1.99 device to access any external DNS
>>
Am 16.07.2012 um 01:39 schrieb Lonnie Abelbeck:
> David,
>
> With the general DNS block in place...
>
> LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
>
> will allow the internal 192.168.1.99 device to access any external DNS server.
>
> Lonnie
>
> PS: In the web interface we don't support "Pa
Thanks. Just what I needed.
On Sun, Jul 15, 2012 at 7:39 PM, Lonnie Abelbeck
wrote:
> David,
>
> With the general DNS block in place...
>
> LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
>
> will allow the internal 192.168.1.99 device to access any external DNS
> server.
>
> Lonnie
>
> PS: In the
David,
With the general DNS block in place...
LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
will allow the internal 192.168.1.99 device to access any external DNS server.
Lonnie
PS: In the web interface we don't support "Pass LAN->EXT" rules, since that is
the default policy and would seem con
Yes I agree. Of course since turning on blocking I find that I have a VoIP
adapter that is remotely administered by "someone else" and it is pointing
to a external DNS server. Fortunately the logs identified this. So I need
to explicitly allow one internal IP to access an external DNS.
David
O
David,
Yes, blocking is best, the "iptables -t nat -A PREROUTING" technique described
only works with IPv4, plus those rules would get a *lot* of matches.
Lonnie
On Jul 15, 2012, at 5:11 PM, David Kerr wrote:
> Thanks lonnie. Blocking port 53 is the simplest way to go I think. Googling
> a
Thanks lonnie. Blocking port 53 is the simplest way to go I think.
Googling also turns up...
http://www.dd-wrt.com/wiki/index.php/OpenDNS
Scroll down that page and you find a way to intercept all port 53 requests
and send them somewhere else silently... so DNS requests satisfied, just
not by th
Off the top of my head you'd need a custom rule along the lines of:
iptables -A FORWARD -i $INTIF -m udp -p udp --dport 53 -d
208.67.222.222 -j ACCEPT
iptables -A FORWARD -i $INTIF -m udp -p udp --dport 53 -d
208.67.220.220 -j ACCEPT
iptables -A FORWARD -i $INTIF -m udp -p udp --dport 53 -j REJECT
Hi David,
From the Network -> Firewall tab
Deny LAN->EXT TCP/UDP 0/0 0/0 53
<>
This applies for both IPv4 and IPv6 if enabled. TCP is seldom used, but best
to also block it.
Now for the extra credit, :-), this can't be done via the Firewall tab, but if
you also add the AIF variable to your
So, the OpenDNS was mentioned on this list a few days ago. I use this
service and the mention on this list prompted me to check my settings to
make sure that I was still appropriately blocking access to web site
categories. And it started me thinking... it would be easy for
a savvy user to reconf
16 matches
Mail list logo
