IP tables configuration problem.

[Steven E. Protter]

/etc/sysconfig/itables


# Generated by iptables-save v1.2.5 on Sun Oct 20 02:43:53 2002
*nat
:PREROUTING ACCEPT [11:792]
:POSTROUTING ACCEPT [31:2763]
:OUTPUT ACCEPT [31:2763]
-A POSTROUTING -o eth0 -j SNAT --to-source 66.92.143.194
COMMIT
# Completed on Sun Oct 20 02:43:53 2002
# Generated by iptables-save v1.2.5 on Sun Oct 20 02:43:53 2002
*filter
:INPUT ACCEPT [30:2771]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [38:3507]
:okay - [0:0]
-A INPUT -s 192.168.0.0/255.0.0.0 -i eth1 -j ACCEPT
# IP addy changed to protect the innocent
-A INPUT -d 69.62.173.201 -m state --state RELATED,ESTABLISHED -j ACCEPT

# key section here.

-A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --dport 53 -j ACCEPT

My microsoft clients are having a hard time getting dns resolution when pointed to this Linux machine. eth1 is the internal network, eth0 is the internet.

do I need a line for tcp on port 53 to make the Microsoft clients work right.

A traceroute from the Microsoft client will work, albeit slowly. nslookup works some times other times forget about it. Some web sites load, others, forget about it.

The Linux box itself works perfectly.

Steve

[Trever Furnish]

Stepping back and looking sideways at this through squinty eyes first...

If that's your /etc/sysconfig/iptables file, then you should probably run /sbin/iptables-save first and make sure that the whole file is getting loaded.

Specificly I'm wondering about the COMMIT - I'd expect that to be at the end of the file.

[Steven E. Protter]

I've checked the file and it works.

Some of the notes in the file are because I built the darned thing line by line from a text book.

I've run telnet tests to make sure that blocked ports are actually blocked.

I've noticed one other anomaly, when I try and connect with ssh, port 22 I get connection refused. I've exchanged public keys and don't think I should be getting this error.

Please keep up the good suggestions.

Steve

[Stuart Browne]

*whee!* Asumption city:

You're running a DNS server on this linux box (as you don't appear to be doing any forwarding using IP Tables).

.. blech, the rest can wait.

Given that everying is set to ACCEPT and I see no DENY/DROP rules, you should have no issues *PERIOD* connecting to a running service.

Meaning, if 'named' is running, then it should work.

Now, assuming you do have more rules that you haven't shown us (most likely), the rule's you've shown here say two things.

1) Windows machines on the internal network can make a DNS request from the Linux box.
2) The rest of the world can make a request from the linux bx.

As FORWARD is set to ACCEPT, the packet should get back (unless there's forwarding rules you've not shown us?)

No rules to deny SSH so assuming 'sshd' is running, I can't see a problem.

More details?

[U.SivaKumar_2]

Put the linux server's internal ip address as the default gateway for all the internal windows clients.

regards,
U.SivaKumar

[Steven E. Protter]

I found one problem which was the /etc/sysconfig/network configuration.

I didn't set it, but it had a default pointing toward my cable modem, which I'd like to turn off with its $45 monthly bill.

My gateway IP address for DSL and the web hosting is 66.92.143.193

That's not what was in the file though which was certainly part of my problem

I appreciate the help and to be fair, I'm going to give you everything you need to solve the problem without assumptions.

First the bad /etc/sysconfig/network file

NETWORKING=yes
HOSTNAME='jerusalem.investmenttool.com'
GATEWAY="192.168.0.1"
GATEWAYDEV="eth0"
FORWARD_IPV4="yes"


Bad Steve

Now the correct one.

NETWORKING=yes
HOSTNAME='jerusalem.investmenttool.com'
GATEWAY="66.92.143.193"
GATEWAYDEV="eth0"
FORWARD_IPV4="yes"

Attached is the complete iptables file.

I do apologize for tyring to ask you to solve my problem without providing enough informaiton. Its not like my IP address is private.

Thanks.

[Stuart Browne]

Oo! the fun stuff! :) Just going to comment on a few things, feel free to ignore most of it..

Ok. eth0 is to your DSL, and you should now have one defualt route (RH versions prior to 7.something had a bug in the 'ifup' routines which would add a second default route. This isn't happening, right?). Do you have another (eth2?) for the Cable connection?

IPTables:

*nat: yea, fine. looks good. Use a similar rule here.

*filter:

First rule accepts everything on the 192 block using a 8 bit subnet mask. You should start by reducing this to either a 16 (192.168) or a 24 (192.168.0). As you are saying '-i eth1' though, there's really no need to specify IP addresses at all, as I assume it's your own private network behind that interface?

'-i lo': The only thing that's going to be connecting on the loopback device is 'localhost'. It's logically impossible for anything else to connect, thus the other 3 rules allowing differeing IP's to connect to it are superflous. The '255' one I assume is to get around a DHCP bug which existed once-upon-a-time with '95 machines? Do you have any '95 machines? Also superflous.

icmp/udp: You seem to be explicitly allowing some traffic, yet not stopping any.

You're 'okay' rules look somewhat strange, allowing new and known existing conversations to known ports, yet you aren't making any attempt to block unknown ports.

... Everything looks as if it should work OK from what I can see.

In answer to the question though, No. TCP on port 53 is only required for 'zone transfers'. Unless you are running your own primary DNS, there should be no need for that.

What DNS server are you setting your Windows clients to use?

If it's this linux box, then the rulres are happy. if it's external, then it still looks happy ('-a FORWARD -i eth1 -j ACCEPT', and the reverse RELATED,ESTABLISHED).

Your drop rules are going nowhere near UDP packets so they should be completely unmolested.

As U.Sivakumar said, are the Windows PC's gateway's pointing to this Linux box's eth1 interface?

.. *sigh* I shouldn't post at quitting time .. mind really isn't in the right place .. Anyway, I hope this poitns you somewhat in the right direction.

If your DNS is external, you might be better suited setting up a forwarding-only DNS server locally to do marginal caching, and blocking incoming requests to UDP:53 on eth0.

[Steven E. Protter]

The minute I modified the /etc/sysconfig/network file I pretty much lost network connectivity.

Here are some diagnostics:

[root@telaviv network-scripts]# /etc/init.d/network restart
Shutting down interface eth0: OK ]
Shutting down interface eth1: OK ]
Shutting down loopback interface: OK ]
Disabling IPv4 packet forwarding: OK ]
Setting network parameters: OK ]
Bringing up loopback interface: OK ]
Bringing up interface eth0: OK ]
Bringing up interface eth1: OK ]
[root@telaviv network-scripts]# ping 66.92.143.221
PING 66.92.143.221 (66.92.143.221) from 66.92.143.221 : 56(84) bytes of data.
64 bytes from 66.92.143.221: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from 66.92.143.221: icmp_seq=2 ttl=64 time=0.105 ms

--- 66.92.143.221 ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 999ms
rtt min/avg/max/mdev = 0.105/0.110/0.116/0.011 ms
[root@telaviv network-scripts]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:A0:CC:3D:BA:57
inet addr:66.92.143.221 Bcast:66.92.143.223 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:49017 errors:0 dropped:0 overruns:0 frame:41
TX packets:7691 errors:6 dropped:0 overruns:0 carrier:0
collisions:481 txqueuelen:100
RX bytes:3238349 (3.0 Mb) TX bytes:631057 (616.2 Kb)
Interrupt:5 Base address:0x1000


[root@telaviv network-scripts]# ping 66.92.143.195
PING 66.92.143.195 (66.92.143.195) from 66.92.143.221 : 56(84) bytes of data.

--- 66.92.143.195 ping statistics ---
5 packets transmitted, 0 received, 100% loss, time 4011ms

This is kind of strange. IP forwarding is on yet the display message says, disableing it.

/etc/sysctl.conf

[root@telaviv network-scripts]# more /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) for
# more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
[root@telaviv network-scripts]#

[Steven E. Protter]

I'm thinking this is not really a firewall configuraion issue.

I'd love to see a suggested rewrite on this basis.

I want to use the machine as a router. It needs to provide DNS information to the local network and its a failover server providing DNS services to the public Internet.

Now, if I change GATEWAY parameter in /etc/sysconfig/network to 192.168.0.1

and

/etc/init.d/network restart

Networking works fine.

To act as a router, does the machine have to be 192.168.0.1 ???

I suppose I could set up eth0:1 as a 10.X network and make it the default gateway.

There is a router from the DSL company to handle my IP address block.

Testing is rough if I have to turn off the cable modem router and change this machine to 192.168.0.1 in order to test this out.

Could the problem be a second Linux Box, my production web server which has gateway=66.92.143.193 in its ifcfg-eth0 file?

[Stuart Browne]

It's a RH7.[23] something box, right?

FORWARD_IPV4 in the /etc/syscontrol/network was supposadly deprecated around then some time (it definately is in 8).

After you did the 'service network restart', did /proc/sys/net/ipv4/ip_forward go back to 0, or did it stay as 1?

But not being able to ping your DSL router is somewhat strange. In all honesty, you should be able to get away with the default gw of just the device 'eth0'.

Once it's plugged in, turned on, blah, blah, just try a traceroute to an external, see what you get.

If you don't atleast get to the DSL from the Linux box, then it would appear that either the IP addresses you are using are incorrect, or there's a physical cabling problem (does your DSL use a cross-over cable, or have cross-over port and thus use a straight cable? My DSL router has a cross-over port and a straight cable into my Linux boxen's eth0).

[Steven E. Protter]

My dsl router is a real router and doesn't need a crossover.

There is a second RH 7.3 box sitting right next to the one giving me trouble, hooked into the same 4 port DSL router that can do everything just fine.

Both boxes are RH 7.3 pretty well patched.

I've determined that Microsoft clients get their dns via udp.

This is a networking problem and a vexing one at that.

Can two RH 7.3 machines on the same network have the same default route? I think the answer is yes, surely so for HP-UX.

I copied the following files across made IP number changes and tried restarting networking

/etc/sysconfig/networking
/etc/sysconfig/network-scripts/*

I am certain that there is absolutely no conflict between the two boxes.

I'm really frustrated and don't know whats wrong.

How you doing sir?

Steve

[Steven E. Protter]

/etc/sys/net/ip_foward is 1

a traceroute yields nothing.

I've included a netstat -r output fromt he problem child server.

[Stuart Browne]

Assuming that your two Linux boxen don't both have the same ip address for eth0, then yea. There's no problem with them both having the same default gateway.

It's how large networks work (250 PC's, one defualt gateway).

When you had the IP address of eth0 on the cable address block, it all worked, didn't it?

Just trying to make sure that eth0 in problem-child works.

If the happy-child works when the DSL hub/modem thingie is plugged in, try unplugging that known-working-cable from happy-child and plugging it into eth0 of problem-child.

Rule out problem cabling, and port on DSL.

Compare configurations.. Subnets on interfaces, routes, ip addresses, and maybe even hardware addresses. Make sure that only the hardware/ip's are different for the device, but that the routes are the same etc.

Rule out the firewall completely by turning it off ("service iptables stop"), and try traceroute again from the problem-child.

... blech ... insert more network diagnosis steps here ...

[Stuart Browne]

.. congratulations on the new hat by the way ;)

[Steven E. Protter]

The mystery is unravelled.

Just for grins, I decided to turn off the firewall.

service iptables stop

Ba-bing, the networking works JUST fine.

Time to analyze and rebuild.

Steve

[Steven E. Protter]

keep working this call and you'll earn your next hat right here.

I'm going look back at your earlier information and start rebuilding this iptables configuration line by line if need be.

Thanks for the congrats. Its nice to have someone taking a thoughtful look at this thing, and not giving up on me. I guess the question at hand is what the heck did I do that was incompatible.

I copied the firewall configuration from my working production web server. Just a stupid human trick I'm sure.

Regards,

Steve

[Steven E. Protter]

WhooHoo!

I got it.

Take a looke at the firewall config I posted.

Note all the references to an IP address ending in 194?

Well, this machines address ends in 221, causing all of the firewall problems.

Now its time to figure out whats making snat and all not work.

Steve

[Steven E. Protter]

I'm running a test, here actually accessing itrc.hp.com with the Linux box acting as a router.

nslookup returns no response.

a traceroute gets a good trace after a pretty long delay. I almost have this licked, but I need nslookup response to be better.

I'm thinking about adding a static route from the 192 network to the external network on the Linux Server.

Any other suggestions?

[Stuart Browne]

192.168.x is private. If it goes *over* the router, it'll get chomped.

I'm picking the best bet for a DNS fix is to install the caching nameserver package along with bind, forcing it to listen only on the internal interface ("listen-on { 192.168.whatever; };"), with a forwader to your external address ("forwarders { ext.tern.al.dns; };"). Is what I usually do.

You just need the 'bind' package, and the 'nameserver-cache' (I think it's called) package installed.

[Steven E. Protter]

Stuart,

You have been extremely helpful.

If you could give me a procedure for setting that up, I'd appreciate it.

I dont need some line with MASQ in the firewall? My understanding of iptables says probably not.

Behvavior is strane and should be getting logged somewhere. Every new site I want to browse takes three tries on the tracert then suddenly the lookup works and the site resolves and loads.

I'd love to know what log file to look at because there has to be an error somewhere.

I also had some luck in getting a Microsoft NT Server box to serve DNS lookup for the Microsoft clients. I don't know why it has an easier time getting resolution, but at this point I don't care what works, so long as it works.

I can cut $50 a month out of my monthly cost structure by getting rid of that cable modem upstairs.

Steve.

[Steven E. Protter]

Its all fixed.

For some reason, if you program the local ip as the dns server, you don't get answers.

Once I put in the IP's that the ISP hands out for DNS in the windows client, all was well.

I've tightened up the firewall configuration and can dump the second IP. I'm going to test for a week and make sure its reliable.

Thanks for all your help. It was a pleasure talking with you. Let me know if you're ever in Chicago.

Besides the points, I'd like to buy you a beer.

Steve

[Stuart Browne · Accepted solution]

Caching Name server configuration, simple steps:

install package 'bind'.
install package 'nameserver-cache'.

Modify /etc/named.conf

In the top section (options), put the following two directives:

listen-on { ; };
forwarders { ; };

(yes, with curly braces, and semi-colons).

Start name server service:

chkconfig --levels 2345 named on
service named start

Your local linux box should now be a 'forwarding DNS' (or caching DNS).

Basically, it will service requests, and throw out non-authoritive answers, requesting real ones it doesn't already know from . You can put multiple external DNS server references in that section, so it if has a miss on server A, it'll go to server B.

The listen-on section is axactally what it sounds like; it will listen on this IP address and this IP address ONLY.

Not a source for attack if the external interface isn't listening.

Hope this helps..