Hello, i'm using suse 7.3 as a router for a privat network. Filtering and masquerading is done by firewall2. Connection to the internet is done by rp-pppoe. After booting, everything works out fine, but when i get a new IP (/usr/sbin/adsl-stop /usr/sbin/adsl-start), the Firewall2 seems to block the whole linux-mashine (not even ping to an IP). The Firewall-log shows (for example): Mar 18 10:20:57 linux kernel: SuSE-FW-UNALLOWED-TARGETIN=ppp0 OUT= MAC= SRC=193.189.244.205 DST=213.20.25.63 LEN=76 TOS=0x00 PREC=0x 00 TTL=247 ID=50701 PROTO=UDP SPT=53 DPT=1031 LEN=56 The router-funktion works out fine though. All Clients in my private Network can reach the Internet as usual. When i restart the Firewall, all problems are gone. This looks to me like a Firewall-configuration-problem. Any ideas what to do?? Should i ad any CUSTOMRULES? Thanks for reading so far! pierre Here is my firewall2.rc.config: FW_DEV_EXT="ppp0" FW_DEV_INT="eth1" FW_DEV_DMZ="" FW_ROUTE="yes" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="192.168.1.0/24" FW_PROTECT_FROM_INTERNAL="no" FW_AUTOPROTECT_SERVICES="no" FW_SERVICES_EXT_TCP="www ftp ssh 3756" FW_SERVICES_EXT_UDP="domain" FW_SERVICES_EXT_IP="" FW_SERVICES_DMZ_TCP="" FW_SERVICES_DMZ_UDP="" FW_SERVICES_DMZ_IP="" FW_SERVICES_INT_TCP="www ftp domain ssh 139" FW_SERVICES_INT_UDP="domain" FW_SERVICES_INT_IP="" FW_TRUSTED_NETS="" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" FW_SERVICE_AUTODETECT="yes" FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="no" FW_SERVICE_DHCPD="no" FW_SERVICE_SQUID="no" FW_SERVICE_SAMBA="yes" FW_FORWARD="" FW_FORWARD_MASQ="" FW_REDIRECT="" FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="no" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW" FW_KERNEL_SECURITY="no" FW_STOP_KEEP_ROUTING_STATE="no" FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="no" FW_ALLOW_PING_EXT="yes" FW_ALLOW_ FW_TRACEROUTE="yes" FW_ALLOW_ FW_SOURCEQUENCH="yes" FW_ALLOW_ FW_BROADCAST="no" FW_IGNORE_ FW_BROADCAST="yes" FW_ALLOW_CLASS_ROUTING="no"
Hi, SuSEfirewall2 needs to be restarted after you got a new IP address. I usually start it in the ip-up script (kernel pppoe). You probably want to put it at the end of your adsl-start script. Robert
i'm using suse 7.3 as a router for a privat network. Filtering and masquerading is done by firewall2. Connection to the internet is done by rp-pppoe. After booting, everything works out fine, but when i get a new IP (/usr/sbin/adsl-stop /usr/sbin/adsl-start), the Firewall2 seems to block the whole linux-mashine (not even ping to an IP). The Firewall-log shows (for example):
Mar 18 10:20:57 linux kernel: SuSE-FW-UNALLOWED-TARGETIN=ppp0 OUT= MAC= SRC=193.189.244.205 DST=213.20.25.63 LEN=76 TOS=0x00 PREC=0x 00 TTL=247 ID=50701 PROTO=UDP SPT=53 DPT=1031 LEN=56
The router-funktion works out fine though. All Clients in my private Network can reach the Internet as usual. When i restart the Firewall, all problems are gone. This looks to me like a Firewall-configuration-problem. Any ideas what to do?? Should i ad any CUSTOMRULES?
Thanks for reading so far!
pierre
Here is my firewall2.rc.config:
FW_DEV_EXT="ppp0" FW_DEV_INT="eth1" FW_DEV_DMZ="" FW_ROUTE="yes" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="192.168.1.0/24" FW_PROTECT_FROM_INTERNAL="no" FW_AUTOPROTECT_SERVICES="no" FW_SERVICES_EXT_TCP="www ftp ssh 3756" FW_SERVICES_EXT_UDP="domain" FW_SERVICES_EXT_IP="" FW_SERVICES_DMZ_TCP="" FW_SERVICES_DMZ_UDP="" FW_SERVICES_DMZ_IP="" FW_SERVICES_INT_TCP="www ftp domain ssh 139" FW_SERVICES_INT_UDP="domain" FW_SERVICES_INT_IP="" FW_TRUSTED_NETS="" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" FW_SERVICE_AUTODETECT="yes" FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="no" FW_SERVICE_DHCPD="no" FW_SERVICE_SQUID="no" FW_SERVICE_SAMBA="yes" FW_FORWARD="" FW_FORWARD_MASQ="" FW_REDIRECT="" FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="no" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW" FW_KERNEL_SECURITY="no" FW_STOP_KEEP_ROUTING_STATE="no" FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="no" FW_ALLOW_PING_EXT="yes" FW_ALLOW_ FW_TRACEROUTE="yes" FW_ALLOW_ FW_SOURCEQUENCH="yes" FW_ALLOW_ FW_BROADCAST="no" FW_IGNORE_ FW_BROADCAST="yes" FW_ALLOW_CLASS_ROUTING="no"
* Robert Klein wrote on Tue, Mar 19, 2002 at 08:32 +0100:
SuSEfirewall2 needs to be restarted after you got a new IP address. I usually start it in the ip-up script (kernel pppoe).
Hum, and again. Can someone explain any need for this restarting hack, please? I don't see why you shouldn't say accept incoming packets on ppp0 for any IP, so it doesn't matter what IP you have there. Especially on peer-to-peer devices you will get the packets dedicated for you routed only. Even if you would get the wrong packets, the pppd would drop them. And then you can enable rp_filter. And if you really want to drop packets arriving on ppp0 and not matching your IP, you can make a new chain for that and just rewrite a single rule, but I don't see any need for it. If your ip-up accepts any IP the peer assigns, which is usually the way it goes, why adapting the firewall? Either you trust the peer to assign you correct IPs or don't trust (and don't use at all). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Steffen Dettmer wrote:
* Robert Klein wrote on Tue, Mar 19, 2002 at 08:32 +0100:
SuSEfirewall2 needs to be restarted after you got a new IP address. I usually start it in the ip-up script (kernel pppoe).
Hum, and again. Can someone explain any need for this restarting hack, please?
two reasons. First, ipsec likes rp_filter to be 0 (don't ask me on details, here). Second, it's easier for the novice user (than rp_filter). Of course, you might want to ask SuSE, why they don't try to use rp_filter in their firewall script... Robert
I don't see why you shouldn't say accept incoming packets on ppp0 for any IP, so it doesn't matter what IP you have there. Especially on peer-to-peer devices you will get the packets dedicated for you routed only. Even if you would get the wrong packets, the pppd would drop them. And then you can enable rp_filter.
And if you really want to drop packets arriving on ppp0 and not matching your IP, you can make a new chain for that and just rewrite a single rule, but I don't see any need for it. If your ip-up accepts any IP the peer assigns, which is usually the way it goes, why adapting the firewall? Either you trust the peer to assign you correct IPs or don't trust (and don't use at all).
* Robert Klein wrote on Tue, Mar 19, 2002 at 11:49 +0100:
Steffen Dettmer wrote:
Hum, and again. Can someone explain any need for this restarting hack, please?
two reasons. First, ipsec likes rp_filter to be 0 (don't ask me on details, here).
I've read it, but don't know why, well, and at least on the GWs I used it's active without problems (so far :)).
Second, it's easier for the novice user (than rp_filter).
Do you really think it's easier to mess up with hacking ip-scripts, thing about concurrency issues and such than have a more simple configuration?! Well, and it's annoying if the first DNS packets get dropped on dialup I think, this can really delay the things a lot.
Of course, you might want to ask SuSE, why they don't try to use rp_filter in their firewall script...
What should happen when a packet with the wrong dest IP arrives? Either it is for a blocked port and get blocked anyway, or it's for an allowed port and doesn't get even processed by the kernel! I don't see any advantages to have a single IP dialup router that filters or rp_filters IPs on the peer to peer device. So I would recommend to specify the IP of the peer to peer devices as 0/0 and filter port-based, as firewalls usually do also, and don't get in trouble with restarting firewalls dynamically. [... Fullquote cut ...] oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (3)
-
Pierre Naels -
Robert Klein -
Steffen Dettmer