ipcop-devel Mailing List for IPCop Firewall

On 2011-11-28 21:04, Michael G Beirne wrote:

> When I put "%defaultroute" into the IPSec "Public IP or FQDN for the RED
> interface or %defaultroute" and then add a connection using a PSK, when
> the connection is saved, it puts "%defaultroute" into the ipsec.secrets
> file instead of converting this to "%any" as it should.

I don't follow.
When the IPsec host IP is set to %defaultroute, PSK is disabled and the 
PSK field shows "hostname=%defaultroute not allowed".


Olaf

Hello,

When I put "%defaultroute" into the IPSec "Public IP or FQDN for the RED
interface or %defaultroute" and then add a connection using a PSK, when
the connection is saved, it puts "%defaultroute" into the ipsec.secrets
file instead of converting this to "%any" as it should.

I've hacked up (and attached) a quick patch which adds support for
updating the IPv4 endpoint for Hurricane Electric IPv6 tunnels.
See: http://www.tunnelbroker.net/

Problem:
The IPv6 tunnel broker needs to know your current IPv4 address in
order to send you 6in4 packets.
Many people have dynamic IP addresses.

Solution:
I've added a Dynamic DNS rule for he.net which behaves like any other
DDNS target, and keeps your current IPv4 address updated.

Thanks!

PS.
Also useful to add to /etc/rc.d/rc.firewall.local under start section:

HE_TUNNELBROKER_IP=209.51.181.2
iptables -A CUSTOMFORWARD -i eth2 -p 41 -s HE_TUNNELBROKER_IP -j ACCEPT
iptables -t nat -A CUSTOMPREROUTING -i eth2 -s $HE_TUNNELBROKER_IP -p
41 -j DNAT --to 192.168.100.15

Raqcop 2.0.2 Update and install images available. If you are already 
running 2.0.1 simply refresh the updates, download and apply. You can 
also do it the old fashioned way and download the update from 
http://downloads.raqcop.com/cobalt_ipcop and then upload to your machine 
ala IPCop 1.4 even though there are few reasons to need to do the 
latter. Since 2.0.2 has a kernel change you need to reboot.

As of yet, only the iso image used by a VM to install directly to your 
disk(s) and both raid and single 20GB dynamic images to be installed via 
WinImage are uploaded. Flash images will follow.

-- 
Dave Studeman
http://www.raqcop.com

Dave Studeman wrote (from an unsubscribed address)

Update and install images available. If you are already 
running 2.0.1 simply refresh the updates, download and apply. You can 
also do it the old fashioned way and download the update from 
http://downloads.raqcop.com/cobalt_ipcop and then upload to your machine 
ala IPCop 1.4 even though there are few reasons to need to do the 
latter. Since 2.0.2 has a kernel change you need to reboot.

As of yet, only the iso image used by a VM to install directly to your 
disk(s) and both raid and single 20GB dynamic images to be installed via 
WinImage are uploaded. Flash images will follow.

-- 
Dave Studeman
http://www.raqcop.com

PS. Please use your subscribed address when posting to the devel list. 
G.

On 2011-11-18 19:40, Gilles Espinasse wrote:
> I fixed capi4k-utils to compile on my tree (not yet commited).
> But looking at the rootfiles, it look we only use the pppd plugins.
>
> Is there a reason why we should still compile capiinit, avmcapictrl and
> capi20 lib and not only the plugins?

I am not sure, what is still needed and what can be removed.
I have yet to find time to try ISDN.


Olaf

I fixed capi4k-utils to compile on my tree (not yet commited).
But looking at the rootfiles, it look we only use the pppd plugins.

Is there a reason why we should still compile capiinit, avmcapictrl and
capi20 lib and not only the plugins?

Gilles

IPCop 2.0.2 is released

v2.0.2 can be installed using the installation images or as an update 
from version 2.0.1.
You need to reboot to use the new kernel after upgrading to 2.0.2.

In addition to a few updates to software used in IPCop,
v2.0.2 fixes creating CA certificate which did not correctly work in 2.0.1.


Online English installation manual: 
http://www.ipcop.org/2.0.0/en/install/html
Online German installation manual: 
http://www.ipcop.org/2.0.0/de/install/html
The installation manuals are 'work in progress' and not yet complete.

Online English admin manual: http://www.ipcop.org/2.0.0/en/admin/html
Online German admin manual: http://www.ipcop.org/2.0.0/de/admin/html


Noteworthy:
- the GUI uses 8443 instead of 445.
- SSH uses 8022 instead of 222.
- access to IPCop and to the internet from internal networks (aka
Green, Blue, Orange) is very much different. Spend some time with the
various options you will find under "Firewall Settings" and the online
admin manual.
- Several translations are complete, other languages are work in progress.
- backups from 1.4-series can not be used.
- addons made for the 1.4-series will not work.


Updates
a67ee1732ef83e47c280171135272973  ipcop-2.0.2-update.i486.tgz.gpg

Installation
7c745ce011c8ce991197a0161b85e652  ipcop-2.0.2-install-cd.i486.iso
110768eae38b6525eec4a7eef4c510a0  ipcop-2.0.2-install-netboot.i486.tgz
f95d2fbbdc61739fc4e4edf9f1241571  ipcop-2.0.2-install-usb-fdd.i486.img.gz
c7d3a244707b2e5f7e5694c507eb1257  ipcop-2.0.2-install-usb-hdd.i486.img.gz
cb483b897d5b85fd4456ba09ea5d3b3f  ipcop-2.0.2-install-usb-zip.i486.img.gz
4da8540656f7239a8e4799b5f69750fe  ipcop-2.0.2-install-avmdrv.i486.tgz

----- Original Message ----- 
From: "Mester" <me...@fr...>
To: <ipc...@li...>
Sent: Wednesday, November 16, 2011 5:51 PM
Subject: [IPCop-devel] no sudo in version 2.0?


> Hi,
>
> I wrote about it on ipcop-users list but someone said that I should post
> it to this list.
> In IPCop 1.x I used a standard user for login to my IPCop box and used
> sudo or su for root access. But unfortunatelly I can not find sudo or su
> in version 2.0.
> Is there a way to fix it somehow?
>
>
> Attila Mesterhazy
>
A standard IPCop 1.x only allow to log in as root at the shell level.
IPCop 2.x behave the same.

sudo never was in official tree.

To have su installed on V2.x, you would need to add some instructions in
lfs/coreutils to install su (it is already compiled)

Gilles

Hi,

I wrote about it on ipcop-users list but someone said that I should post 
it to this list.
In IPCop 1.x I used a standard user for login to my IPCop box and used 
sudo or su for root access. But unfortunatelly I can not find sudo or su 
in version 2.0.
Is there a way to fix it somehow?


Attila Mesterhazy

Feature Requests item #3438765, was opened at 2011-11-16 05:17
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3438765&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next release
Status: Open
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: TCAR request

Initial Comment:
Every install of the old IPCop I did, I used TCAR (Traffic Control and Reporting). Will this be a built in feature at some point? Its one of the most useful add-ons I've seen for IPCop.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3438765&group_id=40604

On 2011-11-14 11:28, g....@fr... wrote:

> When working adding test suite on all perl packages, I understood we include twice sqlite code, once as sqlite package, once as DBD-SQLite as the second include his own version (3.7.8.6) of the code.
> With a sed 's/if ( 0 ) /if ( 1 ) /' Makefile.PL, GDB-SQLite compile against system sqlite lib (would need to install sqlite before GBD-SQLite). Compilation is ok but that time, the package test suite badly fail.
> Fedora and Debian compile against system lib and do nothing special to run the tests.
> I haven't find what is wrong in our case, if it is related to our way to compile perl or something else.
>
> Another point of view is that we could not include sqlite package, let GDB-SQLite include the code and wrap the command to create a database in a perl script.

OK, that would be a good simplification. IIRC there really is only 1 
place where we use sqlite directly.
Probably better to wait till next week though, after the 2.0.2 update.


> There is too a perl DBI-Shell package that give access to a shell using DBI=>DBD-SQLite stack.

Don't think we need to include that. Using DBD-SQLite should give us 
anything we need.


> I could upgrade iw to 3.2 (with or without upgrading too libnl to 3.2.2).
> libnl-3.2 add some configuration files and probably some overhead, compared to libnl-2.0

OK.


> Another place I am working is the graphic stack, that will probably wait after 2.0.2 to be ready.
> Reducing freetype size is not hard (commenting some modules we don't use).
>
> For libgd, I switched to debian 2.0.36 version that is used since lenny.
>
> Much harder is to understand what is exactly needed to be finally used on rrdtool. Actually rrdtool ask for pdf, svg support from cairo. That does not look very usefull for our use case.
> The last point is that I really want to have a better cairo test suite as this is the only remaining package with so much errors.

Yes, let's wait with those for next release (2.0.3 or 2.1.0).


Olaf

Bugs item #3437783, was opened at 2011-11-14 05:31
Message generated for change (Tracker Item Submitted) made by yguillot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3437783&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: 2.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: yoan guillot (yguillot)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port forwarding using port

Initial Comment:
Hello,
When i try to define a port and check the checkbox "used port" in source destination, the rule is created but it doesn't work.
Without this checkbox checked it work but i can't define mutiple ports (multi - pc) for a service like RDP(3389).

Exemple :

PC1 RDP TCP Any:3390 => 3389
PC2 RDP TCP Any:3389 => 3389

Only "PC1 RDP TCP Any => 3390" works...

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3437783&group_id=40604

----- Mail original -----
> De: "Olaf Westrik" <wei...@ip...>
> À: "Gilles Espinasse" <g....@fr...>
> Cc: "IPCop devel" <ipc...@li...>
> Envoyé: Lundi 14 Novembre 2011 09:10:54
> Objet: Re: [IPCop-devel] [2.0] Planning for 2.0.2 update
>
> On 2011-11-14 08:46, Gilles Espinasse wrote:
>
> > I have binutils-2.21.1a upgrade ready. This fix the download of
> > 2.21 no more
> > available on
> > http://ftp.gnu.org/gnu/binutils/
> > This is mostly transparent to check_files as the only changed files
> > from
> > binutils upgrade are in the new kernel already in update.
>
> OK.
>
>
> > There is still the issue for files loaded from kernel.org.
>
> They'll come back eventually. I am reluctant to put up a mirror on
> SF, as that is difficult to maintain.

I have the same mind.
Maybe simply just add an advice warning on ./make.sh prefetch that missing files could be found using google.

>
>
> I intend to release 2.0.2 this Friday (2011-11-18). I will implement
> the 'valid until' addition also for other generated certificates.
> It did not fix the problem, but it is a good addition anyway.
>
> Commits are OK until Thursday 08:00 UTC.
>
>
> Olaf
>
When working adding test suite on all perl packages, I understood we include twice sqlite code, once as sqlite package, once as DBD-SQLite as the second include his own version (3.7.8.6) of the code.
With a sed 's/if ( 0 ) /if ( 1 ) /' Makefile.PL, GDB-SQLite compile against system sqlite lib (would need to install sqlite before GBD-SQLite). Compilation is ok but that time, the package test suite badly fail.
Fedora and Debian compile against system lib and do nothing special to run the tests.
I haven't find what is wrong in our case, if it is related to our way to compile perl or something else.

Another point of view is that we could not include sqlite package, let GDB-SQLite include the code and wrap the command to create a database in a perl script. There is too a perl DBI-Shell package that give access to a shell using DBI=>DBD-SQLite stack.

I could upgrade iw to 3.2 (with or without upgrading too libnl to 3.2.2).
libnl-3.2 add some configuration files and probably some overhead, compared to libnl-2.0

Another place I am working is the graphic stack, that will probably wait after 2.0.2 to be ready.
Reducing freetype size is not hard (commenting some modules we don't use).

For libgd, I switched to debian 2.0.36 version that is used since lenny.

Much harder is to understand what is exactly needed to be finally used on rrdtool. Actually rrdtool ask for pdf, svg support from cairo. That does not look very usefull for our use case.
The last point is that I really want to have a better cairo test suite as this is the only remaining package with so much errors.


Gilles

On 2011-11-14 08:46, Gilles Espinasse wrote:

> I have binutils-2.21.1a upgrade ready. This fix the download of 2.21 no more
> available on
> http://ftp.gnu.org/gnu/binutils/
> This is mostly transparent to check_files as the only changed files from
> binutils upgrade are in the new kernel already in update.

OK.


> There is still the issue for files loaded from kernel.org.

They'll come back eventually. I am reluctant to put up a mirror on SF, 
as that is difficult to maintain.


I intend to release 2.0.2 this Friday (2011-11-18). I will implement the 
'valid until' addition also for other generated certificates.
It did not fix the problem, but it is a good addition anyway.

Commits are OK until Thursday 08:00 UTC.


Olaf

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
To: "Michael G Beirne" <bei...@sb...>; "IPCop devel"
<ipc...@li...>
Sent: Saturday, November 12, 2011 7:13 PM
Subject: Re: [IPCop-devel] [2.0] Planning for 2.0.2 update


> On 2011-11-12 17:29, Michael G Beirne wrote:
> > On 11/12/2011 5:17 AM, Olaf Westrik wrote:
> >>
> >>
> >>>> Could I update to 2.6.32.48 [3], that should still have a lot of good
fixes,
> >>>> that's 2.6.47 [4] + 3 revert?
> >>>
> >>> OK. I'll need some time to add fields for "valid until" in several
CGIs
> >>> anyway.
> >>
I have binutils-2.21.1a upgrade ready. This fix the download of 2.21 no more
available on
http://ftp.gnu.org/gnu/binutils/
This is mostly transparent to check_files as the only changed files from
binutils upgrade are in the new kernel already in update.

There is still the issue for files loaded from kernel.org.

Gilles

On 2011-11-12 17:29, Michael G Beirne wrote:
> On 11/12/2011 5:17 AM, Olaf Westrik wrote:
>>
>>
>>>> Could I update to 2.6.32.48 [3], that should still have a lot of good fixes,
>>>> that's 2.6.47 [4] + 3 revert?
>>>
>>> OK. I'll need some time to add fields for "valid until" in several CGIs
>>> anyway.
>>
>> Unfortunately 'fixing' the validity is not enough.
>> More thinking and experimenting is required to get openswan to accept
>> the host certificate.
>>
>
>
> I created a certificate after the 2.0.1 update and openswan did accept
> the certificate, although with an incorrect end date.

ipsec auto listall does not complain, ipsec showhostkey --left does:
ipsec showhostkey   error in PKCS#1 private key
ipsec showhostkey "/etc/ipsec.secrets" line 2: error loading RSA private 
key file
ipsec showhostkey: wrong kind of key PPK_XAUTH in show_confkey. Expected 
PPK_RSA.

The IPsec log shows (parsing PLUTO DEBUG enabled):

18:59:59 pluto[6795] loading secrets from "/etc/ipsec.secrets"
18:59:59 pluto[6795]   loaded private key file 
'/var/ipcop/certs/hostkey.pem' (916 bytes)
18:59:59 pluto[6795] |   file content is not binary ASN.1
18:59:59 pluto[6795] |   -----BEGIN PRIVATE KEY-----
18:59:59 pluto[6795] |   -----END PRIVATE KEY-----
18:59:59 pluto[6795] |   file coded in PEM format
18:59:59 pluto[6795] | L0 - RSAPrivateKey:
18:59:59 pluto[6795] | L1 - version:
18:59:59 pluto[6795] | L1 - modulus: ASN1 tag 0x02 expected, but is 0x30
18:59:59 pluto[6795] |   30 0d 06 09  2a 86 48 86  f7 0d 01 01  01 05 00
18:59:59 pluto[6795]   error in PKCS#1 private key
18:59:59 pluto[6795] "/etc/ipsec.secrets" line 2: error loading RSA 
private key file
18:59:59 ipsec__plutorun 003 "/etc/ipsec.secrets" line 2: error loading 
RSA private key file



Olaf

>> Could I update to 2.6.32.48 [3], that should still have a lot of good fixes,
>> that's 2.6.47 [4] + 3 revert?
>
> OK. I'll need some time to add fields for "valid until" in several CGIs
> anyway.

Unfortunately 'fixing' the validity is not enough.
More thinking and experimenting is required to get openswan to accept 
the host certificate.


Olaf

On 2011-11-12 09:19, Gilles Espinasse wrote:

> Could I update to 2.6.32.48 [3], that should still have a lot of good fixes,
> that's 2.6.47 [4] + 3 revert?

OK. I'll need some time to add fields for "valid until" in several CGIs 
anyway.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "IPCop devel" <ipc...@li...>
Sent: Friday, November 11, 2011 11:57 PM
Subject: [IPCop-devel] [2.0] Planning for 2.0.2 update


> Expect a 2.0.2 release tomorrow (2011-11-12), to fix a problem
> generating the CA certificates.
> Looks like ssl is now taking our 999999 days literally, creating a cert
> which openswan is not at all happy with.
>
> I'll either use 10 years, 15 years or a configurable length for the
> certificate(s).
>
>
> Everything committed so far will be included in the update package.
>
>
> Olaf
>
I don't think the uptime issue [1] that reboot the machine after 208 days is
yet fixed, even in latest linus tree as I don't see the fix there [2]

Could I update to 2.6.32.48 [3], that should still have a lot of good fixes,
that's 2.6.47 [4] + 3 revert?
[1] http://marc.info/?l=linux-kernel&m=131958272013717&w=2
[2]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob_plain;f=arch/x86/kernel/cpu/intel.c;hb=HEAD
[3] http://www.kernel.org/pub/linux/kernel/v2.6/longterm/
[4] http://marc.info/?l=linux-kernel&m=132070176418339&w=2

Gilles

On 2011-11-12 00:11, Michael Rasmussen wrote:

>> I'll either use 10 years, 15 years or a configurable length for the
>> certificate(s).
>>
> Could it be an idea to have some sort of certificates state displayed
> on one of the system status pages?

The (i) button already provides plenty of information.
All connections with certificates have "Valid until" displayed.
Connection states are displayed on IPsec and OpenVPN page.

That really should be sufficient information.


Olaf

On 11/11/2011 2:57 PM, Olaf Westrik wrote:
> Expect a 2.0.2 release tomorrow (2011-11-12), to fix a problem 
> generating the CA certificates.
> Looks like ssl is now taking our 999999 days literally, creating a cert 
> which openswan is not at all happy with.
> 
> I'll either use 10 years, 15 years or a configurable length for the 
> certificate(s).
> 
> 
> Everything committed so far will be included in the update package.
> 
> 
> Olaf

Are there any plans to allow Distinguished Names to be entered into the
"Local ID" or "Remote ID" fields when creating an IPSec connection?

There is a radio button for "Peer is identified by ... DER_ASN1_DN in
remote ID", but a certificate is still needed for this to work and
clicking any other button, turns this one off.

Any plans to have a GUI to revoke certificates or even update the time
stamp on the CRL?

Keep up the good work!
Mike

On Friday 11 November 2011 23:11:09 Michael Rasmussen wrote:
> On Fri, 11 Nov 2011 23:57:18 +0100
>
> Olaf Westrik <wei...@ip...> wrote:
> > I'll either use 10 years, 15 years or a configurable length for the
> > certificate(s).
>
> Could it be an idea to have some sort of certificates state displayed
> on one of the system status pages?

Michael,
 that is avery good idea.
Developers?

-- 
C U 
   Geo
 

On Fri, 11 Nov 2011 23:57:18 +0100
Olaf Westrik <wei...@ip...> wrote:

> 
> I'll either use 10 years, 15 years or a configurable length for the 
> certificate(s).
> 
Could it be an idea to have some sort of certificates state displayed
on one of the system status pages?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

Expect a 2.0.2 release tomorrow (2011-11-12), to fix a problem 
generating the CA certificates.
Looks like ssl is now taking our 999999 days literally, creating a cert 
which openswan is not at all happy with.

I'll either use 10 years, 15 years or a configurable length for the 
certificate(s).


Everything committed so far will be included in the update package.


Olaf