suse firewall - Mar 1 15:02:03 bigapple kernel: Packet log: output DENY ppp0 PROTO=1 195.186.133.129:3 195.132.143.170:3 L=88 S=0xC0 I=42977 F=0x0000 T=255 (#3)
Hello, Little thing probably, but I've not managed to solve it yet, reading ipchains docs. I have DSL and I am using pppoed. I installed a minimal susefirewall set of rules, and everything seems to work nicely. Just a little thing: when I try to connect to external hosts via ssh, I get about 3-4 such lines in my logs, and it takes really long to connect (5-10 seconds) : Mar 1 14:58:49 bigapple kernel: Packet log: output DENY ppp0 PROTO=1 195.186.133.129:3 195.186.1.111:3 L=214 S=0xC0 I=42750 F=0x0000 T=255 (#3) Mar 1 15:01:21 bigapple kernel: Packet log: output DENY ppp0 PROTO=1 195.186.133.129:3 195.139.143.170:3 L=88 S=0xC0 I=42872 F=0x0000 T=255 (#3) The funny thing is that when I connect to an old suse server (suse 6.x), it works directely. So that must be something with openssh/old-ssh. Any idea of what I could change to allow these icpm packets to come in ? Tried a few things, but not yet found the right line to comment. Regards & Thanks, Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
Hi,
I have DSL and I am using pppoed. I installed a minimal susefirewall set of rules, and everything seems to work nicely.
Just a little thing: when I try to connect to external hosts via ssh, I get about 3-4 such lines in my logs, and it takes really long to connect (5-10 seconds) :
Mar 1 14:58:49 bigapple kernel: Packet log: output DENY ppp0 PROTO=1 195.186.133.129:3 195.186.1.111:3 L=214 S=0xC0 I=42750 F=0x0000 T=255 (#3) Mar 1 15:01:21 bigapple kernel: Packet log: output DENY ppp0 PROTO=1 195.186.133.129:3 195.139.143.170:3 L=88 S=0xC0 I=42872 F=0x0000 T=255 (#3)
Maybe you should not block outgoing ICMP destination-unreachable packets (ICMP type 3). They are used, besides other things, for MTU discovery. Blocking these packets leads to MTU not being reduced and network performance detereorating to extremely poor levels. I suggest you re-read the ipchains-Howto (in /usr/share/doc/packages/ipchains). It's discussed there in section 5.
The funny thing is that when I connect to an old suse server (suse 6.x), it works directely. So that must be something with openssh/old-ssh.
Any idea of what I could change to allow these icpm packets to come in ?
The last item in your log entries (#3) should indicate the offending rule. It's rule no. 3 in your output chain.
Regards & Thanks, Olivier
Regards, Martin -- Martin Leweling Institut fuer Planetologie, WWU Muenster Wilhelm-Klemm-Str. 10, 48149 Muenster, Germany E-Mail (work): lewelin@uni-muenster.de
On Thu, Mar 01, 2001 at 03:57:25PM +0100, Martin Leweling wrote:
Any idea of what I could change to allow these icpm packets to come in ?
The last item in your log entries (#3) should indicate the offending rule. It's rule no. 3 in your output chain.
I know that :) But this is the original susefirewall script, and I don't see which one it is. If I see correctely, it's one of the first chains, the one with DENY everything... Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
Hello Olivier, On Thursday 01 March 2001 16:22, Olivier Mueller wrote:
On Thu, Mar 01, 2001 at 03:57:25PM +0100, Martin Leweling wrote:
Any idea of what I could change to allow these icpm packets to come in ?
The last item in your log entries (#3) should indicate the offending rule. It's rule no. 3 in your output chain.
I know that :) But this is the original susefirewall script, and I don't see which one it is. If I see correctely, it's one of the first chains, the one with DENY everything...
Ah, I see ... Well, I think I found it in /sbin/SuSEfirewall: look for the following lines (I have SuSE 7.0 here, so I don't know about changes in SuSE 7.1): -------------------------------------------------------- for i in $DEV_WORLD; do .... test "$FW_ALLOW_FW_TRACEROUTE" = yes || { $IPCHAINS -A output -j "$DENY" -p icmp -s $i 11 $LDC # Time exceeded $IPCHAINS -A output -j "$DENY" -p icmp -s $i 3 $LDC # Unreachable } done -------------------------------------------------------- So the FW_ALLOW_FW_TRACEROUTE variable is set to yes in /etc/rc.config.d/firewall.rc.config. Ha! It's in the "expert section". You knew what you were doing, now didn't you ... ;-) Ok, forgive me ... ;-) You could either set it to "no" or uncomment the second $IPCHAINS line above and see what happens when you restart your firewall. Hope this helps ...
Olivier
Regards, Martin -- Martin Leweling Institut fuer Planetologie, WWU Muenster Wilhelm-Klemm-Str. 10, 48149 Muenster, Germany E-Mail (work): lewelin@uni-muenster.de
Ooops, small diff to my previous posting:
You could either set it to "no" or uncomment the second $IPCHAINS line above and see what happens when you restart your firewall.
That should read "comment out", not "uncomment" ... sigh ... Regards, Martin -- Martin Leweling Institut fuer Planetologie, WWU Muenster Wilhelm-Klemm-Str. 10, 48149 Muenster, Germany E-Mail (work): lewelin@uni-muenster.de
On Thu, Mar 01, 2001 at 05:15:17PM +0100, Martin Leweling wrote:
So the FW_ALLOW_FW_TRACEROUTE variable is set to yes in /etc/rc.config.d/firewall.rc.config. Ha! It's in the "expert section". You knew what you were doing, now didn't you ... ;-)
:)) ok, with this variable set on yes, there are no warning anymore in the logs, but it take as much long time to connect : if turn off the firewall, it takes less than one second, and with the firewall on, about 5 to 10 sec.
Hope this helps ...
yes, thanks, we're on the right way :) Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
participants (2)
-
Martin Leweling -
Olivier Mueller