Great job of posting the pertinent information for debugging, John. To save bandwidth, I've snipped some of the less important stuff in my reply below.
On Sun, 16 Dec 2001 20:38:51 EST John Stoffel wrote: > The first was that I could not port forward SSH to an internal box > with either Eiger or Dach. I had the proper stuff uncommented in > /etc/network.conf, but it just didn't work. I ended up having to do > the following: > > ipchains -I input -i eth0 -j ACCEPT -p tcp -s 0/0 -d 0/0 24 Looks like the problem is you're forwarding port 24 to port 22 (ssh) on 192.168.1.6, but, in the absence of the above rule, you are blocking port 24. More below... > to get the rule early enough in the input chain to be effective. But > I think this is actually too early now, since I'm bypassing some of > the good input rules. Probably so. > My ipchains ruleset looks like this now: > > # ipchains -L input > Chain input (policy DENY): > target prot opt source destination ports > ACCEPT tcp ------ anywhere anywhere any -> 24 [ snip ] > ACCEPT tcp ------ anywhere anywhere any -> ssh [ snip ] Interesting bits pulled up from the network.conf I snipped out below... > EXTERN_TCP_PORTS="0/0_ssh" > INTERN_SSH_SERVER=192.168.1.6 # Internal SSH server to make available > EXTERN_SSH_PORT=24 # External port to use for internal SSH access The "any -> ssh" ACCEPT is created by EXTERN_TCP_PORTS="0/0_ssh" The correct adjustment to your network.conf settings depends on whether or not you run sshd on your firewall and allow connections from external nets. If you do, you probably want EXTERN_TCP_PORTS="0/0_24 0/0_ssh" EXTERN_SSH_PORT=24 If not, you can probably leave EXTERN_TCP_PORTS alone and comment EXTERN_SSH_PORT back out like so: EXTERN_TCP_PORTS="0/0_ssh" # EXTERN_SSH_PORT=24 (Note that you can still ssh to the internal address of the firewall from your internal network even if you forward port 22 on the external interface to an internal host.) > The second problem was that I was getting tons and tons of the > following messages in the /var/log/[messages,kern.log,syslog] files: > > Dec 16 20:42:22 jfsgw kernel: Packet log: input DENY eth0 PROTO=17 10.2.0.1:67 >255.255.255.255:68 L=350 S=0x00 I=22593 F=0x0000 T=255 (#9) > Dec 16 20:42:22 jfsgw kernel: Packet log: input DENY eth0 PROTO=17 10.2.0.1:67 >255.255.255.255:68 L=350 S=0x00 I=22595 F=0x0000 T=255 (#9) > Dec 16 20:42:49 jfsgw kernel: Packet log: input DENY eth0 PROTO=2 >192.168.100.1:65535 224.0.0.1:65535 L=28 S=0xC0 I=0 F=0x0000 T=1 (#11) > Dec 16 20:44:22 jfsgw kernel: Packet log: input DENY eth0 PROTO=17 10.2.0.1:67 >255.255.255.255:68 L=344 S=0x00 I=22697 F=0x0000 T=255 (#9) > Dec 16 20:44:30 jfsgw kernel: Packet log: input DENY eth0 PROTO=17 10.2.0.1:67 >255.255.255.255:68 L=344 S=0x00 I=22700 F=0x0000 T=255 (#9) > > Even though I had the settings to turn off the logging of martians. I I'm guessing here, but I'd bet the *IP_KRNL_LOGMARTIANS flags that I assume you're referring to only affect if the kernel spits out messages like so: Aug 17 12:49:35 systenrouter kernel: ll header: ff ff ff ff ff ff 00 50 ba b5 27 04 08 00 Aug 17 12:49:36 systenrouter kernel: martian source abcdef01 for abcdefff, dev eth1 when a packet that arrives on an interface destined for an address, broadcast or otherwise, the interface in question isn't supposed to serve. Since the five packets above are broadcast to everyone using 255.255.255.255 and 224.0.0.1, the kernel isn't really surprised to see them hitting eth0. They may not even be considered martians. (Someone who's more familiar with martians, please step in and correct me if necessary.) > ended up changing the /etc/ipfilters.conf file so that in the > 'stopMartians' function, I didn't bother to log packets for the RFC > 1918, 1627 and 1597 blocks. I just removed the '-l' flag from those > three lines, saved /etc o floppy and rebooted. You could probably achieve the same effect by adjusting the value of the SILENT_DENY variable in /etc/network.conf . [ remaining statements and questions snipped since they're *much* more in Charles' ballpark ] Hope that helps show ways you can use network.conf to achieve some of the things you did manually with ipchains. --Brad _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
