Don't forget to turn forwarding on too.

sysctl -w net.ipv4.ip_forward=1

Johnny Hughes wrote:

You need to do ip-masquerading to pass traffic thru a linux box as a gateway. That requires 2 NICs and an iptables script which does masquerading

I use this script to setup that kind of box: http://ldp.hughesjr.com/HOWTO/IP-Masquerade-HOWTO/stronger-firewall-examples...

To the list:

HOW-TO on DNS + DHCP + SQUID + Firewall + Router

Since this seems to be a recurring topic:

Thought you might be interested in a working set up of DNS + DHCP + SQUID + Firewall + Router machine that took quite an effort to get working but now runs flawlessly.

Don't get discouraged. This takes some time to set up correctly but once you get through it - it works great!

Remember: tcpdump is your friend!!!!

Anyone having a network internally that needs these features should continue reading:

We set up a new firewall based on CentOS 3.3. (3.4 should work fine)

We needed it to serve many protocols internally.

The specifications for it are:

NOT Microsoft based (We are a MS Partner with all the software but I wanted something that was MS virus proof)

KDE Graphical Firewall Control External Internet LAN Port x 1 Internal Networks x 2 (more can be added) -> we used 192.168.0.X and 192.168.1.X DNS Name Caching Server - internal and external, forward and reverse lookups DHCP Server that does ddns-update internally Squid Server IP Masqerading Routing between all networks

Hardware:

OLD P3-800 Based System (Only non AMD system we run) 3 x Intel Pro 100 NIC's (We have a big box of these) 1GB SDRAM 40GB IDE Disk CDROM Drive Floppy Standard PC Case with extra cooling and 400 w ps.

This hardware is overkill as it never runs above 30% load. Any machine supported by Centos with > 600 MHz CPU and 512M Memory should do.

Software:

Centos 3.3 Full Install (Lessens the chance of missing packages)

Guarddog Firewall RPM for Centos (http://centos.hughesjr.com/3/guarddog/RPMS/) Guidedog router/masqerader RPM for RH9 (works fine) (http://www.simonzone.com/software/guidedog/guidedog-1.0.0-1_rh9.i386.rpm)

Squid source tar ball.

First install Centos and set it for a KDE graphical boot up. Turn off all services not used Leave Iptables on but turn off IP6tables

Then Install Guarddog Then install Guidedog Configure both of the above - read the instructions for these carefully. - questions for these should go to the writer or his mail forum - Make sure to enable DHCP for eth1 and eth2 BUT NOT eth0 (external LAN NIC)

Make sure you can see the internet from the inside LANs with the clients set to use static IPs.

NEXT ---

Please read the instructions on how to set up DHCP and bind(DNS) here:

http://integratedsolutions.org/downloads/DHCP-DDNS.txt

Read this multiple times and make sure you understand it!

Cut and paste can be an enemy. Be careful which editor you use

This set up allows us to have any number of machines on our internal network automagically connected to each other and the internet with all the IP information coming from our firewall / router / masquerader / squid server.

It works for forward and reverse DNS internally for Windows and linux clients and servers.

It also speeds up client internet traffic by caching most outside pages.

Install squid per the INSTALL in the src tar ball and add a startup entry to either chkconfig or rc.local. We set it to use 5 GB of disk cache and start automatically at boot time. We used the standard proxy port.

We configured squid using webmin and this works fine.

We added Webmin just to see how well it works: It can break DNS and DHCP easily if you are not careful but it was helpful getting squid working.

Read up on syslogd and change the config file (or use webmin) to rotate logs every day and keep 7 to 14 old logs for back checking purposes. This will limit log size and make it easier to find any problems.

Your milage mary vary.

Standard software disclaimer applies.

If this is helpful drop me an email so I know.

If this needs work drop me an email with specifics.

We will be adding a knowledgebase to our website with complete instructions for this in the next few weeks.

Best

Seth Bardash

Integrated Solutions and Systems

seth@integratedsolutions.org

719-495-5866

Failure can not cope with perseverance!

Johnny Hughes wrote:

<snip>

You need to do ip-masquerading to pass traffic thru a linux box as a gateway. That requires 2 NICs and an iptables script which does masquerading

I use this script to setup that kind of box: http://ldp.hughesjr.com/HOWTO/IP-Masquerade-HOWTO/stronger-firewall-examples...

Is it absolutely necessary to use IP-Masq / NAT in order to setup Linux as a Router?

I'm trying to setup a few Linux machines (Centos of course) as convential routers as opposed to Gateways so that I can learn more about routing between them on various Subnets.

All the How-To's I've found talk about Masq, I would appreciate if anyone can point me in the direction of a convential Linux router howto.

Thanks in advance

Regards

Lee

From my firewall script in BASH lines like this is what you should be thinking of using:

iptables -t nat -A POSTROUTING --source $LAN_IP_RANGE --out-interface $EXT_IFACE -j SNAT --to-source $EXT_IP

Lee W wrote:

Johnny Hughes wrote:

<snip>

...

You need to do ip-masquerading to pass traffic thru a linux box as a gateway. That requires 2 NICs and an iptables script which does masquerading

I use this script to setup that kind of box: http://ldp.hughesjr.com/HOWTO/IP-Masquerade-HOWTO/stronger-firewall-examples...

Is it absolutely necessary to use IP-Masq / NAT in order to setup Linux as a Router?

I'm trying to setup a few Linux machines (Centos of course) as convential routers as opposed to Gateways so that I can learn more about routing between them on various Subnets. All the How-To's I've found talk about Masq, I would appreciate if anyone can point me in the direction of a convential Linux router howto.

Thanks in advance

Regards

Lee _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Peter Farrow wrote:

You might also find this useful....

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html

Thanks for all the links, although I don't think they are what I'm after.

What I'm trying to do is setup something which ( I guess) is something similar to that which an ISP may have. For example

ISP External Interface = 55.20.0.2 / 255.255.0.0 Client 1 external interface = 56.1.1.2 / 255.255.255.0 Client 2 external interface = 56.1.2.2 / 255.255.255.0

Each of the clients are running a server on 56.1.x.4 which needs to have a public IP (e.g. an SSL web server) therefore NAT of any kind cannot be used.

The ISP central router is responsible for directing the packets at the correct client router with I guess some form of routing table (but I haven't got that far in my studyies yet).

Hope this helps to clarify.

Regards

Lee

Lee W wrote:

Peter Farrow wrote:

...

You might also find this useful....

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html

Thanks for all the links, although I don't think they are what I'm after.

What I'm trying to do is setup something which ( I guess) is something similar to that which an ISP may have. For example

ISP External Interface = 55.20.0.2 / 255.255.0.0 Client 1 external interface = 56.1.1.2 / 255.255.255.0 Client 2 external interface = 56.1.2.2 / 255.255.255.0

I take it that you have an ISP gateway and then a bunch of ip ranges assigned to you by your ISP?

Each of the clients are running a server on 56.1.x.4 which needs to have a public IP (e.g. an SSL web server) therefore NAT of any kind cannot be used.

The ISP central router is responsible for directing the packets at the correct client router with I guess some form of routing table (but I haven't got that far in my studyies yet).

If your box has a link on 55.20.0.0/255.255.0.0 and then more physical links to 56.1.x.0/24 individually (machines on two separate physical networks) or one more physical link to 56.1.1.0/23 (all machines on one physical network and you are going to assign ips from 56.1.1.x and 56.1.2.x) then all you need is setup the default route of the box to 55.20.0.2, enable ip forwarding and then point the default route of all clients to the box's corresponding ip on their subnets (eg: two physical links, 56.1.1.1 and 56.1.2.1) or on their subnet (only one physical link, 56.1.1.1)

If you want to control what packets get through the box, use the iptables -t filter FORWARD chain.

Lee W wrote:

Feizhou wrote:

...

If your box has a link on 55.20.0.0/255.255.0.0 and then more physical links to 56.1.x.0/24 individually (machines on two separate physical networks) or one more physical link to 56.1.1.0/23 (all machines on one physical network and you are going to assign ips from 56.1.1.x and 56.1.2.x) then all you need is setup the default route of the box to 55.20.0.2, enable ip forwarding and then point the default route of all clients to the box's corresponding ip on their subnets (eg: two physical links, 56.1.1.1 and 56.1.2.1) or on their subnet (only one physical link, 56.1.1.1)

If you want to control what packets get through the box, use the iptables -t filter FORWARD chain.

That is what I thought, but it doesn't seem to be working.

Here is the routing table of the Linux Router box

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 green 192.168.8.0 * 255.255.255.0 U 0 0 0 red 169.254.0.0 * 255.255.0.0 U 0 0 0 green default 192.168.8.2 0.0.0.0 UG 0 0 0 red

You have private ips. These are not routable on the Internet.

I've given the real IP's this time as it is only a virtual machine. The names probably say enought but to clarify 192.168.8.0 is the Public facing subnet (what would be in the ISP Cloud I guess), with 192.168.8.2 as the default gateway, this is pingable from the router. 192.168.1.0 is the private subnet with 192.168.8.254 as the routers internal IP. Workstations can ping the internal IP of the router but not anything outside, nor does a traceroute work.

Your ISP has not given you *any* routable ips. Any natting will have to be handled by your ISP.

IP Forwarding has been enabled by: "sysctl -w net.ipv4.ip_forward = 1"

The iptables rules are all clear as follows:-

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

Here is the routing table from the client machine:-

Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

From what you have said this should work fine, but I'm clearly missing something obvious that I just cannot see.

Yes, you are missing Internet routable ips. If your ISP says these are routable, the ISP is lying.

Lee W wrote:

Hi Feizhou,

Sorry, I did put it in my previous reply but I guess I didn't specify it in enough detail.

This is a purely a virtual setup (using VMWare) so I know the IP's are not public. But I should still be able to route across two of my own private subnets.

I think I may have determined what the problem may be. My real router with which the PC my virtual machines are running on is connected is showing spoofing attempts in the logs so I think this could be getting blocked. I'm going to try and install a third virtual machine and see if can route to that from the original workstation though my virtual linux router.

Thanks for the help so far.

Regards

Lee

Yep, it turned out to be something to do with the real router. I setup a third virtual machine and was able to get all 3 VM's to talk to each other happily. I may even try that try that 3rd machine as a NAT router now and see if that works.

Thanks for all the suggestions.

Lee