Public IP -> router(with firewall) -> Linux server(192,168.1.20)

When I place my server behind the router firewall, it lags (30 - 90 seconds) performing the following:

- When I use POP3 to check e-mail from inside of the network
- When using ftp trying to connect to server

While talking to friends they mention that it might be a loop-back issue. And it should solved by doing the DNS inside of the network (on that same linux box).

1- Is that correct?

2- If this is, where do I start?

3 - What is the difference between DNS being performed by a my linux box (server) and let say Network Solutions or Go-Daddy?

No. It doesn't even make sense.

The problem is that the firewall silently drops requests to port 113 (ident). This is a common problem. You can either set up your firewall to REJECT traffic on port 113 (that way you don't have to wait for a timeout) or configure the services on the server to not even send out ident requests. (Not all services can be configured to do that.) Another option is to disallow ident requests to go out from the server in the first place by setting up a local iptables rule (that way you don't have to change anything on the firewall).

Take your pick.

Thanks for the reply. FYI I have a linksys cable/dsl router.

Correct if I'm wrong. Router firewalls should reject all ports except the ones that you allow in, correct?

I' allowing in the following only:
FTP - Port 21 - For Both Protocol TCP+UDP on 192,168.1.20
smtp - Port 25 - For Both Protocol TCP+UDP on 192,168.1.20
HTTP - Port 80 - For Both Protocol TCP+UDP on 192,168.1.20
POP3 - Port 110 - For Both Protocol TCP+UDP on 192,168.1.20

how do you reject (ident) port 113

Yes and no. When I say REJECT I mean what iptables does when a rule has the REJECT target. That is send a TCP RST packet to the host seeking the connection telling it basically "this port is closed". Now since it answered the remote host knows there is a server running on the address it just tried to connect to. That's why most people use DROP as the default meaning the incoming packet is just send to the bit bucket and no response at all is sent back to the connecting system. This is not rfc compliant but most people feel it's more secure since a) a port sweep over a network won't immediately give the attacker a clue as to what addresses are in use, b) a simple port scan will take a lot more time since the attacking host needs to wait for time outs.

What happens when you connect to your server with ftp (or pop3) is this: The client contacts the server, the connection is estalished and the ftp authentication process starts. At this point the ftp server tries to get your remote username via an ident request (that's not the username you want to log in with). This request times out since somewhere between your server and your client there's a firewall that drops tcp packets on port 113. So what you want to do is to send back a tcp RST packet to the server telling it "the ident port is closed". ident seems pretty much useless nowadays since nobody takes the risk to run such a server anymore. Yet a lot of services come preconfigured in a way to try it anyways.

Since I have no idea what your linksys thingy can or cannot do, here's my suggestion: On the linux server set up this iptables rule:

iptables -I OUTPUT 1 -p tcp --dport 113 -j REJECT

On a different note: You can close udp port 21, 25, 80, and 110. It's not needed for the services you run.

I still have the problem of lagging. Being behind the linksys, I had ipchains and iptable services off. But i turned them back on.

On the linkys: switched all TCP+UDPs to only TCP
FTP - Port 21 - For Both Protocol TCP on 192,168.1.20
smtp - Port 25 - For Both Protocol TCP on 192,168.1.20
HTTP - Port 80 - For Both Protocol TCP on 192,168.1.20
POP3 - Port 110 - For Both Protocol TCP on 192,168.1.20T

there were no rules in the iptables, So I added the following:
iptables -I OUTPUT 1 -p tcp --dport 113 -j REJECT
So it looks like this now
----------> iptables
# Completed on Wed Jun 15 23:32:48 2005
# Generated by iptables-save v1.2.3 on Wed Jun 15 23:32:48 2005
*filter
:INPUT ACCEPT [23:1469]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [34:2036]
[3:180] -A OUTPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Wed Jun 15 23:32:48 2005



----------> ipchains
# Firewall configuration written by lokkit
# Manual customization of this file is not recommended.
# Note: ifup-post will punch the current nameservers through the
# firewall; such entries will *not* be listed here.
:input ACCEPT
:forward ACCEPT
utput ACCEPT
-A input -s 0/0 -d 0/0 25 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 110 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 -i lo -j ACCEPT
-A input -p tcp -s 0/0 -d 0/0 0:1023 -y -j REJECT
-A input -p tcp -s 0/0 -d 0/0 2049 -y -j REJECT
-A input -p udp -s 0/0 -d 0/0 0:1023 -j REJECT
-A input -p udp -s 0/0 -d 0/0 2049 -j REJECT
-A input -p tcp -s 0/0 -d 0/0 6000:6009 -y -j REJECT
-A input -p tcp -s 0/0 -d 0/0 7100 -y -j REJECT

Are you sure the iptables rules are actually in use? You said you turned on both ipchains and iptables. I'm not sure you can actually do that. I thought it's either iptables or ipchains. Set up a logging rule in iptables and see if it does have any effect.

When chkconfig --list both ipchains and iptables are are on levels 2345.


Since you said that i did a
/etc/rc.d/init.d/ipchains/ status
I got a status result

But when I
/etc/rc.d/init.d/iptables/ status
I got nothing! No Status

So I went under /etc/rc.d/init.d folder. I have both ipchains and iptables, but the type of ipchains is a plain text document and iptables is a SHELL SCRIPT. Could that have anything to do with it?

Further when I reboot, both ipchains and iptables services load up. Iptables loads first ans it flushes and clears all rules and user defined chains, But iptables just loads without any messages. Is that how it should be?

One more thing

Frankly I am not familiar with their functions. What is difference between the two? Which one should I have on?

.

iptables replaced ipchains with the introduction of linux 2.4 back in... uhh well a long time ago. There were plans to remove backwards compatibility with linux 2.6.9. I'm not sure if that really happened since - as I said - I never followed the "news" on ipchains.

So go with iptables.

You do realize, though, that rejecting ident requests is a workaround for your problem. The proper way to fix this is to find out how to disable it in your ftp and pop3 server. Still, it doesn't hurt to become familiar with iptables...

FYI - Took out my stop watch and did the following:

turned off ipchains service
With a request coming from outlook; timed the pop3 service:

- without the rule of rejecting ident requests - IT TOOK 40 seconds per e-mail

- with iptables -I OUTPUT 1 -p tcp --dport 113 -j REJECT in place IT TOOK 10 seconds per e-mail address.

huge difference. Since I have a bout 15 different addresses coming to me, it's a great time saver!!!

But, It still not fast enough and I am looking around for a solution.

If you figure something out; please let me. Thanks.

FYI - Testing pop3 e-mail retrival period: It takes 8to seconds regardless of the server being outside or inside of the firewall. I guess that is normal.

BY the way, would having the following statement cause any security issues?

iptables -I OUTPUT 1 -p tcp --dport 113 -j REJECT

Thanks for all of your help.