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).