Posted by Steve on Wed 6 Oct 2004 at 12:12
Many people want to use a dedicated Debian machine as a gateway for a LAN, this has many benefits compared to using a dedicated hardware firewall. For a start it's a lot more flexible, but in addition to this it allows you to offer a lot of extra services to your machines.
To run a Debian gateway you'll need a machine with two network cards, and you'll need to be able to setup the external one to route to your ISP properly.
I tend to use eth0 to be the internal network card, this is the one which has an IP address like 192.168.1.1 and is used as the default gateway for your internal machines.
This leaves eth1 as the external address for your machine.
In order for your machine to work as a gateway and route packets from your LAN to the world and back it needs to have 'IP forwarding' enabled, and some rules on how to route packets. This can be done with iptables.
We basically need to have three sets of rules:
This leaves us with a script something like this:
#!/bin/sh PATH=/usr/sbin:/sbin:/bin:/usr/bin # # delete all existing rules. # iptables -F iptables -t nat -F iptables -t mangle -F iptables -X # Always accept loopback traffic iptables -A INPUT -i lo -j ACCEPT # Allow established connections, and those not coming from the outside iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -i ! eth1 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow outgoing connections from the LAN side. iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT # Masquerade. iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE # Don't forward from the outside to the inside. iptables -A FORWARD -i eth1 -o eth1 -j REJECT # Enable routing. echo 1 > /proc/sys/net/ipv4/ip_forward
If you save this script upon your system you'll want it to run as soon as your network interfaces come up. To do that you can save it in the directory /etc/network/if-up.d/. Everything inside that directory is executed when an interface comes up, so long as it's executable.
As the directory contents are executed in order I call my script 00-firewall.
This should give you a basic gateway now. Any machine on your internal LAN should be able to access the internet whilst your gateway is kept nice and secure.
Now you can look at adding extra services for your LAN, from the gateway.
There are a couple of interesting things that you can add to make your life easier, for example rather than giving each of your LAN machines a fixed IP address you can allow them to be dynamic using DHCP.
You can also install a local nameserver to cache DNS lookups and allow you to recognise your internal machines.
A great package for this is dnsmasq. This can be installed via apt-get and is configured via a simple readable file /etc/dnsmasq.conf.
Once this is running you will find that client machines can lookup any host which is included in the /etc/hosts file on the server - so you can start giving machines aliases which can be resolved easily.
For example if you install a proxy server to cache HTTP downloads on your gateway you can create the name proxy for it:
# # /etc/hosts # 127.0.0.1 localhost # # Local machines. # 192.168.1.1 gateway gateway.my.flat proxy proxy.my.flat
This creates a new name 'proxy' for the machine normally known as 'gateway'.
This artical was easy to do and worked first time. Just needed to change the eth numbers around in the script. For me as a newbie running the system as described in the artical this was excelent.
Bob
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Probably line ending issues .. make sure it is not a DOS file.
Run:
perl -pi.bak -e 's/\r\n/\n/' /etc/network/if-up.d/00-firewall
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Change every occurance of eth1 to ppp0 in the script and you should be fine.
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
That should be sufficient if the gateway is setup correctly - are you sure that IP forwarding is enabled upon the gateway?
[ Parent ]
[ Parent ]
Since you're using ppp0 for the outgoing device on the gateway I'd definitely double-check that you changed things appropriately from the example in this article.
It might be useful to flush the firewall and enter the rules manually whilst you're dialled out. The following will do the flush:
iptables -F iptables -t nat -F iptables -t mangle -F iptables -X
Once you've done that check the routes. I'd expect something like:
skx@desktop:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
You can drop any routes and recreate them on the LAN machine(s) to see if that helps.
[ Parent ]
[ Parent ]
ultra1:~#/etc/init.d/networking restart Setting up IP spoofing protection: rp_filter. Reconfiguring network interfaces...ifup: interface lo already configured run-parts: failed to exec /etc/network/if-up.d/00-firewall: Exec format error run-parts: /etc/network/if-up.d/00-firewall exited with return code 1 run-parts: failed to exec /etc/network/if-up.d/00-firewall: Exec format error run-parts: /etc/network/if-up.d/00-firewall exited with return code 1 done. ultra1:~#But it works flawlessly when I run the script manually:
ultra1:~#/etc/network/if-up.d/00-firewall ultra1:~#What could the problem be?
[ Parent ]
Make sure that the first line of the script is "#!/bin/sh".
As for the IP address range you use it doesn't much matter. There are several ranges which are set aside for "local" use this guide shows you them.
I use 192.168 exclusively, the only reason not to is if you run into problems with a VPN sharing the same space on the far side. Also many common household routers will assume 192.168.1.x which can be handy.
Using the 10.x.x.x prefix I guess gives you a much bigger pool of addresses - but that isn't likely to be a good enough reason for preferring it in the home setting. I'd ask your professor why he has a preference?
[ Parent ]
[ Parent ]
I'd suggest this is probably not something that will be easy to solve. If it works at all then the gateway is working, and realistically the gateway shouldn't care what type of traffic is passing over it.
I'd suggest you look at DNS configuration, and see what server-side messages you can get from the remote SSL server(s) to see if there is something else misconfigured..
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
# The loopback network interface auto lo iface lo inet loopback # The primary network interface (Uplink) auto eth0 iface eth0 inet dhcp # The secondary network interface (LAN interface) auto eth1 iface eth1 inet static address 192.168.0.1 netmask 255.255.255.0I also created a basic (less secure) script to see if my error was in miking up interfaces in your script.
#!/bin/sh PATH=/usr/sbin:/sbin:/bin:/usr/bin iptables -F iptables -t nat -F iptables -t mangle -F iptables -X echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 192.168.0.1/24 -o eth0 -j MASQUERADEI have a windows machine that I am trying to connect to the gateway and I cannot get a valid local IP address or ping the gateway. I have tried both using a static IP and DHCP requests on the windows machine. What am I missing? I cant imagine it is an IP conflict because there is only 2 NICs on the local network, eth1 and my second computer. Thanks.
[ Parent ]
Sounds to me like there is something strange going on. The setup you've described should work just fine.
If you give the windows machine the following details what happens? Can it ping the gateway, or the outside world?
ip: 192.168.0.10 netmask: 255.255.255.0 broadcast: 192.168.0.255 gateway: 192.168.0.1
[ Parent ]
~#ping google.com
Pinging google.com [72.14.207.99] with 32 bytes of data:
Ping statistics for 72.14.207.99:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Connected through gateway:
~#ping google.com
Ping request could not find host google.com. Please check the name and try again.
~#ping google.comping 72.14.207.99
Pinging 72.14.207.99 with 32 bytes of data:
Ping statistics for 72.14.207.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
I have a modded xbox (running XBMC) on my network as well, but I cant seem to get it working with the gateway. The setting on it all work fine if I set a windows machine up as a gateway using ICS so I would imagine I wouldn't have to change anything on it if I am using the debian gateway instead (both gateways are set to be 198.168.0.1 and I only have one or the other running at a time during this testing). I wouldnt imagine that you would know what could cause that, but do you have any suggestion about the why I cannot resolve DNS addresses? I have dnsmasq running on my gateway, but would that forward DNS look-up requests as well as checking the gateway's host file? Thank you for your help and your quick response.[ Parent ]
So, with the settings updated the windows machine can ping the gateway, and it can ping the outside world - but only by IP.
That suggests that either the Windows machine has no DNS servers setup, or they are unreachable. I'd suggest you compare them with what the Linux gateway has ("cat /etc/resolv.conf" should tell you).
It could just be that they are bogus .. if not I'd be a little confused.
(I know nothing about xboxes, but buy me one and I'll look into it for you ;) For the moment I'd assume that if DNS isn't working for the windows machine that suggests it isn't working for that either, and that could be the only problem.)
[ Parent ]
[ Parent ]
The gateway should be able to forward UDP traffic to those machines from the LAN. If you set them up for the windows machine it should work - I'm trying to ask you if there are any entries present. Because if there are and they are invalid, or not working, then it seems like the forwarding isn't coping with UDP traffic - or similar.
[ Parent ]
Update your script to include this:
# Allow established connections, and those not coming from the outside iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -i ! eth0 -j ACCEPT iptables -A FORWARD -i eth1 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow outgoing connections from the LAN side. iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # Masquerade. iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Does that help?
[ Parent ]
[ Parent ]
[ Parent ]
Have you tried restarting the ssh server, or verified it is running? Is this on the internal address, or the external one?
[ Parent ]
[ Parent ]
If you can connect via the IP address, but not by the hostname, then that means things are working fine - but your DNS/name lookup is broken.
I guess thats a whole other topic..
Try checking /etc/hosts, or /etc/resolv.conf on the machine from which you're making the connection to look for errors/oddities..
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
You probably need to update /etc/resolv.conf upon the machines on the LAN to match the contents on the gateway machine - which is presumably working?
Failing that more details would be useful..
[ Parent ]
[ Parent ]
Cool, glad it works. I'm hazy on Network manager, and how it works so I'm not sure if your changes will get overwritten (as it threatens) or not. It might be worth a quick google search to see what others say?
I think that the dns-search lines you've added are only going to be used by some DHCP clients, rather than globally. So if they're ignored that might be why.
Finally the IP of the gateway? There is no real standard and you're safe to pick any working IP. (Most of my gateways are the "first" IP rather than the "last" FWIW.)
[ Parent ]
[ Parent ]
root@optimus:/etc/network/if-up.d# ./00-firewall Using intrapositioned negation (`--option ! this`) is deprecated in favor of extrapositioned (`! --option this`).
root@optimus:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere state NEW Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination
root@optimus:~# cat /etc/network/interfaces
#NETWORK
auto lo
iface lo inet loopback
#WAN
allow-hotplug eth0
iface eth0 inet dhcp
hostname "optimus"
#LAN
auto eth1
iface eth1 inet static
address 192.168.0.1
netmask 255.255.255.0
root@optimus:~# cat /etc/network/if-up.d/00-firewall #!/bin/sh PATH=/usr/sbin:/sbin:/bin:/usr/bin # # delete all existing rules. # iptables -F iptables -t nat -F iptables -t mangle -F iptables -X # Always accept loopback traffic iptables -A INPUT -i lo -j ACCEPT # Allow established connections, and those not coming from the outside iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -i ! eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow outgoing connections from the LAN side. iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT # Masquerade. iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Don't forward from the outside to the inside. iptables -A FORWARD -i eth0 -o eth0 -j REJECT # Enable routing. echo 1 > /proc/sys/net/ipv4/ip_forward
[ Parent ]
[ Parent ]
#eth0 auto eth0 iface eth0 inet manual auto dsl-provider iface dsl-provider inet ppp pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf provider dsl-provider #eth1 auto eth1 iface eth1 inet static address 10.10.10.254 netmask 255.255.255.0 network 10.10.10.0 broadcast 10.10.10.255
#!/bin/sh PATH=/usr/sbin:/sbin:/bin:/usr/bin # # delete all existing rules. # iptables -F iptables -t nat -F iptables -t mangle -F iptables -X # Always accept loopback traffic iptables -A INPUT -i lo -j ACCEPT # Allow established connections, and those not coming from the outside iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW ! -i ppp0 -j ACCEPT iptables -A FORWARD -i ppp0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow outgoing connections from the LAN side. iptables -A FORWARD -i eth1 -o ppp0 -j ACCEPT # Masquerade. iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # Don't forward from the outside to the inside. iptables -A FORWARD -i ppp0 -o ppp0 -j REJECT
#eth0 auto eth0 iface eth0 inet dhcp #eth1 auto eth1 iface eth1 inet static address 10.10.10.254 netmask 255.255.255.0 network 10.10.10.0 broadcast 10.10.10.255
#net.ipv4.ip_forward=1 to net.ipv4.ip_forward=1
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Rule that fails to load:
iptables -A INPUT -m state --state NEW -i ! eth1 -j ACCEPT
Changed it into:
iptables -A INPUT -m state --state NEW ! -i eth1 -j ACCEPT
From iptables man page:
[!] -i, --in-interface name
Name of an interface via which a packet was received (only for
packets entering the INPUT, FORWARD and PREROUTING chains).
When the "!" argument is used before the interface name, the
sense is inverted. If the interface name ends in a "+", then
any interface which begins with this name will match. If this
option is omitted, any interface name will match.
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Um, don't you know about the "ipmasq" package? It does all that automatically for you (but is also completely reconfigurable).
Just setup the two network interfaces with the first one as the "outside" one, install ipmasq and you're done!
[ Parent ]