ipcop-devel Mailing List for IPCop Firewall

Ralph Crongeyer wrote:

> Hi all,
> I'm using IPCop 1.4.5 and it seems the NTP Time service is not working 
> with Win XP? This was working with version 1.4.2 (which is what I 
> started with when I swithced from the 1.3 series). Here's the error 
> I'm getting:
>
> "An error occured while Windows was synchronizing with 192.168.1.1. The
> time simple was rejected because: The peer's stratum is less than the
> host's stratum."
>
> Is anyone else having this problem?
> How can I fix it?
>
> Thanks
>
> Ralph
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great 
> events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

Please disregard this message.

Sorry everyone. :-(
It turns out it was my fault, I had the wrong timezone set on my IPCop 
box!  Hee hee hee....  Oops!

Ralph

Hi all,
I'm using IPCop 1.4.5 and it seems the NTP Time service is not working 
with Win XP? This was working with version 1.4.2 (which is what I 
started with when I swithced from the 1.3 series). Here's the error I'm 
getting:

"An error occured while Windows was synchronizing with 192.168.1.1. The
time simple was rejected because: The peer's stratum is less than the
host's stratum."

 Is anyone else having this problem?
How can I fix it?

Thanks

Ralph

Tom Eichstaedt wrote:

> Franck Bourdonnec wrote:
>
>> Le Vendredi 29 Avril 2005 20:09, Ralph Crongeyer a =E9crit :
>>
>>> Hi all,
>>> Does IPCop have UPS support built in or as an addon? I maean can it =

>>> either
>>> be the master UPS controller, or at least be the slave?
>>> I have my Debian server setup with the APC UPS connected to it (I'm =

>>> running
>>> apcupsd to talk to it)  and would like my IPCop box to be setup as th=
e
>>> slave so my server can send the shutdown signal to my IPCop box, =

>>> upon power
>>> failures.
>>>
>>> Thanks
>>>
>>> Ralph
>>
>>
>>
>>
>> http://www.h-loit.de/apcupsd/index-apcupsd.htm
>>
>
> apcupsd v0.1.1 addon for IPCop V1.4.x
> --> http://www.ipcop-pro.de/news.php
>
> Kind regards.
> -Tom-

Thanks for the help everyone.
When I try to install that addon it complains that it was created for =

another version of IPCop and it won't install?
Is there a newer vervion of this addon?

Thanks

Ralph

Bugs item #1177572, was opened at 2005-04-06 09:37
Message generated for change (Comment added) made by franck78
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1177572&group_id=40604

Category: VPN
Group: 1.4.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tran Thach Anh (thachanh)
Assigned to: Mark Wormgoor (riddles)
Summary: IPCop 1.4.5 doesn't start VPN connection after booting.

Initial Comment:
The bug SF 1167658 is fixed in IPCop 1.4.5, but VPN 
connections does not start automatically after IPCop 
restarted.
See the log, it produces:
13:16:25 ipsec__plutorun: 022 "toPartner" we have no 
ipsecN interface for either end of this connection
13:16:25 ipsec__plutorun ...could not route 
conn "toPartner"

The VPN connections is OK after disabling/enabling the 
VPN feature.

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

Comment By: Franck Bourdonnec (franck78)
Date: 2005-04-30 22:47

Message:
Logged In: YES 
user_id=1041094

# if [ -s /var/ipcop/ddns/settings ]; then  
/usr/local/bin/setddns.pl  
#fi 
 
setddnns.pl does not interact with vpn. 
When config file is empty, calling setddns.pl will do 
nothing. It just can't invent a provider. 
If settings exist, well, setddns.pl do it's job. 
So, I have difficulty to imagine why a call to 'nothing' 
can change vpn starting. 
 
I have erased a start of VPN before RED is up. And the 
error you show, "could not route to partner" seems good 
whith this. 
Please try with this rc.netaddress.up: 
http://cvs.sourceforge.net/viewcvs.py/ipcop/ipcop/src/rc.d/Attic/rc.netaddress.up?rev=1.7.2.11&only_with_tag=IPCOP_v1_4_0&view=markup 
It starts VPN after red is up. 
 
(replace 'CONFIG_ROOT' whith '/var/ipcop' ) 
 
I have checked that 'setddns.pl' is called before 
'ipsecctrl S'. Maybe a problem possible with dyndns is the 
vpn peer will not find our machine because 'real' dns is 
not propagated yet. The peer respond to somewhere on the 
internet. 
 
First, try with this rc.netadress.up and report errors on 
both machines making the vpn. 
 
 
  

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

Comment By: Tran Thach Anh (thachanh)
Date: 2005-04-30 06:54

Message:
Logged In: YES 
user_id=675154

Another infor:
I use Dynamic DNS (www.dyndns.org) for two partners. But 
the version 1.4.0 works fine with same configuration.

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

Comment By: hector (escriou)
Date: 2005-04-19 14:46

Message:
Logged In: YES 
user_id=1254620

To resolve this problem make a Save on the dynamic dns 
Page and the file size of /var/ipcop/ddns/settings will be 
different of zero


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

Comment By: hector (escriou)
Date: 2005-04-19 13:26

Message:
Logged In: YES 
user_id=1254620

if i put in comment the if condition of dynamic connection 
script from rc.updatered 
1.4.5 : 
# if [ -s /var/ipcop/ddns/settings ]; then 
/usr/local/bin/setddns.pl 
#fi
the vpn connection work well after booting 

in ipcop 1.4.0 there is not if condition for this part of script
 


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

Comment By: Franck Bourdonnec (franck78)
Date: 2005-04-15 16:11

Message:
Logged In: YES 
user_id=1041094

Hello,

instead of disabling/enabling VPN can you try with

'ipsecctrl' utility. It has some options
S: start/restart
D: stop
R: reload certificates

Maybe the vpn starts too early in ipcop.
You can test (and report) with adding
'ipseccrtr S' somewhere at the and
of "rc.local"



Franck

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

Comment By: hector (escriou)
Date: 2005-04-07 10:48

Message:
Logged In: YES 
user_id=1254620

We have the same problem since ipcop 1.4.4. Editing and 
saving vpn parameters restart immediatly the vpn.

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

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

Le Samedi 30 Avril 2005 12:16, vous avez =E9crit :
> I don't like too. I think you consider too much v1.4 as a development
> version.
> Our priority is to have a stable release, broke less things as we can (ev=
en
> if we have not done it in v1.4.3/1.4.4).
>
> But dhcp.cgi change is not yet ready to be released and is not the answer
> of RFE 1143541 as the options related can't be added.
that something I did not mention yet because not necessary:
the actual compiled version do not accept
'options-NN' syntax name as stated in the man.
The way is universal, whitout syntax but is maybe-disabled or not enabled
in compilation .
So the to use options 132 you must know it's name.
I did not verify this existence, sorry.
Applying to blue or green or both is functionnal.



> I had no answer from your last change in rc.network.up (removal of dnsmasq
> and ipsecctrl call) wich have been made in contrary as what was related in
> changelog of this file.
Lost message ?
Resent.  no answer=3D>no problem.

> We have bug reports to close and other subjects to be fixed.


> Since the backup from the web interface is available, we are wrong to make
> upgrade only in upgrade_v130_v140.
> We will need to write a real upgrade script available from both backups.
> And this will be a painfull part as we can't continue to just replace
> official old files by the new official files.


> I would prefer if the changes are tested in main branch and backported on=
ly
> in v1.4 :
> - when they are ready and stable,
> - when upgrade is easy to write
Well, something I tend to remove of my mind. I must take a hammer
in burn on my screen : think upgrade from 1.3


> I will be happy to work with you if everything commited is 100% ready to =
be
> released and with a better timing.
Yes, but last time dhcp was to big.....
This : smalls steps easily removed !!!=20


> There is only a small windows open after each release to include a new
> feature.
See latter in this message:

> Now we need to release v1.4.6 in a few days and it is not time to include
> new features and new texts.
We do not enable/include this gui screen in 1.4.6. Future translations can=
=20
begin to be present in pl file , it gives more time to translate them for=20
1.4.7 or even 1.4.8 no ?

> We should only accept bug fixes for now. Because of snort update, we can't
> postpone more this version.
Ok I understand this. Snort is critical, so need an update as soon as possi=
ble=20
? Really need to someone (you!!!) to be the boss and=20

>
> You should be able to register at
> https://lists.sourceforge.net/lists/listinfo/ipcop-core
> to be better informed of the news ( if it does not work, let me know)
Good


> I may need better commmunicate at what should to be include in a release
> and at the planned timing.
YEs YEs a boss !!!  ;-)


> In this version, I have to look at more userspace package upgrade (new
> tcpdump and libpcap is planned to be released the first may and will fix
> vulnerabilties).
!!!

> In next versions, I think :
> - at a kernel 2.4.30 upgrade, include vlan support and more wireless
> drivers (and wireless configuration from the web interface)
I can do interface for wireless data needed (mode, keys, size, wep/wpa,....=
),=20
See, all thoses constant strings could be included now for translators begi=
n=20
working  and used latter !
The gui screen can be made, adjusted, tested for usablity before it even do=
=20
something onto the ipcop logic.
Title of screen can be 'PRELIMINARY WLAN setup, please report=20
misunderstandings',

> - integrate the features of some add-ons : advproxy, maybe others.
> We have too look at what is used and could be include.
oui oui, "squidguard" Gilles. For home office use, it's really a must have=
=20
tools to protect childrens.

Le Samedi 30 Avril 2005 08:32, vous avez =E9crit :
> on 30/4/05 1:25 am, Franck Bourdonnec at fra...@us...
>
> wrote:
> > Update of /cvsroot/ipcop/ipcop/config/cfgroot
> > In directory
> > sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13651/config/cfgroot
> >
> > Modified Files:
> > Tag: IPCOP_v1_4_0
> > header.pl
> > Log Message:
> > Add a new cgi page under firewall tab, designed to receive future reque=
st
> > about specificcaly firewall options.
> > Example: disable ping.
> > This is only the GUI part, nothing is done yet.
> > (need to create /var/ipcop/optionsfw/settings file to work)
> >
> >
> > Index: header.pl
>
> Hold on Franck, is this too big a change, just before v1.4.6 is released?
>
> We also have to consider how we _patch_ header.pl, as we were going to st=
op
> replacing it completely, which might break users addons.
>
> Can I suggest you hold it until v1.4.7, to give us some time?
>
> Regards.
>
> Eric
No problem,

If it's too early I remove all or we can just remove the entry menu=20
(headder.lp) and let the file 'optionsfw' and classic stuff for 'settings'=
=20
ready for next release. It won't hurt (absent from .iso).
I dont think a special page especially from 'firewalling' is bad isn'it ?

The next step in using variable is module  rc.firewall:
=2Deval readhash /var/ipcop/optionsfw/settings   (nothing new here)
=2Dif 'SKIP-PING eq YES'
		iptables -A INPUT icpmt-type-8    (original line not touched)
=2Dfi

Not really a big issue, we know ipcop is ok whitout ping enabled , see numb=
er=20
of message speaking of this.

Tell me if I remove entry in header.pl for 1.4.6,=20

I want to continue to update rc.firewall with my addition commented, to that
everybody can vote on accept or not (or see a bug) befoer enabling.



=46ranck

In message <427...@sp...>
          Sean Porterfield <ip...@sp...> wrote:

> Thanks Josh, that helped a lot.  I guess I didn't search on the correct
> terms when I checked the user list archives.  From what I read there, it
> sounds like this is not considered an IPCop problem because IPCop is
> thought of as a firewall and not a router.  Personally, I've never
> wanted to block green to green traffic.

This isn't really green to green traffic - the source and destination address
aren't both in the green subnet. If they were then the packets wouldn't even
be passing through IPCop in the first place. IPCop was never really designed
to route between subnets that aren't directly connected to it.

> The rule to RETURN matches tcp traffic but not icmp.  They show in the
> log as OUTPUT on eth0 (green) with icmp type 0.  Is there a way to find
> out which rule is really blocking something?  (And better yet, what is
> the "correct" rule to not block it?)

> kernel: OUTPUT IN=eth0 OUT=eth0 SRC=10.9.3.3 DST=10.9.1.10 LEN=284
> TOS=0x00 PREC=0x00 TTL=127 ID=58715 PROTO=ICMP TYPE=0 CODE=0

What you probably want is something like:

 iptables -A CUSTOMFORWARD -i eth0 -o eth0 -j ACCEPT

In addition to the rule already given. That should stop IPCop paying
attention to any packets coming in from green that are also being routed back
out of green. I don't think it'll break anything else, or open any holes, but
it's entirely untested so use at your own risk.

-- 
 Robert Kerr

Feature Requests item #1192987, was opened at 2005-04-30 15:05
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=1192987&group_id=40604

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Julien HENRY (henryju)
Assigned to: Nobody/Anonymous (nobody)
Summary: uPnP support

Initial Comment:
It could be interesting to have uPnP support for those
who are using messenger, because I don't like idea of
opening all the udp ports.

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

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

Thanks for the offer, but I've now got it to build after tracking down a
few other files.  Re-reading my original post, I sounded like a complete
newbie :)  The point I was failing to make was that the as released
1.4.5 source tarball would no longer build as dependencies have moved. 
I guess that this will always be a risk unless IPCop.org hosts them, but
that could lead to a nasty bandwidth bill.

Regards,
Dave

Franck Bourdonnec wrote:
> Le Vendredi 29 Avril 2005 20:09, Ralph Crongeyer a =E9crit :
>=20
>>Hi all,
>>Does IPCop have UPS support built in or as an addon? I maean can it eit=
her
>>be the master UPS controller, or at least be the slave?
>>I have my Debian server setup with the APC UPS connected to it (I'm run=
ning
>>apcupsd to talk to it)  and would like my IPCop box to be setup as the
>>slave so my server can send the shutdown signal to my IPCop box, upon p=
ower
>>failures.
>>
>>Thanks
>>
>>Ralph
>=20
>=20
>=20
> http://www.h-loit.de/apcupsd/index-apcupsd.htm
>=20

apcupsd v0.1.1 addon for IPCop V1.4.x
--> http://www.ipcop-pro.de/news.php

Kind regards.
-Tom-
--=20
http://www.tom-e.de

Le Vendredi 29 Avril 2005 20:09, Ralph Crongeyer a =E9crit :
> Hi all,
> Does IPCop have UPS support built in or as an addon? I maean can it either
> be the master UPS controller, or at least be the slave?
> I have my Debian server setup with the APC UPS connected to it (I'm runni=
ng
> apcupsd to talk to it)  and would like my IPCop box to be setup as the
> slave so my server can send the shutdown signal to my IPCop box, upon pow=
er
> failures.
>
> Thanks
>
> Ralph


http://www.h-loit.de/apcupsd/index-apcupsd.htm

Gilles Espinasse wrote:

>>>Sean Porterfield wrote:

>>terms when I checked the user list archives.  From what I read there, it
>>sounds like this is not considered an IPCop problem because IPCop is
>>thought of as a firewall and not a router.  Personally, I've never
>>wanted to block green to green traffic.
>>
> 
> This is not a question of blocking green to green.
> But by setting a return path different for your data from the source way,
> you broke tcp protocol.
> What goes inside through the vpn need to return the same way through the
> vpn.

Perhaps something has been lost in translation or semantics, but I 
disagree.  If every return path had to match, the Internet would be dead.

As an example, I have 3 connections at my corporate office to my backup 
location.  A packet could get there or back on any of them.  The router 
may have a preference for which route it chooses based on line speed and 
saturation, but there is no reason I should expect the return on the 
same line.  The source and destination IP address are all that matter.

Now, if you're talking about natting the packet, that's different.

I see no reason to add static routes to every PC in every one of my 
branches.  That's what routers are for.  (Besides, it's very complicated 
to change things if there are static routes on every device.)

Some of my devices sending packets only know IP address, subnet mask, 
default route.  They do not understand additional routes or redirection. 
  They expect a router to handle that, as do I.


>>The rule to RETURN matches tcp traffic but not icmp.  They show in the
>>log as OUTPUT on eth0 (green) with icmp type 0.  Is there a way to find
>>out which rule is really blocking something?  (And better yet, what is
>>the "correct" rule to not block it?)
>>
> 
> Have you not seen in rc.firewall
>  # NEW TCP without SYN
>  /sbin/iptables -A BADTCP -p tcp ! --syn -m state --state NEW -j NEWNOTSYN
> 
> A solution is described in
> http://marc.theaimsgroup.com/?l=ipcop-user&m=110614432906439

Yes, I saw the rule in the file and have already read that message.  The 
rule looks like it matches on tcp packets only.  I have already followed 
the advice to add a custom rule allowing my network's NEWNOTSYN.  As I 
read it, that rule doesn't match icmp which is my other problem.

One thing I've learned over the years is that it's better to ask a 
question when I don't understand something and be thought a fool than to 
change something and be proven a fool.

The firewall I'm working with is over 4 hours away by car.  I would 
really prefer not to break it!

At any rate, this portion of my discussion probably belongs on the user 
list if, as I said above, the developers feel IPCop doesn't need to 
handle this situation on its own.

Thanks,
Sean

----- Original Message ----- 
From: "Javier Jaspe" <JJ...@so...>
To: <ipc...@li...>
Sent: Friday, April 29, 2005 10:47 PM
Subject: [IPCop-devel] Connections page incomplete


> Many times, IPTables Connections Tracking list is incomplete. When this
> happens, not even IPCop logos at the bottom of the page show up.
> 
> The problem was connections.cgi aborting because it doesnt handle icmp
> protocol, sending an empty string to ipv4_in_network in Net::IPv4Addr.
> It then caused an error that aborted script execution.
> 
> I am using icmp protocol in a simple software that verifies vpn
> connectivity and warns me if something goes wrong, so my ip_conntrack
> always has more than one entry for icmp packets so the connection list
> is never complete.
> 
> I added a few lines to connections.cgi v 1.6.2.11 to process icmp
> entries in /proc/net/ip_conntrack and that worked fine for me. I checked
> v 1.8 on cvs and didnt find anything about icmp.
> 
> If my solution is correct, is this the right place to post it?
> 
Use the bug report on sourceforge.
There you can post a diff -u of your changes

Many times, IPTables Connections Tracking list is incomplete. When this
happens, not even IPCop logos at the bottom of the page show up.

The problem was connections.cgi aborting because it doesnt handle icmp
protocol, sending an empty string to ipv4_in_network in Net::IPv4Addr.
It then caused an error that aborted script execution.

I am using icmp protocol in a simple software that verifies vpn
connectivity and warns me if something goes wrong, so my ip_conntrack
always has more than one entry for icmp packets so the connection list
is never complete.

I added a few lines to connections.cgi v 1.6.2.11 to process icmp
entries in /proc/net/ip_conntrack and that worked fine for me. I checked
v 1.8 on cvs and didnt find anything about icmp.

If my solution is correct, is this the right place to post it?

Hi all,
Does IPCop have UPS support built in or as an addon? I maean can it either be 
the master UPS controller, or at least be the slave? 
I have my Debian server setup with the APC UPS connected to it (I'm running 
apcupsd to talk to it)  and would like my IPCop box to be setup as the slave 
so my server can send the shutdown signal to my IPCop box, upon power 
failures.

Thanks

Ralph
-- 
Linux, to keep you humble.

On Friday 29 April 2005 1:52, SourceForge.net wrote:
> Bugs item #1192398, was opened at 2005-04-29 08:52
> Message generated for change (Tracker Item Submitted) made by Item
> Submitter You can respond by visiting:
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D428516&aid=3D119239=
8&group_
>id=3D40604
>
> Category: General
> Group: 1.4.5
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Ponty (ponty13)
> Assigned to: Mark Wormgoor (riddles)
> Summary: Bad Routing Performance
>
> Initial Comment:
> My IPCop machine is a Compaq Proliant (PII/400 with
> 128MB RAM, or something close to that).  The RED
> interface is the built-in Compaq NIC (e100), and the
> GREEN is a 3Com (3c59x).
> The machine has plenty of free disk space, sits mostly
> around 95% idle, and has not been using swap at all.
>
> The GREEN interface is plugged into a 10/100 switch,
> and the RED is plugged into a 10MBit hub, shared with a
> 9MBit cable modem.
>
> Since upgrading to 1.4.5, which may just be a
> coincidence, I have had intermittent problems with
> extremely bad performance.  Pinging the machine on the
> GREEN network results in over 80% packet loss.  The
> routing also shows the same performance loss--both
> incoming and outgoing traffic.  This pretty much
> renders my GREEN network useless until the machine is
> restarted.
>
> Although I have not tried using the rc.d scripts to
> stop/start services, rebooting the machine definitely
> resolves the problem for some time--from a day up to
> about a week.
>
> I am suspicious about malicious DoS attacks, but not
> being a security expert, I don't know what to look for
> in the IDS logs.
>
> Any help or suggestions on what I can do/look for area
> greatly appreciated.  Let me know if there's any more
> information I can provide.  Thanks!
>
Hi,
 On one of my sites I use this same type of setup (proliant etc) and had th=
e=20
same hassle about a year ago . it proved to be the green NIC by coincidence=
=20
also a 3com , changing the NIC cured the problem.


=2D-=20
TTFN
     ^
=A0 =A0 @ @ =A0
=A0 =A0 /V\ =A0 =A0
=A0 /( =A0 )\ =A0Caparo=20
=A0 =A0^^ ^^   =A0 =A0=20
http://www.saltmine.org.uk

Bugs item #1192398, was opened at 2005-04-29 08:52
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=1192398&group_id=40604

Category: General
Group: 1.4.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ponty (ponty13)
Assigned to: Mark Wormgoor (riddles)
Summary: Bad Routing Performance

Initial Comment:
My IPCop machine is a Compaq Proliant (PII/400 with
128MB RAM, or something close to that).  The RED
interface is the built-in Compaq NIC (e100), and the
GREEN is a 3Com (3c59x).
The machine has plenty of free disk space, sits mostly
around 95% idle, and has not been using swap at all.

The GREEN interface is plugged into a 10/100 switch,
and the RED is plugged into a 10MBit hub, shared with a
9MBit cable modem.

Since upgrading to 1.4.5, which may just be a
coincidence, I have had intermittent problems with
extremely bad performance.  Pinging the machine on the
GREEN network results in over 80% packet loss.  The
routing also shows the same performance loss--both
incoming and outgoing traffic.  This pretty much
renders my GREEN network useless until the machine is
restarted.

Although I have not tried using the rc.d scripts to
stop/start services, rebooting the machine definitely
resolves the problem for some time--from a day up to
about a week.

I am suspicious about malicious DoS attacks, but not
being a security expert, I don't know what to look for
in the IDS logs.

Any help or suggestions on what I can do/look for area
greatly appreciated.  Let me know if there's any more
information I can provide.  Thanks!

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

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

Gilles Espinasse wrote:
>----- Original Message ----- 
>From: "Dave Smith" <da...@sm...>
>To: <ipc...@li...>
>Sent: Friday, April 29, 2005 12:12 AM
>Subject: [IPCop-devel] Build failure on 1.4.5
>
>
>  
>>I downloaded the source tar.gz for 1.4.5, and I get this error trying
>>to build :-
>>Apr 28 22:09:55: Building linux
>>linux    Download:
>>
>>    
>http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27-ssp-1.patch
>  
>http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27-ssp-1.patch:
>  
>>23:09:56 ERROR 404: Not Found.
>>
>>Is there another 'official' location for this file?
>>
>>Regards,
>>Dave
>>
>>
>>    
>with google, you should find
>http://ipcop.ath.cx/
>
>You don't need to care if it is official or not as md5sum of the file is
>checked before compilation.
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Tell us your software development plans!
>Take this survey and enter to win a one-year sub to SourceForge.net
>Plus IDC's 2005 look-ahead and a copy of this survey
>Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
>_______________________________________________
>IPCop-devel mailing list
>IPC...@li...
>https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>
>  
 Is this all you need? I can certainly mail something this small since 
it is only 2.4KB. Let me know if it's ok to email it. I may have to tar 
zip it to keep it as an attachment. I keep at least one backup of my 
cache so I should have everything from the last several months.

Dave

----- Original Message ----- 
From: "Dave Smith" <da...@sm...>
To: <ipc...@li...>
Sent: Friday, April 29, 2005 12:12 AM
Subject: [IPCop-devel] Build failure on 1.4.5


> I downloaded the source tar.gz for 1.4.5, and I get this error trying
> to build :-
> Apr 28 22:09:55: Building linux
> linux    Download:
>
http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27-ssp-1.patch
>
http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27-ssp-1.patch:
> 23:09:56 ERROR 404: Not Found.
>
> Is there another 'official' location for this file?
>
> Regards,
> Dave
>
>
with google, you should find
http://ipcop.ath.cx/

You don't need to care if it is official or not as md5sum of the file is
checked before compilation.

Feature Requests item #1192035, was opened at 2005-04-28 22:39
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=1192035&group_id=40604

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: thedevnull (thedevnull)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL VPN

Initial Comment:
Hello Guys,

  I love IPCOP keep up the good work!  =)  I wondered if 
there is any desire to add a native SSL VPN to IPCOP?

Thanks

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

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

I downloaded the source tar.gz for 1.4.5, and I get this error trying  
to build :-
Apr 28 22:09:55: Building linux
linux    Download:  
http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27- 
ssp-1.patch
http://www.linuxfromscratch.org/patches/downloads/linux/linux-2.4.27- 
ssp-1.patch:
23:09:56 ERROR 404: Not Found.

Is there another 'official' location for this file?

Regards,
Dave

----- Original Message ----- 
From: "Sean Porterfield" <ip...@sp...>
To: <ipc...@li...>
Sent: Thursday, April 28, 2005 8:54 PM
Subject: Re: [IPCop-devel] ipcop 1.4.5 dropping green packets


> > Sean Porterfield wrote:
>
>  >> Each location has a class C subnet in the 10.x.x.x range.  The log
>  >> shows icmp packets dropped when we attempt ping and port 5900 dropped
>  >> when we attempt VNC.
>
> Josh Stompro wrote:
> > Had that same problem myself.  1.4 has more stringent rules, it doesn't
> > like the fact that packets are trying to return through the green
> > interface when they were not sent from the green interface (they were
> > sent from the vpn device).
>
>
> > Search for subjects
> > [IPCop-user] VPN and IPTABLES
> > [IPCop-user] OpenVPN and IPCop all working... nearly!
> > [IPCop-user] VPN - special Route
>
>
> Thanks Josh, that helped a lot.  I guess I didn't search on the correct
> terms when I checked the user list archives.  From what I read there, it
> sounds like this is not considered an IPCop problem because IPCop is
> thought of as a firewall and not a router.  Personally, I've never
> wanted to block green to green traffic.
>
This is not a question of blocking green to green.
But by setting a return path different for your data from the source way,
you broke tcp protocol.
What goes inside through the vpn need to return the same way through the
vpn.


> The rule to RETURN matches tcp traffic but not icmp.  They show in the
> log as OUTPUT on eth0 (green) with icmp type 0.  Is there a way to find
> out which rule is really blocking something?  (And better yet, what is
> the "correct" rule to not block it?)
>
Have you not seen in rc.firewall
 # NEW TCP without SYN
 /sbin/iptables -A BADTCP -p tcp ! --syn -m state --state NEW -j NEWNOTSYN

A solution is described in
http://marc.theaimsgroup.com/?l=ipcop-user&m=110614432906439

Gilles

 > Sean Porterfield wrote:

 >> Each location has a class C subnet in the 10.x.x.x range.  The log
 >> shows icmp packets dropped when we attempt ping and port 5900 dropped
 >> when we attempt VNC.

Josh Stompro wrote:
> Had that same problem myself.  1.4 has more stringent rules, it doesn't 
> like the fact that packets are trying to return through the green 
> interface when they were not sent from the green interface (they were 
> sent from the vpn device).


> Search for subjects
> [IPCop-user] VPN and IPTABLES
> [IPCop-user] OpenVPN and IPCop all working... nearly!
> [IPCop-user] VPN - special Route


Thanks Josh, that helped a lot.  I guess I didn't search on the correct 
terms when I checked the user list archives.  From what I read there, it 
sounds like this is not considered an IPCop problem because IPCop is 
thought of as a firewall and not a router.  Personally, I've never 
wanted to block green to green traffic.

The rule to RETURN matches tcp traffic but not icmp.  They show in the 
log as OUTPUT on eth0 (green) with icmp type 0.  Is there a way to find 
out which rule is really blocking something?  (And better yet, what is 
the "correct" rule to not block it?)

kernel: OUTPUT IN=eth0 OUT=eth0 SRC=10.9.3.3 DST=10.9.1.10 LEN=284 
TOS=0x00 PREC=0x00 TTL=127 ID=58715 PROTO=ICMP TYPE=0 CODE=0

I noticed that running `/etc/rc.d/rc.firewall start` flushes everything 
and reloads the firewall rules but does not load the port forwarding. 
Is there a reason the call to setportfw isn't included in that script?

On Thursday 28 April 2005 00:20, Kim Wall wrote:
> David Smith wrote:
> > Anyone else confirm this bug?  If so, I'll submit it to the BTS.
>
> See the thread "1.4.4 VPN reset bug?" on the ipcop-user list; I have
> encountered this bug on several 1.4.5 installations, and it sounds like
> Praxton has met it too.

Ah, I searched to look for any other postings, but I obviously used
the wrong search terms :-)

Anyway, Franck's fix (http://tinyurl.com/artmo - thanks Franck) seems
to have stopped it giving server errors, although it's not deleting the
connection, so it's still not quite doing "exactly what it says on the tin".

I'll try to investigate further to work out why it's not deleting the 
connection.

David Smith wrote:

> Anyone else confirm this bug?  If so, I'll submit it to the BTS.

See the thread "1.4.4 VPN reset bug?" on the ipcop-user list; I have 
encountered this bug on several 1.4.5 installations, and it sounds like 
Praxton has met it too.


kim.