SuSE-FW-NO_ACCESS_INT->FWEXT (last attempt)
I'm going to make one last attempt at getting some answers to my problem before I leave this list. Hopefully someone can help me, or at least tell me what I want done is impossible so I don't have to keep looking for a solution. Here's my problem: I'm using SuSE 8.0 with SuSEfirewall2, and on my firewall I have ports for ssh,smtp,http and identd open to the outside, and the same ports plus pop3+samba open for the internal network. I also have an extra port (not 21) opened for my ftp service. My problem is that I can access all resources from the inside using the internal ip-adress of the firewall, ie I can view the web pages when calling http://192.168.0.1/ from any other machine on the internal network. It also works when I try to access the web server from the outside (using the external ip), BUT when I try to access the web server using the external ip (or the domain pointing to my firewall) nothing happens and i get this logged in /var/log/firewall: Jul 27 14:25:22 linux kernel: SuSE-FW-NO_ACCESS_INT->FWEXT IN=eth0 OUT= MAC=00:50:8b:03:d1:60:00:c0:26:59:d9:56:08:00 SRC=192.168.0.5 DST=213.66.148.171 LEN=64 TOS=0x08 PREC=0x00 TTL=128 ID=33688 DF PROTO=TCP SPT=3802 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402) Same goes for when I try to access any of the other services from the inside using the external ip. How can I make this work? Here is my /etc/sysconfig/SuSEfirewall2 setup: FW_DEV_EXT="eth1" FW_DEV_INT="eth0" FW_DEV_DMZ="" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_DEV="eth1" FW_MASQ_NETS="192.168.0.0/24" FW_PROTECT_FROM_INTERNAL="yes" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="113 8000 http smtp ssh" FW_SERVICES_EXT_UDP="" FW_SERVICES_EXT_IP="" FW_SERVICES_DMZ_TCP="" FW_SERVICES_DMZ_UDP="" FW_SERVICES_DMZ_IP="" FW_SERVICES_INT_TCP="113 139 445 8000 http pop3 pop3s smtp ssh" FW_SERVICES_INT_UDP="137:138" FW_SERVICES_INT_IP="" FW_TRUSTED_NETS="192.168.0.0/24" FW_ALLOW_INCOMING_HIGHPORTS_TCP="8000" FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS" FW_SERVICE_AUTODETECT="yes" FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="yes" FW_SERVICE_DHCPD="no" FW_SERVICE_SQUID="no" FW_SERVICE_SAMBA="no" 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="yes" FW_STOP_KEEP_ROUTING_STATE="no" FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="no" FW_ALLOW_PING_EXT="no" 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" Any help would be appreciated, thank you! Jonas
On Thu, 1 Aug 2002, j0nas wrote:
I'm going to make one last attempt at getting some answers to my problem before I leave this list.
Leaving? No.... :)
My problem is that I can access all resources from the inside using the internal ip-adress of the firewall, ie I can view the web pages when calling http://192.168.0.1/ from any other machine on the internal network. It also works when I try to access the web server from the outside (using the external ip), BUT when I try to access the web server using the external ip (or the domain pointing to my firewall) nothing happens and
This is a "feature"... :) It has been discussed to some extent before on this list I think, so maybe you can find something interesting by reading through the archives at the SuSE web site. Anyway, there are probably a number of ways to solve this. The reason your requests fail is that the external interface is protected from your internal network, so any packages with your external IP as destination coming in through your internal interface will be dropped with a log message similar to the one below. In order to resolve this, you need to explicitly allow traffic from the internal network to your external IP. This can be done by using tailored ipchains commands, either inserted into an appropriate hook in the firewall2-custom.rc.config or executed somewhere else, like in a bootup script. Anyway, I use the brutal method of opening everything from my internal network, but that is because I'm the only one there and I sort of trust myself. iptables -I INPUT 1 -j ACCEPT -p all -i eth1 -d abc.def.ghi.jkl/32 -s 192.168.0.0/24 You might want to use the -A flag instead, and most likely you'd like to use one line for each of your external services and with the additional --dport <whatever> to specify just which services your internal users are supposed to be able to reach. Maybe you'd like to restrict the protocols as well, so look at the -p flag too. You'd also need to change 'eth1' above to 'eth0' in your case. All in all, man iptables is your friend. :-)
i get this logged in /var/log/firewall: Jul 27 14:25:22 linux kernel: SuSE-FW-NO_ACCESS_INT->FWEXT IN=eth0 OUT= MAC=00:50:8b:03:d1:60:00:c0:26:59:d9:56:08:00 SRC=192.168.0.5 DST=213.66.148.171 LEN=64 TOS=0x08 PREC=0x00 TTL=128 ID=33688 DF PROTO=TCP SPT=3802 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402)
It's seldom a good idea to send log entries without mangling the external IP address. :) Hope it helps somewhat. /Johan
I solved a similar problem configuring an internal DNS server and pointing the web/ftp server names to the internal IP addresses. Or do you want to be able to access your servers with the external IP addresses and not the given hostnames? Perhaps an entry in /etc/hosts will work for you, depending on what kind of network you have (Unix/Linux or other not using /etc/hosts, or too many Unix/Linux so updating /etc/hosts would be painful so beter configure a DNS server?) You could also filter packets coming from your local network on the firewall with destination IP set to your external servers and change their destination IP to the local one. (static NAT) Have a look at the iproute2 package! ip route add nat ... via ... Lots of possibilities as you can see! Bye, Richard -- Richard Ems ... e-mail: r.ems@gmx.net ... Computer Science, University of Hamburg Unix IS user friendly. It's just selective about who its friends are.
As to your first statements, this is a voluntary response list. People may not respond for several reasons. I believe the answer to your problem is to place the following in your custom config file for the firewall: fw_custom_before_antispoofing() { # these rules will be loaded before any anti spoofing rules will be # loaded. Effectively the only filter lists already effective are # 1) allow any traffic via the loopback interface, 2) allow DHCP stuff, # 3) allow SAMBA stuff [2 and 3 only if FW_SERVICE_... are set to "yes"] # You can use this hook to prevent logging of uninteresting broadcast # packets or to allow certain packet through the anti-spoofing mechanism. #example: allow incoming multicast packets for any routing protocol #iptables -A INPUT -j ACCEPT -d 224.0.0.0/24 iptables -A INPUT -i eth1 -s 192.168.0.0/24 -d 999.999.999.999 -j ACCEPT true } Note, 999.999.999.999 should be set to the IP adderss for your external interface. You will also need to add this line to the end of your firewall config file: # # 25.) # Do you want to load customary rules from a file? # # This is really an expert option. NO HELP WILL BE GIVEN FOR THIS! # READ THE EXAMPLE CUSTOMARY FILE AT /etc/rc.config.d/firewall2- custom.rc.config # FW_CUSTOMRULES="/etc/rc.config.d/firewall2-custom.rc.config" This should do the job for you. This is an intentional security measure in the firewall to prevent spoofing of your internal addresses to your external interface. Jim By the way, the 'last attempt' comment may actually get you ignored by some members of this list. 8/1/2002 4:29:43 AM, j0nas <jonas@falafel.nu> wrote:
I'm going to make one last attempt at getting some answers to my problem before I leave this list. Hopefully someone can help me, or at least tell me what I want done is impossible so I don't have to keep looking for a solution. Here's my problem:
I'm using SuSE 8.0 with SuSEfirewall2, and on my firewall I have ports for ssh,smtp,http and identd open to the outside, and the same ports plus pop3+samba open for the internal network. I also have an extra port (not 21) opened for my ftp service.
My problem is that I can access all resources from the inside using the internal ip-adress of the firewall, ie I can view the web pages when calling http://192.168.0.1/ from any other machine on the internal network. It also works when I try to access the web server from the outside (using the external ip), BUT when I try to access the web server using the external ip (or the domain pointing to my firewall) nothing happens and i get this logged in /var/log/firewall: Jul 27 14:25:22 linux kernel: SuSE-FW-NO_ACCESS_INT->FWEXT IN=eth0 OUT= MAC=00:50:8b:03:d1:60:00:c0:26:59:d9:56:08:00 SRC=192.168.0.5 DST=213.66.148.171 LEN=64 TOS=0x08 PREC=0x00 TTL=128 ID= 33688 DF PROTO=TCP SPT=3802 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402)
Same goes for when I try to access any of the other services from the inside using the external ip. How can I make this work?
Here is my /etc/sysconfig/SuSEfirewall2 setup: FW_DEV_EXT="eth1" FW_DEV_INT="eth0" FW_DEV_DMZ="" FW_ROUTE="yes"
FW_MASQUERADE="yes" FW_MASQ_DEV="eth1" FW_MASQ_NETS="192.168.0.0/24"
FW_PROTECT_FROM_INTERNAL="yes" FW_AUTOPROTECT_SERVICES="yes"
FW_SERVICES_EXT_TCP="113 8000 http smtp ssh" FW_SERVICES_EXT_UDP="" FW_SERVICES_EXT_IP="" FW_SERVICES_DMZ_TCP="" FW_SERVICES_DMZ_UDP="" FW_SERVICES_DMZ_IP="" FW_SERVICES_INT_TCP="113 139 445 8000 http pop3 pop3s smtp ssh" FW_SERVICES_INT_UDP="137:138" FW_SERVICES_INT_IP=""
FW_TRUSTED_NETS="192.168.0.0/24"
FW_ALLOW_INCOMING_HIGHPORTS_TCP="8000" FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS"
FW_SERVICE_AUTODETECT="yes" FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="yes" FW_SERVICE_DHCPD="no" FW_SERVICE_SQUID="no" FW_SERVICE_SAMBA="no"
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="yes"
FW_STOP_KEEP_ROUTING_STATE="no"
FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="no" FW_ALLOW_PING_EXT="no"
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"
Any help would be appreciated, thank you!
Jonas
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Thursday 01 August 2002 11:29, j0nas wrote: [snip]
(using the external ip), BUT when I try to access the web server using the external ip (or the domain pointing to my firewall) nothing happens and i get this logged in /var/log/firewall:
I also had this occur, but my case was even worse; I had portforwarding for port 80 external address to an internal server. This, unlike your problem (as stated in the other replies) seemed (or indeed really was?) insolvable since the portforwarding occurs at an earlier stage than the NAT, so by the time the NAT-ed packet arrives at the external interface it could never be 'forwarded back in'. Or so I've been told anyway... In such cases, apart from mangling the Iptables setup, it can be a nice solution to let DNS solve this, either by having your internal DNS 'fake' the real address ( it then pretends www.domain.com is not in fact the external, but the internal IP) or, as I currently do, just have a special DNS name for your internal network and just TELL people they must use the alternative name instead whenever they're located 'inside'. (tell them to use "www.office.domain.com" instead of "www.domain.com") This may or may not be tedious to them but I dislike faking DNS records (it tends to turn into a great mess over time if you change the official DNS records and 'forget' to change the internal one!) and if people stop listening to their sysadmins then they're on their own anyway. So what if they have to change 1 or 2 bookmarks ? Not my problem, is it ? ;-)) Choose your own, according to your preferences, or affinity. Either of the three solutions mentioned wiil work for you. Maarten Oh P.S.: Do try to have your mails not sound like some kind of "ultimatum" for us all to reply to, it tends to work _very_ counter-productive. ;-) -- This email has been scanned for the presence of computer viruses. Maarten J. H. van den Berg ~~//~~ network administrator VBVB - Amsterdam - The Netherlands - http://vbvb.nl T +31204233288 F +31204233286 G +31651994273
participants (5)
-
j0nas
-
James Bliss
-
Johan Stäring
-
Maarten J H van den Berg
-
Richard Ems