another 3-interface firewall problem (two external, no DMZ)
Hi, I am running a small enterprise server under Suse 9.0. The main tasks are: Masquerading an internal network, SMTP, POP3 and web serving. Everything works nice with two interfaces: eth0: 1.2.3.4 netmask 255.255.255.192 (leased line with static IP) eth1: 192.168.0.1 netmask 255.255.255.0 (internal network) with default route 1.2.3.3 Web server is listening on 1.2.3.4, SMTP on both interfaces, POP3 only at the internal interface NOW: to keep traffic costs as low as possible, we like to route the main traffic over a DSL flat rate. Configuring the DSL stuff gives the aditional ppp0 interface (PPPoE with eth2), masquerading works and I can see the web server at 1.2.3.4 due to the additional entry: iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 1.2.3.4 -j ACCEPT BUT: The address 1.2.3.4 is not responding from the outside any more. Both eth0 and ppp0 are configured as external interfaces in the SuSEfirewall configuration. I think, the problem can be seen as a sort of load balancing for the leaving IP packets. Any hints, how to get the official external IP address working again ? Best regards Peter
You could check the following: 1) Is the routing ok ? 2) Are there any firewall log entries ? 3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs) You could get more info by tcpdumping your interfaces. Andreas On Sunday 04 January 2004 00:00, Dr. Peter M�nstermann wrote:
Hi,
I am running a small enterprise server under Suse 9.0. The main tasks are: Masquerading an internal network, SMTP, POP3 and web serving.
Everything works nice with two interfaces: eth0: 1.2.3.4 netmask 255.255.255.192 (leased line with static IP) eth1: 192.168.0.1 netmask 255.255.255.0 (internal network) with default route 1.2.3.3 Web server is listening on 1.2.3.4, SMTP on both interfaces, POP3 only at the internal interface
NOW: to keep traffic costs as low as possible, we like to route the main traffic over a DSL flat rate. Configuring the DSL stuff gives the aditional ppp0 interface (PPPoE with eth2), masquerading works and I can see the web server at 1.2.3.4 due to the additional entry: iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 1.2.3.4 -j ACCEPT
BUT: The address 1.2.3.4 is not responding from the outside any more. Both eth0 and ppp0 are configured as external interfaces in the SuSEfirewall configuration.
I think, the problem can be seen as a sort of load balancing for the leaving IP packets.
Any hints, how to get the official external IP address working again ?
Best regards Peter
Hi Again,
1) Is the routing ok ? How can I check the routing ? The SuSEfirewall-Script generates more rules than G.W. bushisms.
2) Are there any firewall log entries ? Nothing critical for the 'dead' Interface. But I have to retry with logging everything.
3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs) I am completely unshure about everything! I guess, everything should be clear by understanding the IP rules. Is there a debugging tool for this ?
Thanks so far Peter ___________________________________________________________ Dr. Peter Münstermann mobil: +49 (0)173/2309398 Schützenstr. 11 tel.: +49 (0)7531/919122 D-78462 Konstanz fax.: +49 (0)7531/914370 ___________________________________________________________
Von: Andreas Baetz
Datum: Mon, 5 Jan 2004 09:01:10 +0100 An: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (two external, no DMZ) You could check the following: 1) Is the routing ok ? 2) Are there any firewall log entries ? 3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs)
You could get more info by tcpdumping your interfaces.
Andreas
On Sunday 04 January 2004 00:00, Dr. Peter M?nstermann wrote:
Hi,
I am running a small enterprise server under Suse 9.0. The main tasks are: Masquerading an internal network, SMTP, POP3 and web serving.
Everything works nice with two interfaces: eth0: 1.2.3.4 netmask 255.255.255.192 (leased line with static IP) eth1: 192.168.0.1 netmask 255.255.255.0 (internal network) with default route 1.2.3.3 Web server is listening on 1.2.3.4, SMTP on both interfaces, POP3 only at the internal interface
NOW: to keep traffic costs as low as possible, we like to route the main traffic over a DSL flat rate. Configuring the DSL stuff gives the aditional ppp0 interface (PPPoE with eth2), masquerading works and I can see the web server at 1.2.3.4 due to the additional entry: iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 1.2.3.4 -j ACCEPT
BUT: The address 1.2.3.4 is not responding from the outside any more. Both eth0 and ppp0 are configured as external interfaces in the SuSEfirewall configuration.
I think, the problem can be seen as a sort of load balancing for the leaving IP packets.
Any hints, how to get the official external IP address working again ?
Best regards Peter
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Tue, 6 Jan 2004, Dr. Peter M[ISO-8859-1] ünstermann wrote:
Hi Again,
1) Is the routing ok ? How can I check the routing ?
route -n
The SuSEfirewall-Script generates more rules than G.W. bushisms.
sometimes i use :: iptables -vnL | grep -v "^ *0 " to see rules that have a hit count other 0.
2) Are there any firewall log entries ? Nothing critical for the 'dead' Interface. But I have to retry with logging everything.
3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs) I am completely unshure about everything! I guess, everything should be clear by understanding the IP rules. Is there a debugging tool for this ?
Thanks so far
Peter
___________________________________________________________
Dr. Peter Münstermann
mobil: +49 (0)173/2309398 Schützenstr. 11 tel.: +49 (0)7531/919122 D-78462 Konstanz fax.: +49 (0)7531/914370 ___________________________________________________________
Von: Andreas Baetz
Datum: Mon, 5 Jan 2004 09:01:10 +0100 An: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (two external, no DMZ) You could check the following: 1) Is the routing ok ? 2) Are there any firewall log entries ? 3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs)
You could get more info by tcpdumping your interfaces.
Andreas
On Sunday 04 January 2004 00:00, Dr. Peter M?nstermann wrote:
Hi,
I am running a small enterprise server under Suse 9.0. The main tasks are: Masquerading an internal network, SMTP, POP3 and web serving.
Everything works nice with two interfaces: eth0: 1.2.3.4 netmask 255.255.255.192 (leased line with static IP) eth1: 192.168.0.1 netmask 255.255.255.0 (internal network) with default route 1.2.3.3 Web server is listening on 1.2.3.4, SMTP on both interfaces, POP3 only at the internal interface
NOW: to keep traffic costs as low as possible, we like to route the main traffic over a DSL flat rate. Configuring the DSL stuff gives the aditional ppp0 interface (PPPoE with eth2), masquerading works and I can see the web server at 1.2.3.4 due to the additional entry: iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 1.2.3.4 -j ACCEPT
BUT: The address 1.2.3.4 is not responding from the outside any more. Both eth0 and ppp0 are configured as external interfaces in the SuSEfirewall configuration.
I think, the problem can be seen as a sort of load balancing for the leaving IP packets.
any martians in the log ? what is the default route now ? -- BINGO: high-performance breakthrough --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+
Sorry for the routing test. The output of the route command seems to be okay. Something like Destination Gateway Genmask Flags Metric Ref Use Iface w.x.y.z 0.0.0.0 255.255.255.0 U 0 0 0 ppp0 external 0.0.0.0 255.255.255.252 U 0 0 0 eth0 internal 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 w.y.x.z+1 0.0.0.0 UG 0 0 0 ppp0 gedenktage:/var/home/muenster # At the moment, I run the expensive two interface solution. I will test the IP-tables as soon as possible. YoYo Peter
Von: engelbert.gruber@ssg.co.at Datum: Tue, 6 Jan 2004 17:15:32 +0100 (CET) An: "Dr. Peter Münstermann"
Cc: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (two external, no DMZ) On Tue, 6 Jan 2004, Dr. Peter M[ISO-8859-1] ünstermann wrote:
Hi Again,
1) Is the routing ok ? How can I check the routing ?
route -n
The SuSEfirewall-Script generates more rules than G.W. bushisms.
sometimes i use ::
iptables -vnL | grep -v "^ *0 "
to see rules that have a hit count other 0.
2) Are there any firewall log entries ? Nothing critical for the 'dead' Interface. But I have to retry with logging everything.
3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs) I am completely unshure about everything! I guess, everything should be clear by understanding the IP rules. Is there a debugging tool for this ?
Thanks so far
Peter
___________________________________________________________
Dr. Peter Münstermann
mobil: +49 (0)173/2309398 Schützenstr. 11 tel.: +49 (0)7531/919122 D-78462 Konstanz fax.: +49 (0)7531/914370 ___________________________________________________________
Von: Andreas Baetz
Datum: Mon, 5 Jan 2004 09:01:10 +0100 An: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (two external, no DMZ) You could check the following: 1) Is the routing ok ? 2) Are there any firewall log entries ? 3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs)
You could get more info by tcpdumping your interfaces.
Andreas
On Sunday 04 January 2004 00:00, Dr. Peter M?nstermann wrote:
Hi,
I am running a small enterprise server under Suse 9.0. The main tasks are: Masquerading an internal network, SMTP, POP3 and web serving.
Everything works nice with two interfaces: eth0: 1.2.3.4 netmask 255.255.255.192 (leased line with static IP) eth1: 192.168.0.1 netmask 255.255.255.0 (internal network) with default route 1.2.3.3 Web server is listening on 1.2.3.4, SMTP on both interfaces, POP3 only at the internal interface
NOW: to keep traffic costs as low as possible, we like to route the main traffic over a DSL flat rate. Configuring the DSL stuff gives the aditional ppp0 interface (PPPoE with eth2), masquerading works and I can see the web server at 1.2.3.4 due to the additional entry: iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 1.2.3.4 -j ACCEPT
BUT: The address 1.2.3.4 is not responding from the outside any more. Both eth0 and ppp0 are configured as external interfaces in the SuSEfirewall configuration.
I think, the problem can be seen as a sort of load balancing for the leaving IP packets.
any martians in the log ?
what is the default route now ?
-- BINGO: high-performance breakthrough --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Sorry forgot the first line with ppp0 in my mail! Destination Gateway Genmask Flags Metric Ref Use Iface w.x.y.z 0.0.0.0 255.255.255.0 U 0 0 0 ppp0 external 0.0.0.0 255.255.255.252 U 0 0 0 eth0 internal 0.0.0.0 255.255.255.0 U 0 0 0 eth1 The last line i default-gw of your provider, so it has to be set correct, but that seems to bo done by pppup-srcipt. 0.0.0.0 w.y.x.z+1 0.0.0.0 UG 0 0 0 ppp0 But you got internet, so default-gw seems to be set correct. Try unload firewall and a traceroute to an external ip and a ping to an external ip. If that works routing is o.k. Philippe
Hello Peter, possibly the problem is a complete different. Recently i had problems with a router using identical nics, i. e. 3* 3com905. It seems that the router mixed up the interfaces. Perhaps you may try it with differrent nics. Best regards Christian
-----Ursprüngliche Nachricht----- Von: Dr. Peter Münstermann [mailto:peter@deike-muenstermann.de] Gesendet: Dienstag, 6. Januar 2004 21:38 An: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (twoexternal, no DMZ)
Sorry for the routing test.
The output of the route command seems to be okay. Something like
Destination Gateway Genmask Flags Metric Ref Use Iface w.x.y.z 0.0.0.0 255.255.255.0 U 0 0 0 ppp0 external 0.0.0.0 255.255.255.252 U 0 0 0 eth0 internal 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 w.y.x.z+1 0.0.0.0 UG 0 0 0 ppp0 gedenktage:/var/home/muenster #
At the moment, I run the expensive two interface solution. I will test the IP-tables as soon as possible.
YoYo Peter
Von: engelbert.gruber@ssg.co.at Datum: Tue, 6 Jan 2004 17:15:32 +0100 (CET) An: "Dr. Peter Münstermann"
Cc: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (two external, no DMZ) On Tue, 6 Jan 2004, Dr. Peter M[ISO-8859-1] ünstermann wrote:
Hi Again,
1) Is the routing ok ? How can I check the routing ?
route -n
The SuSEfirewall-Script generates more rules than G.W. bushisms.
sometimes i use ::
iptables -vnL | grep -v "^ *0 "
to see rules that have a hit count other 0.
2) Are there any firewall log entries ? Nothing critical for the 'dead' Interface. But I have to retry with logging everything.
3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs) I am completely unshure about everything! I guess, everything should be clear by understanding the IP rules. Is there a debugging tool for this ?
Thanks so far
Peter
___________________________________________________________
Dr. Peter Münstermann
mobil: +49 (0)173/2309398 Schützenstr. 11 tel.: +49 (0)7531/919122 D-78462 Konstanz fax.: +49 (0)7531/914370 ___________________________________________________________
Von: Andreas Baetz
Datum: Mon, 5 Jan 2004 09:01:10 +0100 An: suse-security@suse.com Betreff: Re: [suse-security] another 3-interface firewall problem (two external, no DMZ) You could check the following: 1) Is the routing ok ? 2) Are there any firewall log entries ? 3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs)
You could get more info by tcpdumping your interfaces.
Andreas
On Sunday 04 January 2004 00:00, Dr. Peter M?nstermann wrote:
Hi,
I am running a small enterprise server under Suse 9.0. The main tasks are: Masquerading an internal network, SMTP, POP3 and web serving.
Everything works nice with two interfaces: eth0: 1.2.3.4 netmask 255.255.255.192 (leased line with static IP) eth1: 192.168.0.1 netmask 255.255.255.0 (internal network) with default route 1.2.3.3 Web server is listening on 1.2.3.4, SMTP on both interfaces, POP3 only at the internal interface
NOW: to keep traffic costs as low as possible, we like to route the main traffic over a DSL flat rate. Configuring the DSL stuff gives the aditional ppp0 interface (PPPoE with eth2), masquerading works and I can see the web server at 1.2.3.4 due to the additional entry: iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 1.2.3.4 -j ACCEPT
BUT: The address 1.2.3.4 is not responding from the outside any more. Both eth0 and ppp0 are configured as external interfaces in the SuSEfirewall configuration.
I think, the problem can be seen as a sort of load balancing for the leaving IP packets.
any martians in the log ?
what is the default route now ?
-- BINGO: high-performance breakthrough --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Hi Again,
1) Is the routing ok ? How can I check the routing ? The SuSEfirewall-Script generates more rules than G.W. bushisms.
Print routing table: route -n General routing should look like this: fb7-fg6:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface internal-ip 0.0.0.0 255.255.255.0 U 0 0 0 eth1 external-ip 0.0.0.0 255.255.255.0 U 0 0 0 eth0 dsl-ip 0.0.0.0 255.255.255.0 U 0 0 0 ppp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 default-gw-ip 0.0.0.0 UG 0 0 0 ppp0 default gw is the ip you get from dsl, that should be set correct within dsl "dialup script" and resetted within dsl "dialout script"! If not add a rule within yast/network/dsl. Sometimes that routing stuff acts very strange -> maybe a reboot helps sometimes to reset everything after a change.
2) Are there any firewall log entries ? Nothing critical for the 'dead' Interface. But I have to retry with logging everything.
With this you get the firewalloutput in one file to analyse it: less /var/log/messages | grep DROP > Outputfile
3) Are you sure you don't masq your webserver's reply packets with the wrong IP ? (I understand that you now have 2 external IPs) I am completely unshure about everything! I guess, everything should be clear by understanding the IP rules. Is there a debugging tool for this ? -> /sbin/SuSEfirewall status # gives debug output of iptables sets in SuSEfirewall
Try: less /proc/sys/net/ipv4/ip_forward If you see a "1" you have forwarding enabled. Testing if network is running: unload firewall enable forwarding ping IP of eth0, eth1, ppp0 traceroute www.freenet.de # here we go to external and see where the route goes (e.g. here with freenet.de)! If you get errors here there is no problem with the firewall. The firewall should look: FW_DEV_EXT="eth0 ppp0" FW_DEV_INT="eth1" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="192.168.0.0/24" FW_PROTECT_FROM_INTERNAL="yes" FW_AUTOPROTECT_SERVICES="yes" configure the services and ports for your desire! # bad security, but for testing ... FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" FW_SERVICE_AUTODETECT="yes" FW_KERNEL_SECURITY="yes" # for testing set to "yes" \/\/\/\/ FW_STOP_KEEP_ROUTING_STATE="yes" FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="yes" FW_ALLOW_PING_EXT="yes" FW_ALLOW_FW_SOURCEQUENCH="no" FW_ALLOW_FW_BROADCAST="no" FW_IGNORE_FW_BROADCAST="yes" FW_ALLOW_CLASS_ROUTING="yes" FW_REJECT="no" # for german t-dsl: FW_HTB_TUNE_DEV="ppp0,250" # not optimized: FW_HTB_TUNE_DEV="" Philippe
participants (5)
-
Andreas Baetz
-
Christian Lange
-
Dr. Peter M=?ISO-8859-1?B?/A==?=nstermann
-
engelbert.gruber@ssg.co.at
-
Philippe Vogel