Hi,
yesterday we installed our firewall with dsl connection on dsl0 with dsl-modem connected to eth0.
The internal network is connected to eth1 (IP: 10.2.0.254)
IP-Forwarding is enabled so we can use 10.2.0.254 as gateway in our local network and browse the internet.
DNS is also installed. But we need to connect to the firewall from the internet so I set up masquerading and dyndns.
However, it only works from the internet. Locally it doesn’t work, with our dyndns hostname we can only reach the firewall, same as 10.2.0.254.
Adding “zone: int” in FW_MASQ_DEV doesn’t work as this makes the use as gateway impossible (http://opensuse.org => 10.2.0.254:80).
With a little hack it works: Change
in which SuSEfirewall2.
But this workaround is total garbage, as our dsl0 ip varies everyday.
Is there a better solution to achieve this?
I thought of forcing every traffic from our local network to our dsl0 ip through dsl0 so it appears as connection from extern. But I don’t know how to do this.
It’s not completely clear to me what you’re attempting to do, but if you are simply creating an internet gateway from a local machine running Opensuse then it is fairly straight-forward. There are many examples of how to use iptables to set up a firewall/gateway (for example search Google for ‘Set up local linux gateway’) . If you have a dedicated machine which is solely used for firewall/gateway then I would have to say that Opensuse (or any other standard desktop distro) is not the best solution. You should look at Smoothwall which is a free firewall/gateway and is exceptional.
For a solution based on what you are attempting can you explain
What version of opensuse you are using?
When you say “Locally it isn’t working” exactly what is not working? What can you do and not do?
If you want to access the local Lan from outside the firewall you will have to set up port or ip forwarding which again is explained if you search Google for those phrases.
You can avoid using the external IP address of the gateway by specifying the device name (dsl0) instead using -i dsl0 or -o dsl0 depending on whether you are referencing inputs or outputs on that device.
Please provide more information and think about whether using Opensuse (or any other desktop distro) is really what you want.
Everything is working already, except accessing the masqueraded external IP from zone:int. We want to use OpenSUSE because all other solutions are absolute garbage (at least for us). We tried IpCop and M0n0wall before and we also wanted to configure it more low-level. Also, a local proxy server (squid + squidguard) is configured. A web server with php is also needed, what makes opensuse the only possible choice.
For a solution based on what you are attempting can you explain
What version of opensuse you are using?
The latest, 12.3.
When you say “Locally it isn’t working” exactly what is not working? What can you do and not do?
Works:
*****.dyndns.info from zone:ext
OpenVPN
Proxy
Gateway
DNS
Doesn’t work:
*****.dyndns.info from zone:int
If you want to access the local Lan from outside the firewall you will have to set up port or ip forwarding which again is explained if you search Google for those phrases.
That it already working, but only from the outside/external network.
You can avoid using the external IP address of the gateway by specifying the device name (dsl0) instead using -i dsl0 or -o dsl0 depending on whether you are referencing inputs or outputs on that device.
By using our dyndns hostname internally the traffic doesn’t flow through dsl0 at all, that’s the issue. In SuSEfirewall2 it shouldn’t be -i dsl0, it should be -d WAN_IP. So every traffic to the external IP gets port-forwarded.
Please provide more information and think about whether using Opensuse (or any other desktop distro) is really what you want.
OpenSUSE is not only a desktop distro, we’re using it on 20 servers here. At least there’s an installation mode “server installation(textmode only)”.
OK things are starting to become clearer!! You have a big installation which I hope you can share a bit more info about, just to clarify some more.
With regard to the comment about Opensuse not just being a desktop system, I concur with your comment that Opensuse can be at the heart of a powerful server too. The point I was trying to make (badly) was that it is not a specialised firewall/gateway system and will therefore perhaps be a) harder to configure and b) not as secure. I would still strongly recommend Smoothwall, but lets get back to the problem you originally asked about.
How big is your LAN - you say you have 20 opensuse servers - do they all sit on the same LAN behind this firewall system?
How many client systems are on the LAN?
What services are they requesting through the firewall server?
When you say dynamic dns fails on the internal zone, what failure do you see? Are there log entries which you can share? I’m trying to understand if the failure is a routing failure caused by the firewall rules, or a DNS failure caused by the dyndns server.
Finally… It’s not that easy to explain such complicated problems with iptables in a foreign language
We’re a school with 1600 students, 4 computer rooms and WLAN with authentication for teachers and students.
Teachers should be able to surf the internet without being filtered, but students shouldn’t get to facebook, games and other “distractions”.
For the computers the students use we want to filter HTTP transparently and block HTTPS, so they’re forced to use a proxy.
It’s the best way to install the filter directly on the only PC having a direct connection to the internet, the firewall.
We used IpCop (1.4) before, but many features we’d need were missing, especially custom iptables rules.
The users authenticate via samba and we made the samba database accessible via HTTP on our main server (don’t worry, it’s secure :)) and we need to be able to reach this information from our homepage. So port forwarding (at least for vpn) is the only possible option.
With regard to the comment about Opensuse not just being a desktop system, I concur with your comment that Opensuse can be at the heart of a powerful server too. The point I was trying to make (badly) was that it is not a specialised firewall/gateway system and will therefore perhaps be a) harder to configure and b) not as secure. I would still strongly recommend Smoothwall, but lets get back to the problem you originally asked about.
How big is your LAN - you say you have 20 opensuse servers - do they all sit on the same LAN behind this firewall system?
Yup, the firewall is the global dns, proxy and gateway.
How many client systems are on the LAN?
~200
What services are they requesting through the firewall server?
Mostly http and https, rarely pop/smtp/imap.
When you say dynamic dns fails on the internal zone, what failure do you see? Are there log entries which you can share? I’m trying to understand if the failure is a routing failure caused by the firewall rules, or a DNS failure caused by the dyndns server.
It’s actually a simple logic failure: The port forwarding/“-DNAT” rules apply only to packets incoming from zone:ext (dsl0), but as *****.dyndns.info resolves to the external IP of the firewall, the firewall can answer requests directly, without using dsl0. It makes no difference if I’m using 10.2.0.254 (the local IP of the firewall) or ****.dyndns.info (the external) from inside the local network.
IMHO it is not possible to do what you are trying to do with iptables. I have a reasonable amount of iptables
experience (although I’m a little rusty) and I do not think there is a solution - but I may be wrong!!
I wonder instead if you have a DNS problem rather than a Firewall iptables ‘logic’ problem.
Here are my thoughts - this is my train of thought so may contain alot of what may seem obvious stuff!!
I would also add that I am not a DNS expert so will accept critiques from those who are!
If I’m sitting at a client machine out on the internet somewhere and I want to access a web server on your LAN,
I put the name of the web server (eg www.vogtinator.dyndns.org) into my browser. My system then sends a DNS lookup
request to the nearest Name Server (which could be located anywhere) which tries to resolve the name into an
IP address. If it can’t it passes the name on to the next level, and eventually the name is resolved into an
IP address which is passed back to my client system.
My client system then attempts to establish a connection with the system which owns the IP address, using the http
or https port. The connection will reach your firewall/gateway which will accept the connection because there is a
NAT table entry which says that attempted external connections on port 80 (http) or 443 (https) are to be translated
and forwarded to the local web server (eg serverX) on your LAN. serverX will then serve the web connection request and
will Masquerade as your WAN IP in order to maintain the connection until it is closed by me on the client system.
In this case the standard network translation and masquesrading rules have been applied to access serverX transparently
from my client system. The Firewall/Gateway has routed the web server request to the correct machine on your LAN and
has managed the connection packet by packet.
If I’m sitting at a client machine on your LAN and I want to access a local web server, I put the name of the
web server (eg www.vogtinator.dyndns.org) into my browser. My system then sends a DNS lookup request to the nearest
Name Server which is also on the LAN. This Name Server should ALWAYS resolve local names for local services. In this
case I would expect the local Name Server to resolve www.vogtinator.dyndns.org to the IP address of serverX. In this
way, no external DNS lookup is required. The IP address of serverX is returned to my client machine which then attempts
to establish a connection to the system which owns the IP address - in this case serverX. serverX directly responds to
the connection attempt, and will serve the client until it closes the connection on either port 80 or 443.
The local Name Server’s entries for local LAN machines are private to the LAN and never get exported outside of the LAN.
The Firewall/Gateway has no part to play in routing local LAN traffic as should be the case. In this way there is no
NAT rule required to handle local LAN traffic.
I presume that all your 10 servers (web, mail, file, print ?) have static IP addresses and are all referenced by a
local Name Server.
Also I am presuming that you don’t use a DMZ - not using one is asking for trouble in my view but that’s another
story altogether.
The other thing is this - NAT table rules are invoked when a packet is received which tries to establish a new
connection. When the packet has come from outside the LAN and is addressed to the gateway IP address, it is obvious
where the connection attempt is being made. When the packet comes from inside the LAN and is addressed to the
gateway IP address, the connection attempt is not obvious so NAT rules may not be invoked.
If you can find a solution using iptables I would be interested in seeing it.
Actually, I already found a solution, read my first post
I wonder instead if you have a DNS problem rather than a Firewall iptables ‘logic’ problem.
Nope, DNS is working fine. The problem is solely related to a simple logic failure.Only requests from the internet get translated (through the NAT table).Locally the firewall itself answers.The easiest thing would be to not translate every packet targeting dsl0, but packets targeting the dynamic public IP address of the firewall.But I don’t know how to set this up with iptables. Something like “-d ipof(dsl0)” would be perfect.
Here are my thoughts - this is my train of thought so may contain alot of what may seem obvious stuff!! I would also add that I am not a DNS expert so will accept critiques from those who are!
I’m very thankful yast dns-server set up the important stuff itself…
If I’m sitting at a client machine out on the internet somewhere and I want to access a web server on your LAN, I put the name of the web server (eg www.vogtinator.dyndns.org) into my browser. My system then sends a DNS lookup request to the nearest Name Server (which could be located anywhere) which tries to resolve the name into an IP address. If it can’t it passes the name on to the next level, and eventually the name is resolved into an IP address which is passed back to my client system.My client system then attempts to establish a connection with the system which owns the IP address, using the httpor https port. The connection will reach your firewall/gateway which will accept the connection because there is a NAT table entry which says that attempted external connections
EXACTLY! “external connection”: Connection to dsl0!
on port 80 (http) or 443 (https) are to be translated and forwarded to the local web server (eg serverX) on your LAN. serverX will then serve the web connection request and will Masquerade as your WAN IP in order to maintain the connection until it is closed by me on the client system.In this case the standard network translation and masquesrading rules have been applied to access serverX transparently from my client system. The Firewall/Gateway has routed the web server request to the correct machine on your LAN and has managed the connection packet by packet.{/QUOTE]2. If I’m sitting at a client machine on your LAN and I want to access a local web server, I put the name of the web server (eg www.vogtinator.dyndns.org) into my browser. My system then sends a DNS lookup request to the nearestName Server which is also on the LAN. This Name Server should ALWAYS resolve local names for local services. In thiscase I would expect the local Name Server to resolve www.vogtinator.dyndns.org to the IP address of serverX. In this way, no external DNS lookup is required.
Nope, the firewall doesn’t know it’s also called ****.dyndns.info. This makes things much easier.(Only an excuse, I don’t know how to set up host->ip entrys in yast dns-server lol!
The IP address of serverX is returned to my client machine which then attempts to establish a connection to the system which owns the IP address - in this case serverX. serverX directly responds tothe connection attempt, and will serve the client until it closes the connection on either port 80 or 443.The local Name Server’s entries for local LAN machines are private to the LAN and never get exported outside of the LAN.The Firewall/Gateway has no part to play in routing local LAN traffic as should be the case. In this way there is no NAT rule required to handle local LAN traffic.
But I WANT the firewall to route internal traffic to a forwarded port on *****.dyndns.info!
I presume that all your 10 servers (web, mail, file, print ?) have static IP addresses and are all referenced by a local Name Server.
We only use ips, we don’t want to depend on another machine… /etc/hosts on some cases when it’s unavoidable.
Also I am presuming that you don’t use a DMZ - not using one is asking for trouble in my view but that’s another story altogether.
The more important part at school, the office and the principal, have no connection to the school’s (our) internet.They have a seperate connection and seperate firewall (a VERY expensive professional (hardware) firewall from bintec).The WLAN part is handled by a different firewall as well, which also has to handle captive portal and some RADIUS parts.
The other thing is this - NAT table rules are invoked when a packet is received which tries to establish a newconnection. When the packet has come from outside the LAN and is addressed to the gateway IP address, it is obviouswhere the connection attempt is being made. When the packet comes from inside the LAN and is addressed to thegateway IP address, the connection attempt is not obvious so NAT rules may not be invoked.If you can find a solution using iptables I would be interested in seeing it.
Again, look above Also imaginable would be to stop letting SuSEfirewall2 handle the NAT, but setting the rules up in a script that runsafter the internet connection is established (the IP has changed). Wouldn’t be THAT great, but if it’s the only solution (apart from manually editing SuSEfirewall2 itself)I may have to be pleased with this.
The iptables rules wouldn’t have an effect anymore.
I think only the anyway opened ports would be accessible (openvpn), like without any port forwarding rules at all.
I also tried to NAT all the traffic NOT going to the local ip “! -d 10.2.0.254” instead of “-d WAN_IP” or “-i dsl0” but that breaks the gateway functionality.
Exactly!! That’s my point :P- you don’t have a solution only a workaround which only works for as long as the WAN IP address remains unchanged.
The only other possibility is that presumably some part of your network must restart when the WAN IP address changes. You could add a script which executes at this point and resets the NAT rule with the new address.
That would need some understanding of what happens when the WAN IP changes via DHCP.
I wanted to figure that out after the first change occured. It occured some hours ago and I’m not able to reach the server anymore. F*CK!
I’m not able to fix it until Monday >:( The worst part is, the firewall was running for three days straight, but apparently we had to fiddle with the network once every 24hours so we circumvented the renews accidentially everyday. Any Idea what could have caused this? AUTO_RECONNECT is set to true in /etc/sysconfig/network/provider1. I also added AUTO_RECONNECT_EXITS=“0 15”.
No - it’s surprising that “fiddling with the network” affects the DHCP renew if it normally re-leases once every 24 hours. I don’t have specific knowledge or experience of DHCP to offer any help. All I know is that dhclient (if that’s what you’re using) renews IP without taking down the interface, and that it uses the ifrenew/ifrenew-dhcp scripts (which are symlinks to ifup and ifup-dhcp) in the process, but I do not know anything more about how it works. I wonder if anyone else in the forum knows which executables and which scripts are used to renew DHCP leases and get new IP addresses.
As far as I know, the ISP cuts the connection exactly 24 hours after the connection has been made and the server has to re-login.
With “fiddling with the network” I meant something like reconnecting the modem, restarting the interfaces and rebooting the entire machine. Such things which delay the next renew.
So I think we have a solution for you based on the link below - an identical problem posted by someone on another forum.
The solution is based on the answers I gave before
using -i eth0 and -i eth1 to create separate NAT rules for each of your two interfaces and
No problem, that already has been taken care for by SuSEfirewall2. I just had to set FW_MASQ_DEV to “zone:ext zone:int”.
ensuring that your internal DNS resolves servers to their static addresses for internal clients WITHOUT going outside to the internet
I’m only using IPs internal, so that shouldn’t be a problem. But I should definitely read more about bind…
Have a read of it all and see what you think. I think it is definitely the way to go.
Actually, I don’t think so. He says:
I still can’t help thinking this would’ve been easier if there were a way to specify the destination IP as “any of mine, whatever they might be” (and I might’ve needed it if my internal IP wasn’t static).
In my case, the internal IP is static, but if I apply NAT to everything “-i INTERNAL ! -d LOCAL_IP” the functionality as a gateway would be broken. http://opensuse.org would have the same effect as http://*****.dyndns.info.
Could it be the only possible solution is setting up a script in /etc/ifup.d/? Oh, wait, SuSEfirewall2 is already inside.
Does it mean I just have to modify SuSEfirewall2 (again) and add something like “-d IPOF(EXTERNAL)”?
Do I have to find the IP of my external interface myself or can iptables already do this automatically?
Either you’re misunderstanding the solution offered in the link I provided, or else you’re just determined to implement a fix your own way!! lol!Are you sure that you have understood what the other guy did?? He has static IP servers and used DNS to ensure that requests generated internally on his LAN were satisfied internally by his Name Server. Anyhow if you are determined to do things using the WAN IP then let’s continue!!
Could it be the only possible solution is setting up a script in /etc/ifup.d/? Oh, wait, SuSEfirewall2 is already inside.
Does it mean I just have to modify SuSEfirewall2 (again) and add something like “-d IPOF(EXTERNAL)”?
Do I have to find the IP of my external interface myself or can iptables already do this automatically?
iptables will not provide the IP of the external interface. You can do this like this
Your script would need to be executed at the point where the new IP address had been set by dhclient and it’s associated processes. This is the bit I don’t know much about - what scripts are executed at what points in this process of DHCP renew.
I still think that the solution offered is robust, neat, elegant and maintenance-free, but it’s your problem, your system and your decision!
Your script would need to be executed at the point where the new IP address had been set by dhclient and it’s associated processes. This is the bit I don’t know much about - what scripts are executed at what points in this process of DHCP renew.
I think /etc/sysconfig/network/if-up.d/SuSEfirewall2?
I still think that the solution offered is robust, neat, elegant and maintenance-free, but it’s your problem, your system and your decision!
Actually, we only want to use a local DNS because of caching the hostnames. Modifying DNS for every port forwarding change is the opposite of “elegant”.
The problem is, ****.dyndns.info:80 leads to 10.2.0.1:80 but ****.dyndns.info:88 to 10.2.0.6:80.
I don’t think dns alone can handle this.
You are misunderstanding the solution completely - you are missing several vital points.
For the example you quote above, you create a separate iptables NAT rule for each redirection you want, so
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 10.2.0.1:80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 88 -j DNAT --to 10.2.0.6:80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth1 -d <IP of local server> --dport 80 -j DNAT --to 10.2.0.1:80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth1 -d <IP of local server> --dport 88 -j DNAT --to 10.2.0.6:80
Actually, we only want to use a local DNS because of caching the hostnames. Modifying DNS for every port forwarding change is the opposite of “elegant”.
and you make ONE change ONLY to your local DNS server which resolves ****.dyndns.info to <IP of local server>
I give up. You must do what you think is best. Viel Glück!!rotfl!
Which points did I miss? Please tell me if I’m too dumb and overlooking the obvious!
For the example you quote above, you create a separate iptables NAT rule for each redirection you want, so
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 10.2.0.1:80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 88 -j DNAT --to 10.2.0.6:80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth1 -d <IP of local server> --dport 80 -j DNAT --to 10.2.0.1:80
/sbin/iptables -t nat -A PREROUTING -p tcp -i eth1 -d <IP of local server> --dport 88 -j DNAT --to 10.2.0.6:80
This is the same as FW_MASQ_DEV=“eth0 eth1” or in my case FW_MASQ_DEV=“zone:ext zone:int” would do.
and you make ONE change ONLY to your local DNS server which resolves ****.dyndns.info to <IP of local server>
That’s exactly the thing I don’t want. The firewall should have different services listening on eth1 and eth0.
Example: ssh ***.dyndns.info should go to our primary server, but ssh 10.2.0.254 should still reach the firewall.
I give up. You must do what you think is best. Viel Glück!!rotfl!
It seems /etc/sysconfig/network/ifup.d/SuSEfirewall2 already invokes /usr/sbin/SuSEfirewall2 -q start,
so I only have to change SuSEfirewall2.
What do you think of reporting a bug?
Some other people had the same problem and I don’t think this is behaviour is intended.
Und ja, das Glück kann ich brauchen, danke!
