ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #1370295, was opened at 2005-11-30 18:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1370295&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 (example)
Status: Open
Priority: 5
Submitted By: thedevnull (thedevnull)
Assigned to: Nobody/Anonymous (nobody)
Summary: Host Integrity tool integrated into IPCOP -Aide, Samhain...

Initial Comment:
It would be wonderful to see a host integrity tool 
integrated into the core of IPCOP.  HIDS would allow 
a user to assure that their deployed IPCOP was not 
modified and or compromised (vital for a security 
perimeter device such as firewall).  Any of the GNU 
GPL code from Aide, Integrit, OSSEC HIDS, Osiris, 
Samhain would do the trick and would lend a lot to 
the project and its users.
	
See:
http://sourceforge.net/projects/aide
http://integrit.sourceforge.net/
http://ossec.underlinux.com.br/hids/
http://www.hostintegrity.com/osiris/
http://www.la-samhna.de/samhain/index.html

Thanks, 
/the/dev/null


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

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

What I would like to see is some ability
to deal with NAT-T. It appears that it is turned on
in the net to net setup, but there is no way to
customize it for known far end nat setups.
Perhaps I am missing something here, but
I have not found any nat-t setups other than
the glocal flag.
Thanks-
bob-

 
Begin snip 

> 
> Finally, I wanted to propose that we drop the left/right drop down on 
> the VPN page or at the very least move it to the advanced settings 
> page.  It really doesn't matter these days.  The fewer choices folks 
> have to make the easier it is to create VPNs.
> 
> Harry

End snip

If left and right mean nothing, why are they called that in the main page?

I agree they should be moved away from the general setup.  I know people who
tried IPCop (1.3 IIRC), saw the VPN docs (1.2 IIRC), and tried it.  They had
issues, thought it was too hard and left.
  Please update the docs to clarify.


  How does this affect a 3 or more node VPN?

At 12:11 PM +0100 11/29/05, Franck Bourdonnec wrote:
>Le Mardi 29 Novembre 2005 00:29, Charles Trevor a écrit :
>>  On Mon, 2005-11-28 at 14:54 -0800, Harry Goldschmitt wrote:
>>  > I've just started to define VPNs using 1.4.10 and certificates.  Some
>>  > of the documentation says that one side must be defined as left and
>>  > the other as right on the web pages.  Looking at
>>  > /var/ipcop/vpn/ipsec.conf, it seems like this is not the case.  The
>>  > requirement for left and right seems to be a hold over from earlier
>>  > releases when portions of the config file were exchanged to set up
>>  > the VPNs.  These days it seems like we could use left as local and
>>  > right as remote, or whatever.  Am I missing anything?
>>  >
>>  > Harry
>
>
>
>>From IPSEC.CONF
>
>To avoid trivial editing of the configuration file to suit it to each system
>involved in a connection, connection specifications are written in terms of
>left and right participants, rather than in terms of local and remote. Which
>participant is considered left or right is arbitrary; IPsec figures out which
>one it is being run on based on internal information. This permits using
>identical connection specifications on both ends. There are cases where there
>is no symmetry; a good convention is to use left for the local side and right
>for the remote side (the first letters are a good mnemonic).
>
>But in IPCop vpnmain.cgi, it is not symetric... No comment in the source so
>not easy to guess what difference it provides and WHY !!!
>
>Franck

I think I didn't express myself clearly.

First I wanted to confirm that left and right don't matter.

I also  wanted to try to correctly describe what happens when 
defining an IPCop net-to-net VPN.  Some of the descriptions on the 
net state that the left/right descriptions must be consistent on each 
side of the connection.  In other words, if you pick left for one 
side of the VPN, the other side MUST be defined as right.

Finally, I wanted to propose that we drop the left/right drop down on 
the VPN page or at the very least move it to the advanced settings 
page.  It really doesn't matter these days.  The fewer choices folks 
have to make the easier it is to create VPNs.

Harry

Sorry, wrong sender address:-)

On 2005-11-30 01:09:38, Michael Rasmussen wrote:
Hi all,

Was it possible to add port knocking as a feature to IPCop?

Motivation: These days especially ssh is a target for port scanning and =20
therefore it could be a great feature to add to IPCop.

Was it possible to add the feature of been able to black list on an IP =20
level in IPCop? Both static and dynamic. Dynamic could be implemented =20
this way: The user specifies which port number(s) should be handled by =20
black listing and how many times a given IP are allowed to =20
unsuccesfully connect before it is automatically added to the =20
blacklist. This would also require an extra GUI under log where the =20
user could maintain the blacklist. This would require an extra rule in =20
iptables.

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
BOFH excuse #268:

Neutrino overload on the nameserver
--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
Darth Vader:
	I sense something. A presence I've not felt since...

Bugs item #1369617, was opened at 2005-11-29 17:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1369617&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: Security (Patches etc)
Group: 1.4.10
Status: Open
Resolution: None
Priority: 5
Submitted By: Hector S. Mendoza O. (hectormendozao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in /usr/local/bin/setddns.pl

Initial Comment:
Setting dynamic DNS doesn't work properly if behind a 
DLS router and need to fetch a "real ip".

Error is in line 59 of file /usr/local/bin/setddns.pl

if ( &General::IpInSubnet 
($ip,'10.0.0.0','255.0.0.0') ||
     &General::IpInSubnet 
($ip,'172.16.0.0.','255.240.0.0') ||
     &General::IpInSubnet 
($ip,'192.168.0.0','255.255.0.0')) {


where it states 172.16.0.0. it should read 172.16.0.0 
it has a . (dot) more than it needs to.

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

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

Bugs item #1369531, was opened at 2005-11-29 21:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1369531&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: Web Proxy
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christoph Huber (truy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy acl doesn't recognize listening-port setting

Initial Comment:
Proxy acl doesn't recognize listening-port setting

The proxy acl file /var/ipcop/proxy/acl contains a 
fixed setting for the listening port of Squid.
Since Squid's listening port can be modified in the 
IPCop GUI, the actual setting should be written to the 
acl file.

The attached file contains a patch for the acl and the 
proxy cgi file /home/cgi-bin/proxy.cgi, which adds a 
variable for the listening port setting.


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

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

Le Mardi 29 Novembre 2005 20:37, SpamCatcher a =E9crit :
> Thanks for this sugestion Peter.
>
> I took a look at the file mentioned, but it was 63 bytes :-(
>
> Too bad i have got this hint only now, because this afternoon i checked
> the "minimize update" option, so i can not tell, how the file "settings"
> looked like, before this manipulation.
>
> I will observe the update-times and see, if something is changing...
>
> Regards
> Ecki
>
> > From: "Peter Francis" <pe...@pe...>
> > To: ipc...@li...
> > Date: Mon, 28 Nov 2005 22:54:57 -0000
> > Subject: Re: [IPCop-devel] DynDNS-Update takes very long since 1.4.10
> > Reply-to: Peter Francis <pe...@pe...>
> >
> > Ecki
> >
> > May I suggest you investigate and try the following:
> >
> > First, look at the length of the file called "settings" in
> > /var/ipcop/ddns.
> >
> > If this file is zero bytes long, then try the following:
> >
> > Go to the DynDNS page (Services -> Dynamic DNS) and in the
> > top pane, press the "save" button.
> >
> > Now look again at the length of the file called "settings" in
> > /var/ipcop/ddns.
> >
> > I believe that it will now have a non-zero length.
> >
> > My theory is that now your dyndns will be updated very soon
> > after the red interface (PPP) goes up.
> >
> > If, upon initial investigation, /var/ipcop/ddns/settings is
> > not zero bytes long, you've probably got another problem :-(
> >
> > (I had this problem and it worked for me!)
> >
> > Hope this helps...
> >
> > Peter
> >
> > PS I've raised a bug report for this.
> >
> >
> > On 22 Nov 2005 at 22:10, SpamCatcher wrote:
> >
> > From:           	"SpamCatcher" <ec...@fr...>
> > To:             	<ipc...@li...>
> > Subject:        	[IPCop-devel] DynDNS-Update takes very
> > long since 1.4.10
> > Date sent:      	Tue, 22 Nov 2005 22:10:36 +0100
> >
> > > I noticed that since 1.4.10 (not sure if 1.4.9 was affected too) it
> > > takes between 3 and 6 minutes to get the dyndns-update right (time
> > > between "PPP has gone up on ppp0" and "Dynamic DNS
> >
> > ip-update for ***
> >
> > > success"). This is much slower than before, where the
> >
> > update took only
> >
> > > seconds.
> > >
> > > This is especialy bad for vpn-users, where the net-to-net
> >
> > vpn's won't
> >
> > > come up again in time. It is possible to set the "Delay before
> > > launching VPN (seconds):" to 600 (10 minutes) but this is not an
> > > option for everyone.
> > >
> > > Any reasons known why the update takes that long?
> > >
> > > Regards
> > > Ecki
> > >
> > >

Hello,

=46ix ?
=3D=3D=3D=3D
In rc.updatered, change section from=20

if [ -s /var/ipcop/ddns/settings ]; then
  /usr/local/bin/setddns.pl
fi

to

if [ -s /var/ipcop/ddns/config ]; then
  /usr/local/bin/setddns.pl
fi

The test serve nothing. 'setddns' can deal with absence of settings...
No, the problem I see is when IPCop is behing a router and guess
the public IP. The call made by rc.updatered have 3 chance on 4
to be ignored!

A better choice is call with force option:
  /usr/local/bin/setddns.pl -f

Check and I will correct this if it suits.


=46ranck

I found this comment on the http://www.ipcop.org website. Don't know if it
is of interest to the dyndns users/developers...

Eric
=A0   =20
Re: IPCop 1.4.10 released (Score: 1)
by thachanh on Nov 23, 2005 - 07:54 AM

Before IPCop introduces a delay between vpn launch and IPCop 'connection'
for DynDNS hostname. I used some modification in /usr/local/bin/setddns.pl
at the ip cache update:


open(HOSTS, "/etc/hosts");
        my @hos;
        my $novpn =3D 1;
        @hos =3D <HOSTS>;
        close(HOSTS);
        open(HOSTS, ">/etc/hosts");
        foreach my $t (@hos) {
                if ($t =3D~ /vpnpoint/) {
                        $t =3D "$ip vpnpoint.local\n";
                        $novpn =3D 0;
                }
                print HOSTS $t;
        }
        print HOSTS "\n$ip vpnpoint.local\n" if ($novpn);
        close(HOSTS);

This code allow new ip update in /etc/hosts, and for the local VPN
IP/Hostname, i use 'vpnpoint.local' and it works. I think this way is bette=
r
for dynamic ip connections.
Regards.=20

Thanks for this sugestion Peter.

I took a look at the file mentioned, but it was 63 bytes :-(

Too bad i have got this hint only now, because this afternoon i checked
the "minimize update" option, so i can not tell, how the file "settings"
looked like, before this manipulation.

I will observe the update-times and see, if something is changing...

Regards
Ecki


> From: "Peter Francis" <pe...@pe...>
> To: ipc...@li...
> Date: Mon, 28 Nov 2005 22:54:57 -0000
> Subject: Re: [IPCop-devel] DynDNS-Update takes very long since 1.4.10
> Reply-to: Peter Francis <pe...@pe...>
>=20
> Ecki
>=20
> May I suggest you investigate and try the following:
>=20
> First, look at the length of the file called "settings" in=20
> /var/ipcop/ddns.
>=20
> If this file is zero bytes long, then try the following:
>=20
> Go to the DynDNS page (Services -> Dynamic DNS) and in the=20
> top pane, press the "save" button.
>=20
> Now look again at the length of the file called "settings" in=20
> /var/ipcop/ddns.
>=20
> I believe that it will now have a non-zero length.
>=20
> My theory is that now your dyndns will be updated very soon=20
> after the red interface (PPP) goes up.
>=20
> If, upon initial investigation, /var/ipcop/ddns/settings is=20
> not zero bytes long, you've probably got another problem :-(
>=20
> (I had this problem and it worked for me!)
>=20
> Hope this helps...
>=20
> Peter=20
>=20
> PS I've raised a bug report for this.
>=20
>=20
> On 22 Nov 2005 at 22:10, SpamCatcher wrote:
>=20
> From:           	"SpamCatcher" <ec...@fr...>
> To:             	<ipc...@li...>
> Subject:        	[IPCop-devel] DynDNS-Update takes very=20
> long since 1.4.10
> Date sent:      	Tue, 22 Nov 2005 22:10:36 +0100
>=20
> > I noticed that since 1.4.10 (not sure if 1.4.9 was affected too) it=20
> > takes between 3 and 6 minutes to get the dyndns-update right (time=20
> > between "PPP has gone up on ppp0" and "Dynamic DNS=20
> ip-update for ***=20
> > success"). This is much slower than before, where the=20
> update took 
> > seconds.
> >=20
> > This is especialy bad for vpn-users, where the net-to-net=20
> vpn's won't=20
> > come up again in time. It is possible to set the "Delay before=20
> > launching VPN (seconds):" to 600 (10 minutes) but this is not an=20
> > option for everyone.
> >=20
> > Any reasons known why the update takes that long?
> >=20
> > Regards
> > Ecki
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.  Get=20
> Certified Today=20
> > Register for a JBoss Training Course.  Free Certification=20
> Exam for All=20
> > Training Attendees Through End of 2005. For more info visit:
> > http://ads.osdn.com/?ad_idv28&alloc_id 845&opick=20
> > _______________________________________________ IPCop-devel mailing=20
> > list IPC...@li...=20
> > https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>=20
>=20
>=20
>=20
>=20
>=20
> --__--__--
>=20
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>=20
>=20
> End of IPCop-devel Digest
>=20

Bugs item #1369256, was opened at 2005-11-29 16:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1369256&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: 1.4.10
Status: Open
Resolution: None
Priority: 5
Submitted By: Florian Schnabel (fireball)
Assigned to: Nobody/Anonymous (nobody)
Summary: No version number in system log for updates

Initial Comment:
After applying updates to IPcop i checked the system
log via GUI and found the entry
"The following update installed sucessfully"
(i translated the emssage to english ..)
with that text i would expect the version of the update
done after the message.

i guess it should be there and it's a bug it's not ..
otherwise the german text is screwed up :-)

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

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

Le Mardi 29 Novembre 2005 00:29, Charles Trevor a =E9crit :
> On Mon, 2005-11-28 at 14:54 -0800, Harry Goldschmitt wrote:
> > I've just started to define VPNs using 1.4.10 and certificates.  Some
> > of the documentation says that one side must be defined as left and
> > the other as right on the web pages.  Looking at
> > /var/ipcop/vpn/ipsec.conf, it seems like this is not the case.  The
> > requirement for left and right seems to be a hold over from earlier
> > releases when portions of the config file were exchanged to set up
> > the VPNs.  These days it seems like we could use left as local and
> > right as remote, or whatever.  Am I missing anything?
> >
> > Harry



=46rom IPSEC.CONF

To avoid trivial editing of the configuration file to suit it to each syste=
m=20
involved in a connection, connection specifications are written in terms of=
=20
left and right participants, rather than in terms of local and remote. Whic=
h=20
participant is considered left or right is arbitrary; IPsec figures out whi=
ch=20
one it is being run on based on internal information. This permits using=20
identical connection specifications on both ends. There are cases where the=
re=20
is no symmetry; a good convention is to use left for the local side and rig=
ht=20
for the remote side (the first letters are a good mnemonic).

But in IPCop vpnmain.cgi, it is not symetric... No comment in the source so=
=20
not easy to guess what difference it provides and WHY !!!=20


=46ranck

On Mon, 2005-11-28 at 14:54 -0800, Harry Goldschmitt wrote:
> I've just started to define VPNs using 1.4.10 and certificates.  Some 
> of the documentation says that one side must be defined as left and 
> the other as right on the web pages.  Looking at 
> /var/ipcop/vpn/ipsec.conf, it seems like this is not the case.  The 
> requirement for left and right seems to be a hold over from earlier 
> releases when portions of the config file were exchanged to set up 
> the VPNs.  These days it seems like we could use left as local and 
> right as remote, or whatever.  Am I missing anything?
> 
> Harry
> 
> 
Harry,

Nope, Left for local and right for remote works fine.

Charlie

Ecki

May I suggest you investigate and try the following:

First, look at the length of the file called "settings" in 
/var/ipcop/ddns.

If this file is zero bytes long, then try the following:

Go to the DynDNS page (Services -> Dynamic DNS) and in the top pane, 
press the "save" button.

Now look again at the length of the file called "settings" in 
/var/ipcop/ddns.

I believe that it will now have a non-zero length.

My theory is that now your dyndns will be updated very soon after the 
red interface (PPP) goes up.

If, upon initial investigation, /var/ipcop/ddns/settings is not zero 
bytes long, you've probably got another problem :-(

(I had this problem and it worked for me!)

Hope this helps...

Peter 

PS I've raised a bug report for this.


On 22 Nov 2005 at 22:10, SpamCatcher wrote:

From:           	"SpamCatcher" <ec...@fr...>
To:             	<ipc...@li...>
Subject:        	[IPCop-devel] DynDNS-Update takes very long since 1.4.10
Date sent:      	Tue, 22 Nov 2005 22:10:36 +0100

> I noticed that since 1.4.10 (not sure if 1.4.9 was affected too) it
> takes between 3 and 6 minutes to get the dyndns-update right (time
> between "PPP has gone up on ppp0" and "Dynamic DNS ip-update for ***
> success"). This is much slower than before, where the update took only
> seconds.
> 
> This is especialy bad for vpn-users, where the net-to-net vpn's won't
> come up again in time. It is possible to set the "Delay before
> launching VPN (seconds):" to 600 (10 minutes) but this is not an
> option for everyone.
> 
> Any reasons known why the update takes that long?
> 
> Regards
> Ecki
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam for All
> Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id 845&opick
> _______________________________________________ IPCop-devel mailing
> list IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

I've just started to define VPNs using 1.4.10 and certificates.  Some 
of the documentation says that one side must be defined as left and 
the other as right on the web pages.  Looking at 
/var/ipcop/vpn/ipsec.conf, it seems like this is not the case.  The 
requirement for left and right seems to be a hold over from earlier 
releases when portions of the config file were exchanged to set up 
the VPNs.  These days it seems like we could use left as local and 
right as remote, or whatever.  Am I missing anything?

Harry

Bugs item #1368672, was opened at 2005-11-28 22:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1368672&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: Installation
Group: 1.4.10
Status: Open
Resolution: None
Priority: 5
Submitted By: PeterF (pdf47)
Assigned to: Nobody/Anonymous (nobody)
Summary: DynDNS update only works from crontab

Initial Comment:
This report details an inconsistency in dynamic DNS
(ddns) update process.

After a fresh install of IPCop, the two configuration
files (config and settings) in /var/ipcop/ddns are zero
bytes long.

Using the GUI to configure ddns (services -> dynamic
dns) there are two panes presented.  If the user views
the top pane (Settings) and decides that the data is
valid and doesn't press save, then the file
/var/ipcop/ddns/settings remains with zero bytes.

The user can enter valid data into the middle pane (Add
a host).  This data will then appear in the lower pane
(current hosts) and also be saved in the file
/var/ipcop/ddns/config.

In this state, the entries in the crontab which invoke
/usr/local/bin/setddns.pl will cause the appropriate
ddns host to be updated.

However, when the red interface changes from a
disconnected to a connected state, the shell script
/etc/rc.d/rc.updatered is run.  This script will only
run /usr/local/bin/setddns.pl _if_ the length of
/var/ipcop/ddns/settings is _not_ zero bytes. 
setddns.pl will run normally on the next invocation
from the crontab.

I believe that this is why some users experience a slow
update of ddns when the red interface comes up.

Work-around
====
Press save button in top pane on ddns set up page

Fix ?
====
In rc.updatered, change section from 

if [ -s /var/ipcop/ddns/settings ]; then
  /usr/local/bin/setddns.pl
fi

to

if [ -s /var/ipcop/ddns/config ]; then
  /usr/local/bin/setddns.pl
fi



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

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

Feature Requests item #1367393, was opened at 2005-11-27 09:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1367393&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: None
Status: Open
Priority: 5
Submitted By: Odoardo Maria Calamai (omcalamai)
Assigned to: Nobody/Anonymous (nobody)
Summary: GUI improvement

Initial Comment:
Because the top of page for the navigation is 
scrolled up when the page contens is more bigger that 
the screen, one button for return at top of page help 
to navigate without the need to it the scrollbar

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

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

Update:

I did a little more experimenting and testing of this, I
even commented out all the REDNAT rules, even the masq rule,
and still found that the IP was being set to the .242
address. This completely went against how things should
behave. Then it hit me like a ton of bricks as to what was
going on with the SNAT. I followed my hunch and sure enough
- there it was a serious bug with IPCop..... it relied on ME
using my brain and paying attention to what I was doing! 
<laugh> I am using the advance webproxy and advance url
filter addons. If you have the webproxy setup on green in
transparent mode it will automatically convert the IP to the
external interface. As soon as I turned off the web proxy..
the IP's were SNAT'ed properly. Now this probably should not
work this way as it means you cannot use a webproxy or the
content filters (which rely on the webproxy running) with
SNAT entries. Not a real big deal for my application needs
here as the SNAT is only needed to access external systems
via https and other protocols, not port 80. Mystery solved!
Thanks for the quick reply, I appreciate your input.

K9


--------------------------------------
   This Email Was brought to you by
               WebMail
    A Netwin Web Based EMail Client
  http://netwinsite.com/webmail/tag.htm

>> -----Original Message-----
>> From: ipc...@li...
>> [mailto:ipc...@li...]On Behalf Of k9
>> Sent: 26 November 2005 17:12
>> To: IPC...@li...
>> Subject: [IPCop-devel] 1.4.10 SNAT Issue
>>
>>
>> I've got a strange one here. Running 1.4.10 on a Compact
>> Flash based system and trying to use outbound SNAT rules for
>> the internal IP's. Here are my rc.firewall modification
>> entries:
>>
>> # Outgoing masquerading disabled
>> # /sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE
>> /sbin/iptables -t nat -A REDNAT -s 192.168.5.55 -o $IFACE -j
>> SNAT --to xx.xx.xx.243
>> /sbin/iptables -t nat -A REDNAT -s 192.168.5.56 -o $IFACE -j
>> SNAT --to xx.xx.xx.244
>> /sbin/iptables -t nat -A REDNAT -s 192.168.5.57 -o $IFACE -j
>> SNAT --to xx.xx.xx.245
>> /sbin/iptables -t nat -A REDNAT -s 192.168.5.58 -o $IFACE -j
>> SNAT --to xx.xx.xx.246
>> # NAT all others to .242
>> /sbin/iptables -t nat -A REDNAT -o $IFACE -j SNAT --to
>> xx.xx.xx.242
>>
>> This should handle the the static map of the addresses for
>> outbound communications but when I go to a site to validate
>> that the translation is occurring, everything shows as being
>> the xx.xx.xx.242 address. Am I missing something here?? This
>> used to work in the 1.3 versions, has anything changed? Any
>> help on this would be greatly appreciated as I am under the
>> gun on this one with my boss.
>>
I believe that you have to use "--to-source xx.xx.xx.243", not "--to
xx.xx.xx.243".
According to Iptables documentation I've read "--to" is only a valid option
for "NETMAP" and "SAME" targets. The "SNAT" target requires "--to-source".
Let us know if this does make a difference.
Regards,
Crimblepud
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: 25/11/2005

Hi

I've just added the following paragraph to CVS for the Firewall section of
the Admin Manual in XML. Can I get some peer review/comments on the
accuracy/behaviour of the following description?

> Firewall Options Administrative Web Page
> 
> This subsection allows you to configure some firewall behaviour. This is 100%
> optional, so you may safely ignore this section if you do not wish to make use
> of this feature.
> 
> <Firewall Options screenshot showing box with 'Disable ping response'>
> 
> Disable ping response
> 
> No - IPCop responds to ping requests on any interface. This is the default
> behaviour. 
> 
> Only RED - IPCop does not respond to ping requests on the Red Interface.
> 
> All Interfaces - IPCop does not respond to any ping requests on any interface.
> 
> To save changes, press the 'Save' button.

Thanks.

Eric

I've got a strange one here. Running 1.4.10 on a Compact
Flash based system and trying to use outbound SNAT rules for
the internal IP's. Here are my rc.firewall modification
entries:

# Outgoing masquerading disabled
# /sbin/iptables -t nat -A REDNAT -o $IFACE -j MASQUERADE
/sbin/iptables -t nat -A REDNAT -s 192.168.5.55 -o $IFACE -j
SNAT --to xx.xx.xx.243
/sbin/iptables -t nat -A REDNAT -s 192.168.5.56 -o $IFACE -j
SNAT --to xx.xx.xx.244
/sbin/iptables -t nat -A REDNAT -s 192.168.5.57 -o $IFACE -j
SNAT --to xx.xx.xx.245
/sbin/iptables -t nat -A REDNAT -s 192.168.5.58 -o $IFACE -j
SNAT --to xx.xx.xx.246
# NAT all others to .242
/sbin/iptables -t nat -A REDNAT -o $IFACE -j SNAT --to
xx.xx.xx.242

This should handle the the static map of the addresses for
outbound communications but when I go to a site to validate
that the translation is occurring, everything shows as being
the xx.xx.xx.242 address. Am I missing something here?? This
used to work in the 1.3 versions, has anything changed? Any
help on this would be greatly appreciated as I am under the
gun on this one with my boss.


--------------------------------------
   This Email Was brought to you by
               WebMail
    A Netwin Web Based EMail Client
  http://netwinsite.com/webmail/tag.htm

Bugs item #1366357, was opened at 2005-11-25 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1366357&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: 1.4.10
Status: Open
Resolution: None
Priority: 5
Submitted By: shado23 (shado23)
Assigned to: Nobody/Anonymous (nobody)
Summary: portfw fails on reconnect

Initial Comment:
I'm on DSL with 24h disconnect and everytime this  
occurs I have to manually reset the port forwardings,  
either in the GUI or through setportfw.  
The same goes for VPN, even though there is a limit  
of 60 set as suggested by the GUI.If you want me to  
I'll open a separate bug about this, but it seems to  
me that it's the same thing, that these things just  
aren't updated on reconnect somehow.  
Anyways I installed version 1.4.9 and updated to  
1.4.10, the problem persists with both versions.  
Other than that it's a breeze. :)  
I didn't find anything interesting concerning this in 
the logs, so I'm not attaching them at this point.  

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

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

Bugs item #1366165, was opened at 2005-11-25 10:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1366165&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: Security (Patches etc)
Group: 1.4.9
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Hupfeldt Nielsen (lhnielsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error applying patch 10 using Safari

Initial Comment:
While uploading patch 10 using the Mac OS X Safari browser (which in all 
respects work fine with IPCOP) I get an error about invalid response or 
something like that. Sorry I don't remember the exact error message, if 
you need it I can re-apply patch 10 if that is possible.
Note I have not tried another browser so I don't known if this problem is 
Safari specific. I have seen it twice with Safari.

The patch applied extreemly quickly so I am also worried if it is applied 
correctly, but I guess that updating the applied patches list is the last 
thing done?

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

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

On Thursday 24 November 2005 22:00, Joseph wrote:
> Hello Everyone,
>
>   I had a question about Endian project.  As they are
> a GPL derivative work based on IPCop is there any
> effort from their community to share their code
> improvements directly with the group that is helping
> them create a commercial product.  Reason why I ask is
> that some features may be parallel and possibly allow
> reuse.
>
> Thanks,
> J
>

 Peter Warasin and Ralph Vallazza of Endian made an announcement to this group 
on 06-10-05 about exactly this subject. Basically, they used the LFS programs 
and made them into rpm packages as well as made standard, some of the 
programs that some have made into IPCop addons like Dan's Guardian and 
others. I installed RC6 in a guest VMWare session to try it. It is very 
impressive at this stage. The only problem I saw was that the web gui is 
missing the menu link to set up dial up networking but you CAN type the url 
into the address bar of the browser and get to it as the cgi script and web 
page is in there with little change from IPCop. The other thing that differs 
which may make sense is that it has no floppy backup or restoration, the 
backup is stored wherever you save it and the restore as well as the rest of 
network setup is done AFTER you log in as admin the first time. Since many 
machines people use have no floppy drives, this works extremely well. The 
green network is set up during install so you can log in to finish setting it 
up or just import the backup tar.gz file if that exists. I was able to 
manually use many of my IPCop files that get backed up in the ipcop tar.gz 
backup file and simply take them from /var/ipcop and overwrite some of them 
in /var/efw. Now I have backups of both systems. EFW also uses the 2.6 kernel 
already whereas we will see it in IPCop 1.5 which is already using the latest 
2.6 kernel. 
 The rpm feature makes it very easy to upgrade the system in bits and pieces 
but it took them a lot of work to make rpm's out of all the lfs programs 
initially. For those who take IPCop and load it to the hilt with addons, this 
might suit them as it comes standard with some of the programs they add to 
IPCop. They do NOT offer Yum repositories to the general public due to 
resources but it might be possible if volunteers offered to host them 
elsewhere, we'll see. I think this fork will stick but it is not the first 
fork. I never heard much about one fork called "IPFrog" or something like 
that which came about earlier.


Dave

Hello Everyone,

  I had a question about Endian project.  As they are
a GPL derivative work based on IPCop is there any
effort from their community to share their code
improvements directly with the group that is helping
them create a commercial product.  Reason why I ask is
that some features may be parallel and possibly allow
reuse. 

Thanks,
J