IPCOP Behaving Badly

Hi Guys

Got a bit of a problem with an IPCOP box that I cant seem to work out.

Currently the box is running at a remote site (cant physically get to it at the moment) but I can remotely log in via https and ssh.

The box is not allowing any traffic out to the router, even SYSTEM - UPDATES - REFRESH SYSTEM UPDATES wont work

Everything appears to be fine, it just stopped working a few hours ago I have rebooted, but the problem remains.

Any ideas? maybe someone could point me in the direction of some kind of "event logs" (Sorry im still a bit of a newbie to this :oops:

Thanks

J

PS> Found lots of these in the Kernal Log:

INPUT IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:14:bf:02:97:eb:08:00 SRC=192.168.8.1 DST=192.168.8.255 LEN=153 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=2850 DPT=162 LEN=133

any help?

From the bit of the kernel log you posted, it appears that the IPCOP is behind a NAT router.(this assumes that eth1 is the RED interface, otherwise my statement is totally wrong!!) My guess is that it's a UDP broadcast from your router's internal interface (192.168.8.1).

You mentioned that you access the IPCOP remotely via https and ssh. Are able to do that even with the current problems? I need to clarify this in order to proceed.

Also, can users behind the IPCOP:
1. Access the IPCOP GUI
2. Access the Web (HTTP)
3. Ping the IPCOP green IP
4. Ping the router's internal IP
5. Ping a public IP.

Hi DaLight

Thanks for the responce

This problem is very wierd!?!

I faffed around remotely until the bugger died completely and I couldnt acccess it any more. I built a new box and installed it the next day, When I plugged this one in, I got the same problems, could not access http, however, I could ping IP addresses (exactly the same config as the previous box which worked fine when installed for about 3 hrs)

Checked the DNS setting which were set to the routers IP address (Always worked before) Changed to 195.92.195.94 (Wanadoo) now works fine!?!?!?!

Only thing is now im getting loads of these in the firewall log:

13:33:25 INPUT eth1 UDP 192.168.8.1
2844 00:14:bf:02:97:eb 192.168.8.255
162(SNMPTRAP)

Any ideas?

again, thanks for the help

J

Checked the DNS setting which were set to the routers IP address (Always worked before) Changed to 195.92.195.94 (Wanadoo) now works fine!?!?!?!

The DNS forwarder on your router must not be working for some reason or the DNS IPs that have been configured in your router may not be valid. You could take a look at the router's DNS settings to investigate further.
This explains why you could access the location remotely, while local users did not have web access (due to lack of a functioning DNS)

Only thing is now im getting loads of these in the firewall log:

13:33:25 INPUT eth1 UDP 192.168.8.1
2844 00:14:bf:02:97:eb 192.168.8.255
162(SNMPTRAP)

The router (192.168.8.1) probably has SNMP enabled and is sending SNMP broadcasts out to be trapped by an SNMP manager. To stop this, simply disable SNMP on your router.

Hi DaLight

Again, thanks for the responce.

The DNS was set to automatically detect from ISP, probably a service outage :oops:

The wierd thing about the SNMP is I checked that initially, and it is disabled; cant think why its still broadcasting, probably because its a cisco wannabe (linksys) :lol:

Never mind, will just have to put up with miles and miles of useless logs or put in a "proper" router

Cheers

J

If you're really bothered about your logs filling up, and you can't find a way to stop the SNMP broadcasts, you could add iptables rules to silently drop the packets. You will need to make changes to the rc.local file which is located in the following directory /etc/rc.d/ on your IPCOP. Add the following commands after the line containing "#!/bin/sh"
[code:1]
# Flush Custom Input Rules
/sbin/iptables -F CUSTOMINPUT

#drop SNMP packets
/sbin/iptables -A CUSTOMINPUT -i $RED_DEV -p udp --dport 162 -j DROP
[/code:1]
The above code assumes there is no other code in your rc.local file apart from the first line "#!/bin/sh".
It silently drops any UDP packets destined for port 162 on your IPCOP's RED interface.
After editing rc.local, you can immediately activate the new rule by typing "/etc/rc.d/rc.local".