trying to get restore'able iptables output

[Florian Heigl]

Hi again, today I am back to capirca.

In the wiki I read that the speedway output is now supposed to be
iptables-restore friendly.

So far i'm not getting it to load a very basic policy.

root@xen04:/opt/wfmanage/software/capirca# ./aclgen.py
writing ./filters/local-ssh
writing ./filters/local-ssh.ipt
2 filters rendered
root@xen04:/opt/wfmanage/software/capirca# iptables-restore < filters/
local-ssh
iptables-restore: line 7 failed
root@xen04:/opt/wfmanage/software/capirca#

[Florian Heigl]

We still practice the clicking part.
Here is the more useful information:

Generated filter:
root@xen04:/opt/wfmanage/software/capirca# cat filters/local-ssh
# Iptables INPUT Policy
# Input filter
#
# $Id:$
# $Date:$
# inet
-N I_permit-ssh-services
-A INPUT -j I_permit-ssh-services
-A I_permit-ssh-services -p tcp --dport 22 -d abcdef/32 -m state --
state NEW,ESTABLISHED,RELATED -j ACCEPT
-N I_default-deny
-A INPUT -j I_default-deny
-A I_default-deny -p all -j DROP


Policy:
root@xen04:/opt/wfmanage/software/capirca# cat policies/local-ssh.pol
# Test / First definition
header {
comment:: "Input filter"
target:: speedway INPUT
target:: iptables INPUT
}

# removed for now
#### include 'policies/includes/untrusted-networks-blocking.inc'

term permit-ssh-services {
destination-address:: SSH_SERVERS
protocol:: tcp
destination-port:: SSH
action:: accept
}

term default-deny {
action:: deny
}


Version is the r150 from downloads section.


Feeding the lines into single iptables commands of course worked :)

Greetings and thanks for all the updates,
Florian

[watson]

Try running iptables-restore on the local-ssh.ipt file.

Iptables has two forms of output.  The first is generated with a 'target:: speedway', the second with a 'target:: iptables'.  Only the output file with the .ipt extension is usable by iptables-restore command, the other file is only suitable for passing each line manually to /sbin/iptables commandline.

[Florian Heigl]

Hi,

2011/11/14 watson <wat...@gmail.com>:

> Try running iptables-restore on the local-ssh.ipt file.
> Iptables has two forms of output.  The first is generated with a 'target::
> speedway', the second with a 'target:: iptables'.  Only the output file with
> the .ipt extension is usable by iptables-restore command, the other file is
> only suitable for passing each line manually to /sbin/iptables commandline.

Ah, so I mixed up which one to use. Ok, got that.
I missed to say that the .ipt file also errors :)
This gives the following error:

root@xen04:/opt/wfmanage/software/capirca# iptables-restore <
filters/local-ssh.ipt
iptables-restore v1.4.10: no command specified
Error occurred at line: 16
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

root@xen04:/opt/wfmanage/software/capirca# cat filters/local-ssh.ipt
*filter
# Speedway INPUT Policy

# Input filter
#
# $Id:$
# $Date:$
# inet
-N I_permit-ssh-services

-A I_permit-ssh-services -p tcp --dport 22 -d 188.40.175.3/32 -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j I_permit-ssh-services
-N I_default-deny

-A I_default-deny -p all -j DROP

-A INPUT -j I_default-deny

Ah. And looking at the header I have an error in the target part of
the policy file, right?

# Test / First definition
header {
comment:: "Input filter"
target:: speedway INPUT

target:: iptables INPUT <- must be wrong since both generated files
are saying speedway.
}

I'll be back at this tonight - thank you so much for the reply!
Florian

[Florian Heigl]

Small followup:

On Nov 14, 8:41 am, Florian Heigl <florian.he...@gmail.com> wrote:
> Hi,
>
> 2011/11/14 watson <wat...@gmail.com>:
>
> > Try running iptables-restore on the local-ssh.ipt file.
> > Iptables has two forms of output.  The first is generated with a 'target::
> > speedway', the second with a 'target:: iptables'.  Only the output file with
> > the .ipt extension is usable by iptables-restore command, the other file is
> > only suitable for passing each line manually to /sbin/iptables commandline.

Ok.

Lessons learned:
1. The speedway file writes the file named .ipt and the iptables
module writes the one not called .ipt. Errr. Not obvious ;p
2. The .ipt file will not load.
3. If I remove the second line here, it will load:
*filter
# Speedway INPUT Policy <----- iptables restore dies when it reads
this commented line

# Input filter
#
# $Id:$
# $Date:$
# inet
-N I_permit-ssh-services

[snip]


root@xen04:/opt/wfmanage/software/capirca# cat policies/local-ssh.pol

# Test / First definition
header {
comment:: "Input filter"
target:: speedway INPUT
}

[snip]

Now one more idiotic question... :>
Don't I *have* to write it like this?
target:: speedway INPUT


Greetings,
Florian



p.s.:
-----
I'm sorry that I have to bother you (as the devs) with my startup
issues.
I simply *do not* understand why Capirca is not being used by dozens
of ISPs and other organizations and this group full of them :)

[Tony Watson]

On Mon, Nov 14, 2011 at 3:40 PM, Florian Heigl <floria...@gmail.com> wrote:

Small followup:


On Nov 14, 8:41 am, Florian Heigl <florian.he...@gmail.com> wrote:
> Hi,
>
> 2011/11/14 watson <wat...@gmail.com>:

>
> > Try running iptables-restore on the local-ssh.ipt file.
> > Iptables has two forms of output.  The first is generated with a 'target::
> > speedway', the second with a 'target:: iptables'.  Only the output file with
> > the .ipt extension is usable by iptables-restore command, the other file is
> > only suitable for passing each line manually to /sbin/iptables commandline.

Ok.

Lessons learned:
 1. The speedway file writes the file named .ipt and the iptables
module writes the one not called .ipt. Errr. Not obvious ;p

Agreed.  Eventually the plan is to eliminate the different iptables/speedway output formats and simplify to a single format that is usable by iptables-restore.

 

 2. The .ipt file will not load.

I found a bug that was likely causing this.  A quick fix is to specify a default action on the target line, such as:

target:: speedway INPUT DROP

The DROP argument says to modify the INPUT filter to have a default policy of DROP unless a rule explicitly allows the traffic.  ACCEPT is also a valid default policy.

This will ensure the output includes a line like:  

:INPUT DROP

and then the resulting .ipt file should load correctly.

I've submitted a fix for the lib/iptables.py library that will ensure a default policy is always applied for defined filters when generating .ipt files.  I'll get a new tar.gz file up soon on the downloads page - in the meantime, just include the default action in the target:: definition as mentioned above.

Thanks for catching this issue and reporting it.