ipcop-user Mailing List for IPCop Firewall

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Rick,
Allot of info you gave me there!
Do you think I should call my ISP, Comcast?

Demark to Modem:
First, this location is out in the sticks and was lucky comcast decided to
provide service out there... only other option available was satellite (and
dial-up...)  From the Box on the street the cable travels about 300' through
two different barrel connectors to Comcast's box on the side of the building.
~From the inside of the building we have another barrel connector and about
50' of cable (all cable from the demark to cable modem is quad shield RG-6.)

Recent offer of higher speed: Yes and no... they now offer the higher speed to
all customers for the same price.  Previously we were at the basic rate (3.5/.256)
and for a short period of time about a year ago I upped it to (4.5/.328)... but,
didn't notice much of a difference and a month or two later reduced it back to
(3.5/.256).

This system has always been on the cable modem, never any dial-up.  There is
only a cable between the cable modem and the RED interface on IPCop.

I have customized my IPCop, addons server and many of the green addons.
I thought of simply re-installing (and going to 1.4.10 at the same time)
but, I'm worried that my restore disk could possibly carry over the bad
ju-ju.  I just printed out all of my customizations so I can re-enter from
paper.  Do you think I need to reinstall and restore config from paper or disk?

Should I pursue talking with Comcast about these signal issues?
Is there a super superior cable modem that could overcome these signal problems?
And while I'm talking with an expert... what is your favorite cable modem?
They only seem to last me about a year and then pop.  I've had several RCA's...
this is my first Motorola (and the longest survivor yet - about 14 months now.)

Thanks for all your help and knowledge!
Alex.

Rick Kunath wrote:
| Alex McColl wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Rick,
|> thanks for the information and your help!
|>
|> I didn't group reply to the list because I saw your response directly
|> to me -
|> do you care if I cc the list on with the following response (it might be
|> helpful to others?)
|>
|
| Posting to the list is fine. Your reply-to settings may have been set,
| and I didn't catch it. I had intended to post back to the list.
|
|> I didn't even know that I could gain access to my cable modem's
|> error/status
|> page... I have a "Motorola Surf board" and your suggestion got me into
|> it.
|> Pointing my browser at 192.168.100.1 gave me the info you requested:
|> ###
|> Cable Modem Log entries:
|> Time      Priority      Code      Message
|> 060331012445    5-Warning    D103.0    DHCP RENEW WARNING - Field
|> invalid in response
|> 060329224248    3-Critical    R02.0    No Ranging Response received -
|> T3 time-out
|> 060328021031    3-Critical    R04.0    Received Response to Broadcast
|> Maintenance Request, but no Unicast
|> Maintena
|> 060328020959    3-Critical    R02.0    No Ranging Response received -
|> T3 time-out
|> 060226022026    3-Critical    R04.0    Received Response to Broadcast
|> Maintenance Request, but no Unicast
|> Maintena
|> 060226021956    3-Critical    R02.0    No Ranging Response received -
|> T3 time-out
|> 060213024946    3-Critical    R04.0    Received Response to Broadcast
|> Maintenance Request, but no Unicast
|> Maintena
|> 060213024915    3-Critical    R02.0    No Ranging Response received -
|> T3 time-out
|> 060201013853    3-Critical    R04.0    Received Response to Broadcast
|> Maintenance Request, but no Unicast
|> Maintena
|> 060201013818    3-Critical    R02.0    No Ranging Response received -
|> T3 time-out
|> 060125020657    3-Critical    T01.0    SYNC Timing Synchronization
|> failure - Failed to acquire QAM/QPSK
|> symbol tim
|> 060125020657    3-Critical    D01.0    DHCP FAILED - Discover sent, no
|> offer received
|> 060125020654    3-Critical    R04.0    Received Response to Broadcast
|> Maintenance Request, but no Unicast
|> Maintena
|> 060125015851    3-Critical    R02.0    No Ranging Response received -
|> T3 time-out
|> 060125015739    3-Critical    T01.0    SYNC Timing Synchronization
|> failure - Failed to acquire QAM/QPSK
|> symbol tim
|> 060125015739    3-Critical    T04.0    SYNC Timing Synchronization
|> failure - Failed to receive MAC SYNC frame
|> with
|> 060125015735    3-Critical    T01.0    SYNC Timing Synchronization
|> failure - Failed to acquire QAM/QPSK
|> symbol tim
|> 060125015735    3-Critical    T04.0    SYNC Timing Synchronization
|> failure - Failed to receive MAC SYNC frame
|> with
|> 060125015625    3-Critical    T01.0    SYNC Timing Synchronization
|> failure - Failed to acquire QAM/QPSK
|> symbol tim
|> 060125015625    3-Critical    T04.0    SYNC Timing Synchronization
|> failure - Failed to receive MAC SYNC frame
|> with
|> ###
|> Cable Modem Signal information:
|> Frequency      609000000 Hz Locked
|> Signal to Noise Ratio     33 dB
|> QAM     256
|> Network Access Control Object     ON
|> Power Level     -8 dBmV
|> The Downstream Power Level reading is a snapshot taken at the time
|> this page was requested. Please
|> Reload/Refresh this Page for a new reading
|> Upstream     Value
|> Channel ID     7
|> Frequency     25000000 Hz Ranged
|> Ranging Service ID     7568
|> Symbol Rate     3.200 Msym/s
|> Power Level     46 dBmV
|> ###
|>
|
| I haven't seen the time stamps you listed before, so you may want to
| look into how to read them online. BroadBand reports
| (www.dslreports.com) might be a really good resource for this information.
|
| Some of the ranging response failures are normal, but depending on the
| time frame for the list, you are seeing quite a few.
|
| The sync timing issue is a big deal. When you see these, the modem has
| gone off-line and is trying to re-sync and get connected again.
|
| The DHCP failure indicates that the modem can't locate a DHCP server on
| your cable company's network. This later corrected itself after the
| modem synchronized again.
|
| Your Signal-to-Noise ratio is OK, sort of a low average, but OK. The
| downstream power level is on the low end. I'd like to see a +3 or +4 to
| maybe a + 10 dBm here. They are rated to -15 supposedly, but much below
| -5 and you're marginal. You can expect a normal variation during the day
| due to cable company plant gain/loss changes with temperature of as much
| as 6 dBm. So, you're pretty marginal with your -8. The FCC requires no
| lower than 0 dBm for a TV signal to insure proper operation, and most
| all cable companies will come in at the demarc with a +15 dBm signal.
|
| What is the splitter situation on your coaxial cable setup? can you
| describe everything from the demarc to the modem, splitters, etc.?
|
| Your +46 dBm upstream is really worrisome. You are right at the absolute
| edge with your upstream. You'll work with this reading, but won't have
| any headroom for variations on signal levels. I'd be concerned about
| this. Your modem may be online and offline like a yo-yo some days.
|
| I wonder if the cable company has done any plant maintenance of changing
| around that may have made your signals worse at some point? Has your
| cable company recently offered a higher speed tier? I see you are using
| QAM 256 now, so I wonder if your company upgraded from QAM 64 and went
| to the new QAM format recently? This may explain your troubles with your
| marginal signal levels. What cable company was this? (I think you
| mentioned this, but I have forgotten.)
|
|
|> Sorry, I'm a bit lost on the cable modems time stamps for it's log
|> entries:
|> Looks like first two digits are year, then next two are month, next
|> two the
|> day... but, the last 6 I'm not sure of the time (is it the same time
|> zone?
|> hh:mm:ss?)  So, I'm having a little trouble correlating the modem log
|> with
|> my IPCop log... here is my IPCop log for this month:
|> (once again, the errors "Dial Failed: 256" followed by "ERROR: Can't
|> start
|> RED when it's still active" are my kiss of death (about 50% of the
|> time) -
|> 200603280903 was caused by my selecting "connecting debugging" from
|> GUI...
|> the next known independent error, that brought internet access down, was:
|> March 27th at 16:06:31.
|>
|> Time    Section   31/07:35:02    ipcop    NTP synchronisation event
|> 30/19:35:03    ipcop    NTP synchronisation event
|> 30/07:35:02    ipcop    NTP synchronisation event
|> 29/19:35:02    ipcop    NTP synchronisation event
|> 29/07:35:02    ipcop    NTP synchronisation event
|> 28/19:35:01    ipcop    NTP synchronisation event
|> 28/19:33:07    ipcop    dhcpcd success
|> 28/19:33:03    ipcop    Starting RED device eth3.
|> 28/09:03:42    ipcop    Dial failed: 256
|> 28/09:03:42    ipcop    ERROR: Can't start RED when it's still active
|> 28/07:05:02    ipcop    NTP synchronisation event
|> 27/19:48:03    ipcop    DHCP on BLUE: DHCP server enabled. Restarting.
|> 27/19:48:03    ipcop    DHCP on GREEN: DHCP server enabled. Restarting.
|> 27/19:48:03    ipcop    Fixed IP lease removed
|> 27/19:05:03    ipcop    NTP synchronisation event
|> 27/17:58:37    ipcop    dhcpcd success
|> 27/17:58:33    ipcop    Starting RED device eth3.
|> 27/16:06:31    ipcop    Dial failed: 256
|> 27/16:06:31    ipcop    ERROR: Can't start RED when it's still active
|> 27/07:05:02    ipcop    NTP synchronisation event
|> 26/19:05:02    ipcop    NTP synchronisation event
|> 26/07:05:03    ipcop    NTP synchronisation event
|> 26/02:09:01    ipcop    Dynamic DNS ip-update for wile.dyndns.org:
|> success
|> 25/19:05:02    ipcop    NTP synchronisation event
|> 25/07:05:01    ipcop    NTP synchronisation event
|> 24/19:05:02    ipcop    NTP synchronisation event
|> 24/07:05:02    ipcop    NTP synchronisation event
|> 23/19:05:03    ipcop    NTP synchronisation event
|> 23/07:05:03    ipcop    NTP synchronisation event
|> 22/19:05:02    ipcop    NTP synchronisation event
|> 22/07:05:02    ipcop    NTP synchronisation event
|> 22/07:00:04    ipcop    ntpdate error
|> 21/19:13:56    ipcop    Dial failed: 256
|> 21/19:13:56    ipcop    ERROR: Can't start RED when it's still active
|> 21/19:00:05    ipcop    NTP synchronisation event
|> 21/08:56:02    ipcop    Dial failed: 256
|> 21/08:56:02    ipcop    ERROR: Can't start RED when it's still active
|> 21/07:00:01    ipcop    NTP synchronisation event
|> 20/19:00:06    ipcop    NTP synchronisation event
|> 20/18:59:21    ipcop    dhcpcd success
|> 20/18:59:17    ipcop    Starting RED device eth3.
|> 20/08:17:11    ipcop    Dial failed: 256
|> 20/08:17:11    ipcop    ERROR: Can't start RED when it's still active
|> 19/22:10:03    ipcop    NTP synchronisation event
|> 19/10:10:04    ipcop    NTP synchronisation event
|> 19/02:09:00    ipcop    Dynamic DNS ip-update for wile.dyndns.org:
|> success
|> 18/22:10:02    ipcop    NTP synchronisation event
|> 18/10:10:02    ipcop    NTP synchronisation event
|> 17/22:10:03    ipcop    NTP synchronisation event
|> 17/18:58:50    ipcop    Wireless config added
|> 17/18:32:24    ipcop    Dial failed: 256
|> 17/18:32:24    ipcop    ERROR: Can't start RED when it's still active
|> 17/10:10:02    ipcop    NTP synchronisation event
|> 16/22:10:05    ipcop    NTP synchronisation event
|> 16/10:10:02    ipcop    NTP synchronisation event
|> 15/22:10:02    ipcop    NTP synchronisation event
|> 15/18:30:58    ipcop    Dial failed: 256
|> 15/18:30:58    ipcop    ERROR: Can't start RED when it's still active
|> 15/10:10:02    ipcop    NTP synchronisation event
|> 14/22:10:02    ipcop    NTP synchronisation event
|> 14/20:51:54    ipcop    Dial failed: 256
|> 14/20:51:54    ipcop    ERROR: Can't start RED when it's still active
|> 14/10:10:03    ipcop    NTP synchronisation event
|> 13/22:10:02    ipcop    NTP synchronisation event
|> 13/10:10:02    ipcop    NTP synchronisation event
|> 12/22:10:05    ipcop    NTP synchronisation event
|> 12/10:10:02    ipcop    NTP synchronisation event
|> 12/02:09:00    ipcop    Dynamic DNS ip-update for wile.dyndns.org:
|> success
|> 11/22:10:03    ipcop    NTP synchronisation event
|> 11/10:10:02    ipcop    NTP synchronisation event
|> 10/22:10:01    ipcop    NTP synchronisation event
|> 10/10:10:02    ipcop    NTP synchronisation event
|> 09/22:10:02    ipcop    NTP synchronisation event
|> 09/10:10:05    ipcop    NTP synchronisation event
|> 08/22:10:05    ipcop    NTP synchronisation event
|> 08/20:06:04    ipcop    Dial failed: 256
|> 08/20:06:04    ipcop    ERROR: Can't start RED when it's still active
|> 08/10:10:03    ipcop    NTP synchronisation event
|> 07/22:10:02    ipcop    NTP synchronisation event
|> 07/10:10:03    ipcop    NTP synchronisation event
|> 06/22:10:02    ipcop    NTP synchronisation event
|> 06/18:51:42    ipcop    dhcpcd success
|> 06/18:51:38    ipcop    Starting RED device eth3.
|> 06/10:30:41    ipcop    Dial failed: 256
|> 06/10:30:41    ipcop    ERROR: Can't start RED when it's still active
|> 06/10:10:03    ipcop    NTP synchronisation event
|> 05/22:10:01    ipcop    NTP synchronisation event
|> 05/10:10:06    ipcop    NTP synchronisation event
|> 05/02:09:00    ipcop    Dynamic DNS ip-update for wile.dyndns.org:
|> success
|> 04/22:10:02    ipcop    NTP synchronisation event
|> 04/10:10:03    ipcop    NTP synchronisation event
|> 04/09:23:06    ipcop    DHCP on BLUE: DHCP server enabled. Restarting.
|> 04/09:23:06    ipcop    DHCP on GREEN: DHCP server enabled. Restarting.
|> 04/09:19:06    ipcop    DHCP on BLUE: DHCP server enabled. Restarting.
|> 04/09:19:06    ipcop    DHCP on GREEN: DHCP server enabled. Restarting.
|> 04/09:16:30    ipcop    DHCP on BLUE: DHCP server enabled. Restarting.
|> 04/09:16:30    ipcop    DHCP on GREEN: DHCP server enabled. Restarting.
|> 03/22:10:03    ipcop    NTP synchronisation event
|> 03/18:29:27    ipcop    IPCop started.
|> 03/18:29:13    ipcop    dhcpcd success
|> 03/18:29:13    ipcop    Starting RED device eth3.
|> 03/18:27:21    ipcop    Rebooting IPCop
|> 03/18:19:47    ipcop    Wireless config added
|> 03/18:19:19    ipcop    Wireless config added
|> 03/18:18:43    ipcop    Dial failed: 256
|> 03/18:18:43    ipcop    ERROR: Can't start RED when it's still active
|> 03/10:10:02    ipcop    NTP synchronisation event
|> 02/22:18:33    ipcop    Wireless config added
|> 02/22:17:14    ipcop    Dial failed: 256
|> 02/22:17:14    ipcop    ERROR: Can't start RED when it's still active
|> 02/22:10:03    ipcop    NTP synchronisation event
|> 02/22:08:06    ipcop    dhcpcd success
|> 02/22:08:02    ipcop    Starting RED device eth3.
|> 02/09:35:23    ipcop    Dial failed: 256
|> 02/09:35:23    ipcop    ERROR: Can't start RED when it's still active
|> 02/09:35:02    ipcop    NTP synchronisation event
|> 01/21:35:02    ipcop    NTP synchronisation event
|> 01/09:35:02    ipcop    NTP synchronisation event
|>
|> Do you happen to see a correlation?
|> Does my cable modem look happy based on the logs and signal information?
|>
|> I haven't re-installed yet... I was hoping to resolve this without a
|> reinstall.  The system has always been set to receive it's IP via DHCP
|> and has worked great up until about 4 months ago when this started
|> happening.
|> I don't recall changing anything within the last 6 months.
|>
|> I thought these messages were odd, and any message with "Dial" in it,
|> for a system that doesn't have a modem further confused me.
|>
|
| Yes, the dial errors should not be there. Was this system always on the
| cable modem, or did you switch from DSL at some point? Is there any
| piece of equipment in between the cable modem and the IP Cop box WAN
| interface (hub switch, etc.)?
|
| You can do an IP Cop setup without re-installing, but really it's only
| about 5-minutes different than reinstalling from a fresh CD.
|
| I take it that you have some customizations done on the firewall that
| might make a reinstall more work?
|
| I hope that some of this may be of some use, and I do believe that you
| are seeing your cable connection drop regularly. Again, on any of the
| installations I have, IP Cop will automatically re-establish the
| Ethernet connection and sail happily along. There is definitely
| something wrong happening.
|
| Rick Kunath
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFELbPWdQsgobrw7tURAvFYAJ4t2LNKBJ56D6ZJdA75RawSzV54fQCgw/EU
Ppx3LT+SjBOZCqNKiLeHrB0=
=GkMW
-----END PGP SIGNATURE-----

Ben,

I have only needed to change the MTU in anger in the context of VPNs, 
and only changed it for the ipsec interface rather the lan and ipsec 
inerfaces, so suspect you will find that just red will be fine.

HTH

Charlie

Ben Bodenstein wrote:
> Charles,
> Thank you very much. Would you know whether I need to do this on both the 
> red and the green interfaces? I am using a Wireless Broadband modem that 
> needs MTU to be 1352.
> Ben
> 
> ----- Original Message ----- 
> From: "Charles Trevor" <ct....@qg...>
> To: "Ben Bodenstein" <be...@po...>
> Cc: <ipc...@li...>
> Sent: Friday, March 31, 2006 11:08 PM
> Subject: Re: [IPCop-user] How to change MTU size on RED interface
> 
> 
> | Ben,
> |
> | log in via ssh and run 'ifconfig eth1 mtu 1352' with no quotes and
> | assuming you are on a two nic setup you should be done. If not change
> | the eth referenece to match what the network status page says about the
> | interface.
> |
> | Once your happy this does what you need add it to /etc/rc.local and it
> | will be applied on reboot.
> |
> | Above is all from memory, so test first!
> |
> | Charlie
> |
> | Ben Bodenstein wrote:
> | > How do I change the MTU size on the RED interface from 1500 to 1352?
> | > Thanks,
> | > Ben
> | >
> | >
> | > -------------------------------------------------------
> | > This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> | > that extends applications into web and mobile media. Attend the live 
> webcast
> | > and join the prime developer group breaking into this new coding 
> territory!
> | > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> | > _______________________________________________
> | > IPCop-user mailing list
> | > IPC...@li...
> | > https://lists.sourceforge.net/lists/listinfo/ipcop-user
> |
> |
> |
> | __________ NOD32 1.1465 (20060331) Information __________
> |
> | This message was checked by NOD32 antivirus system.
> | http://www.eset.com
> |
> | 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> IPCop-user mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-user

I'd first check that you have ping enabled.  see firewall options.

Then that default gateway is setup correctly.  Varies with what platform =
you are using.

For myself, I get good ping from a box on green to a box on orange, but =
get no response to a ping from that box on orange to the box on green.  I =
can see these packets dropped by doing tail /var/log/messages

I am puzzled.

joea

Ben Bodenstein<be...@po...> wrote on 3/31/2006 3:19 PM:
> After installation of Ipcop 2.4.31, I can not ping in or out of the=20
> green=20
> port.
> Where do I start looking for the problem?
> Thanks,
> Ben=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting=20
> language
> that extends applications into web and mobile media. Attend the live=20
> webcast
> and join the prime developer group breaking into this new coding=20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> =20
> _______________________________________________
> IPCop-user mailing list
> IPC...@li...=20
> https://lists.sourceforge.net/lists/listinfo/ipcop-user

Charles,
Thank you very much. Would you know whether I need to do this on both the 
red and the green interfaces? I am using a Wireless Broadband modem that 
needs MTU to be 1352.
Ben

----- Original Message ----- 
From: "Charles Trevor" <ct....@qg...>
To: "Ben Bodenstein" <be...@po...>
Cc: <ipc...@li...>
Sent: Friday, March 31, 2006 11:08 PM
Subject: Re: [IPCop-user] How to change MTU size on RED interface


| Ben,
|
| log in via ssh and run 'ifconfig eth1 mtu 1352' with no quotes and
| assuming you are on a two nic setup you should be done. If not change
| the eth referenece to match what the network status page says about the
| interface.
|
| Once your happy this does what you need add it to /etc/rc.local and it
| will be applied on reboot.
|
| Above is all from memory, so test first!
|
| Charlie
|
| Ben Bodenstein wrote:
| > How do I change the MTU size on the RED interface from 1500 to 1352?
| > Thanks,
| > Ben
| >
| >
| > -------------------------------------------------------
| > This SF.Net email is sponsored by xPML, a groundbreaking scripting 
language
| > that extends applications into web and mobile media. Attend the live 
webcast
| > and join the prime developer group breaking into this new coding 
territory!
| > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
| > _______________________________________________
| > IPCop-user mailing list
| > IPC...@li...
| > https://lists.sourceforge.net/lists/listinfo/ipcop-user
|
|
|
| __________ NOD32 1.1465 (20060331) Information __________
|
| This message was checked by NOD32 antivirus system.
| http://www.eset.com
|
| 

http://allan.kissack.co.uk/index.php?option=content&task=view&id=55 may help 
(although it uses my graph mod too).  You should be able to see the core 
differences for bits/sec and apply them to standard ipcop graphs

-- 
Allan


----- Original Message ----- 
From: "Franck Horlaville" <fh....@qu...>
To: "ipcop-users user" <ipc...@li...>
Sent: Friday, March 31, 2006 12:49 PM
Subject: [IPCop-user] traffic graphs


> Hi all !
>
> I'd like to have the network graphs in bits/sec instead of bytes. I  know 
> how to do this in MRTG/RRDTool but what would be the "correct"  way to do 
> it in IPCop ?
>
> I wouldn't want to break future updates etc.
>
> Also where could I cleanly add a web user who could visualize these 
> graphs ? I would give out a link to management for example with their  own 
> user and pass allowing them to look at the graphs but not break  anything 
> in the config.
>
> If by this they have access to the whole thing in read-only it  doesn't 
> bother me.
>
> Ideas ?
>
> Thanks !
>
> Franck Horlaville
> IT Manager
> Qualitech
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> IPCop-user mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-user
> 

Rodney Richison wrote:
> Hi,
>
> I appologize as the question is not particulary ipcop's problem. I'm 
> hoping you guys may have somewhat of a similar setup. (If it helps, 
> I'm donating labor here)
> I have a ipcop with cop+ using dansguardian. I drop in to do 
> maintanance on the machines (including windows updates), and none of 
> the machines will do the updates. I finally wipe the ipcop machine and 
> lo and behold, we begin to get updates. However, as soon as I get the 
> cop+ back on to do filtering (is a public library), I can no longer 
> get the updates.
>
> I'm not on the job at this time, but can tell you the exeption rules 
> include the standard windowsupdate.com statements.
>
> This all worked years before, so I'm thinking my question may possibly 
> be, "what has micrsloth changed lately?  :)
>
>
Turn off Cop+, do the updates, then check the proxy logs and see where 
the updates actually came from.  Sounds like they may not be coming from 
where you think.  Either that or you've defined the domain too strictly 
and they're using a subdomain, etc.

Ben Bodenstein wrote:

> How do I change the MTU size on the RED interface from 1500 to 1352?

ip link set dev $RED mtu 1352 (without bringing RED down) or

ifconfig $RED down
ifconfig $RED mtu 1352 up


Cheers,
Sven

Ben,

log in via ssh and run 'ifconfig eth1 mtu 1352' with no quotes and 
assuming you are on a two nic setup you should be done. If not change 
the eth referenece to match what the network status page says about the 
interface.

Once your happy this does what you need add it to /etc/rc.local and it 
will be applied on reboot.

Above is all from memory, so test first!

Charlie

Ben Bodenstein wrote:
> How do I change the MTU size on the RED interface from 1500 to 1352?
> Thanks,
> Ben
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> IPCop-user mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-user

How do I change the MTU size on the RED interface from 1500 to 1352?
Thanks,
Ben

After installation of Ipcop 2.4.31, I can not ping in or out of the green 
port.
Where do I start looking for the problem?
Thanks,
Ben 

you can have multiple openvpn connections to the same endpoint but you 
must specify in each .conf (or ovpn) file

lport 16767 (where 16767 is some unused random port)

and each has to be unique.

Scott Gamble



Darren Davison wrote:
> On Tue, Mar 28, 2006 at 05:28:40PM -0700, Gary Atkinson wrote:
>> Darren
>>
>> Don't see why not.
> 
> well I took a look a the alpha plugin for n2n support, but I still don't see
> how that permits me to make 2 discreet VPN's using the ipcop machine as an
> endpoint for both.. am I missing something?
> 
> 

I'm posting this a second time, I didn't get any responses the first time.

I posted earlier asking how to get updated on my off-site IPCop Dynamic IPs=
,
and was pointed to Dynamic DNS.  I've read about how to do this on both
sides, (IPCop & DynDns.org) and I believe I have it set up correctly, but
I'm not seeing the updated Dynamic IPs when I go to my DynDns.org account.
So here is what I've got.

I created an account w/DynDns.org, the free one.  I set up a Dynamic DNS
host, (dmcfw.dvrdns.org) and modified host with the proper public IP the
IPCop box had at the time.  I then went into my off-site IPCop Dynamic DNS
settings, added the proper info as asked, & clicked the enable box.  Later =
I
did go back and tried the "Force Update" to see if it would update, it
didn't.  Now, here's the setup at the off-site.

The IPCop box handles the SBC DSL connection to the site, the worker uses
Cisco VPN client to connect to the central VPN server and all traffic goes
thru the VPN.  Is this why the Dynamic IP doesn't update?  That the user
does not use the IPBox for DNS services?  From what I've read that seems to
be the problem, but I must admit I'm not fully grasping it.  I hope I
provided enough information.

Thank you in advance for any help.

As Richard said, a second tunnel would be best way to go. I'm not very
familure with IPSec tunnels so I can't help you there. I enjoy hacking
around with routing so that's more of my sort of thing. If someone else
chimes in and get a second tunnel running throw my ideas away.

Assuming you can't create a second tunnel as you said in your first post =
I
would try something like this:

**I'm not sure this would work and I haven't tried it myself**

Our goal is to get traffic from 10.21.0.0/16 to 192.168.1.0/27 via
10.50.0.0/16
Our link between is 10.21.0.0/16 and 10.50.0.0/16 is subnet restricted =
to
10.21.0.0/16 on one side and 10.50.0.0/16 on the otherside. Let's expand
that to 10.50.0.0/15 that gives us access to 10.50.0.0/16 and =
10.51.0.0/16.

Now we need to tell the tunnel that traffic going to 192.168.1.0/27 is =
going
to 10.51.0.0/16 and that traffic coming from 192.168.1.0/27 is coming =
from
10.51.0.0/16.

I believe destination natting 192.168.1.0/27 to 10.51.0.0/27 and
          source natting 10.51.0.0/27 to 192.168.1.0/27 on the local =
IPCop
box
And
          destination natting 10.51.0.0/27 to 192.168.1.0/27 and
          source natting 192.168.1.0/27 to 10.51.0.0/27 on the remote =
IPCop
box
Would do the trick.

I'm using the more restrictive subnet mask. I think this should work =
because
both .0. and .1. fit in 27

Local IPCop box:
iptables -t nat -A PREROUTING -d 192.168.1.0/27 -j DNAT --to-destination
10.51.0.0/27
iptables -t nat -A POSTROUTING -s 10.51.0.0/27 -j SNAT --to-source
192.168.1.0/27

Remote IPCop box:
iptables -t nat -A PREROUTING -d 10.51.0.0/27 -j DNAT --to-destination
192.168.1.0/27
iptables -t nat -A POSTROUTING -s 192.168.1.0/27 -j SNAT --to-source
10.51.0.0/27

If this works I think it should happen before and after (respectively) =
the
IPSec tunnel so it should be allowed to route over the tunnel.

Again, I'm not sure this will work.

Thanks,

David Ruggles
CCNA MCSE (NT) CNA A+
Network Engineer	Safe Data, Inc.
(910) 285-7200	da...@sa...



-----Original Message-----
From: ipc...@li...
[mailto:ipc...@li...] On Behalf Of Andre =
Newman
Sent: Friday, March 31, 2006 10:49 AM
To: ipc...@li...
Subject: RE: [IPCop-user] Help can't configure parallel VPN's


> I'm going to try to diagram what you described:
>
> IPCop Box             IPCop Box
> Local site -> VPN -> remote site -> remote router -> DMZ
> 10.21.0.0/16         10.50.0.0/16                    192.168.1.0/27

That's spot on.

> You can't modify the remote router, but have full control of the two =
IPCop
> Boxen?

I can modify the remote router, I just can't change the 192.168.1.0/27 =
to
something more sensible like 10.51.0.0 :-( The IPCop's are all new, all
mine. :-)

On Friday 31 March 2006 12:23, joea wrote:
> When using the web admin interface, I'd sure like to be able to skip to the
> end of the firewall log.  Paging to the end is a drag.
>
> joea
Under the logs tab>log settings
set chronological order or reverse chronological order :}
-- 
TTFN
   Caparo

Andre Newman wrote:

> The problem is I think that IPSec doesn't allow traffic that's outside of
> the tunnels subnet mask to travel across the tunnel. I either need two
> tunnels or a way to have two subnets on one tunnel.

Andre

As you have worked out IPSec only allows subnet traffic down a tunnel, you
will need two tunnels, one for 10.50.0.0 and one for 192.168.1.0.

This should not be an issue, tunnels are cheap.

--
Regards
	Richard

Hi,

I appologize as the question is not particulary ipcop's problem. I'm 
hoping you guys may have somewhat of a similar setup. (If it helps, I'm 
donating labor here)
I have a ipcop with cop+ using dansguardian. I drop in to do maintanance 
on the machines (including windows updates), and none of the machines 
will do the updates. I finally wipe the ipcop machine and lo and behold, 
we begin to get updates. However, as soon as I get the cop+ back on to 
do filtering (is a public library), I can no longer get the updates.

I'm not on the job at this time, but can tell you the exeption rules 
include the standard windowsupdate.com statements.

This all worked years before, so I'm thinking my question may possibly 
be, "what has micrsloth changed lately?  :)


-- 
Highest Regards,

  

Rodney Richison
RCR Computing
PO Box 566 - 118 N. Broadway
Cleveland, OK 74020
Phone: 918-358-1111

On 31 Mar 2006 at 8:34, Gary Atkinson  wrote:

> On mine is as below, so yes "Advanced".  You will have to stop OpenVPN for the
> button to be selective.

It didn't activate.  I tried several times.

> Even if the logs indicate it has stopped I believe you will still need to stop
> it on the OpenVPN page.

Did that -- perhaps I  need to nuke it, download again, and reinstall.

Angus
--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038
+-----------------------------------+

On Fri, 31 Mar 2006, matthew collins wrote:

> I logged into the web console (http://ipcopserver:81) and then went to=20
> =91System=92 > =91SSH Access=92.  In there I ticked =91SSH Access=92 and =
left everything=20
> as it was; I then tried to connect using Putty (using default putty=20
> settings).  I ended up getting a =91Network Error: Connection refused=92 =
from=20
> within putty after trying to connect.
>
> Is there anything else I need to do in order to get SSH access?
>
   Yes, IPCop's SSH server listenes on port 222, not the standard 22.

--=20
Rick Green

"Those who would give up essential Liberty, to purchase a little=20
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin

I have two IPCop machines, both running 1.4.10.  One performs beautifully, 
and the other is bogged down by a single process 'fetchipac' which runs 
constantly and consumes 99+% of the CPU.
   If I kill the process, it reappears again within minutes.

Investigation has revealed that fetchipac is spawned by makegraphs, which 
is spawned every five minutes by fcron.

On the other machine, the every five minute cron job to update the traffic 
graphs runs so fast that I hardly see it flash by in 'top'.

I've tried killing the offending process.  I've tried rebooting the IPCop 
machine.  This one process comes back and hogs the machine.

  Does anyone know the inner workings of MRTG well enough to prognosticate 
a probable cause for this behaviour, and suggest a method to reinitialize 
that subsystem and get this back on track?  I'm not worried about losing 
historical data, my system and traffic graphs haven't been updated since 
Feb 22nd anyway...

   One possible clue:  If I kill the offending process, then let it get 
restarted by the next cronjob, then the 'Green' traffic graph gets its 
last update timestamp changed, but all data still shows 'nan' where I 
expect numeric values.  THe other interfaces show a timestamp from Feb 
22nd, and old numeric data values.

-- 
Rick Green

"Those who would give up essential Liberty, to purchase a little 
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin

> I'm going to try to diagram what you described:
>
> IPCop Box             IPCop Box
> Local site -> VPN -> remote site -> remote router -> DMZ
> 10.21.0.0/16         10.50.0.0/16                    192.168.1.0/27

That's spot on.

> You can't modify the remote router, but have full control of the two IP=
Cop
> Boxen?

I can modify the remote router, I just can't change the 192.168.1.0/27 to
something more sensible like 10.51.0.0 :-( The IPCop's are all new, all
mine. :-)

> If so, I think the answer would be in routing, you should be able to ro=
ute
> traffic from 10.21.0.0 to 192.168.1.0 via 10.50.0.0 using the existing
> tunnel.

This is already what happens, I've removed a couple of cisco routers
(joined via an expensive 4 ISDN phone calls!) and put two IPCop's in thei=
r
place. The the routing worked fine before the VPN tunnel went in so I kno=
w
it's tunnel related. If I change the tunnel to the 192.168.1 subnet that
starts working instead, change it back and 10.50 works again.

The problem is I think that IPSec doesn't allow traffic that's outside of
the tunnels subnet mask to travel across the tunnel. I either need two
tunnels or a way to have two subnets on one tunnel.

>
> I don't want to start trying to work this out if I'm not correct.

Thanks for trying so far.

Cheers

Andre

> I'm going to try to diagram what you described:
>
> IPCop Box             IPCop Box
> Local site -> VPN -> remote site -> remote router -> DMZ
> 10.21.0.0/16         10.50.0.0/16                    192.168.1.0/27

That's spot on.

> You can't modify the remote router, but have full control of the two IP=
Cop
> Boxen?

I can modify the remote router, I just can't change the 192.168.1.0/27 to
something more sensible like 10.51.0.0 :-( The IPCop's are all new, all
mine. :-)

> If so, I think the answer would be in routing, you should be able to ro=
ute
> traffic from 10.21.0.0 to 192.168.1.0 via 10.50.0.0 using the existing
> tunnel.

This is already what happens, I've removed a couple of cisco routers
(joined via an expensive 4 ISDN phone calls!) and put two IPCop's in thei=
r
place. The the routing worked fine before the VPN tunnel went in so I kno=
w
it's tunnel related. If I change the tunnel to the 192.168.1 subnet that
starts working instead, change it back and 10.50 works again.

The problem is I think that IPSec doesn't allow traffic that's outside of
the tunnels subnet mask to travel across the tunnel. I either need two
tunnels or a way to have two subnets on one tunnel.

>
> I don't want to start trying to work this out if I'm not correct.

Thanks for trying so far.

Cheers

Andre

> I'm going to try to diagram what you described:
>
> IPCop Box             IPCop Box
> Local site -> VPN -> remote site -> remote router -> DMZ
> 10.21.0.0/16         10.50.0.0/16                    192.168.1.0/27

That's spot on.

> You can't modify the remote router, but have full control of the two IP=
Cop
> Boxen?

I can modify the remote router, I just can't change the 192.168.1.0/27 to
something more sensible like 10.51.0.0 :-( The IPCop's are all new, all
mine. :-)

> If so, I think the answer would be in routing, you should be able to ro=
ute
> traffic from 10.21.0.0 to 192.168.1.0 via 10.50.0.0 using the existing
> tunnel.

This is already what happens, I've removed a couple of cisco routers
(joined via an expensive 4 ISDN phone calls!) and put two IPCop's in thei=
r
place. The the routing worked fine before the VPN tunnel went in so I kno=
w
it's tunnel related. If I change the tunnel to the 192.168.1 subnet that
starts working instead, change it back and 10.50 works again.

The problem is I think that IPSec doesn't allow traffic that's outside of
the tunnels subnet mask to travel across the tunnel. I either need two
tunnels or a way to have two subnets on one tunnel.

>
> I don't want to start trying to work this out if I'm not correct.

Thanks for trying so far.

Cheers

Andre

> > I just installed IpCop for the first time and I'm having trouble
> > getting SSH access to the machine.
> >
> > I logged into the web console (http://ipcopserver:81) and
> then went to
> > 'System' > 'SSH Access'. In there I ticked 'SSH Access' and left
> > everything as it was; I then tried to connect using Putty (using
> > default putty settings). I ended up getting a 'Network Error:
> > Connection refused' from within putty after trying to connect.
> >
> > Is there anything else I need to do in order to get SSH access?
> >
> PuTTy is set at the default 22 to start with, you need to
> change it to port 222.

And ... you have to press the "Save" button on the SSH Access screen.  I've
made this mistake myself ;-{

David

On mine is as below, so yes "Advanced".  You will have to stop OpenVPN for
the button
to be selective.

Even if the logs indicate it has stopped I believe you will still need to
stop it on
the OpenVPN page.

Gary

-----Original Message-----
From: Angus Scott-Fleming [mailto:an...@ge...]
Sent: Friday, March 31, 2006 07:55 AM
To: Ipc...@li...
Subject: RE: [IPCop-user] OpenVPN errors: "Connection reset" and server
shuts down


On 30 Mar 2006 at 22:49, Gary Atkinson  wrote:

> Angus
>
> While I was out this evening I had another thought about your situation.
>
> When I first used Zernia the OpenVPN server would not start.

It starts, runs briefly, then shuts down immediately after I try to connect
to
it.

> The way round this was to go into "Advanced Server Option", without making
any
> changes selecting "Save" then starting the server again.
>
> Why this worked I do not know but it did.  If you did not do that, try it.

I don't see an [Advanced Server Option] button.  There is an [Advanced]
button
in the "Global Settings" portion of the screen, but it's inactive on my
system.

A



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
IPCop-user mailing list
IPC...@li...
https://lists.sourceforge.net/lists/listinfo/ipcop-user

On 30 Mar 2006 at 22:49, Gary Atkinson  wrote:

> Angus
> 
> While I was out this evening I had another thought about your situation.
> 
> When I first used Zernia the OpenVPN server would not start.

It starts, runs briefly, then shuts down immediately after I try to connect to 
it.

> The way round this was to go into "Advanced Server Option", without making any
> changes selecting "Save" then starting the server again.
> 
> Why this worked I do not know but it did.  If you did not do that, try it.

I don't see an [Advanced Server Option] button.  There is an [Advanced] button 
in the "Global Settings" portion of the screen, but it's inactive on my system.

A