At 03:24 AM 1/3/2004 -0500, Gene Smith wrote: [...]
Here is the reject messages I see often in /var/log/syslog:
Jan 2 23:23:07 firewall kernel: Shorewall:all2all:REJECT:IN= OUT=eth1 SRC=66.168.89.166 DST=209.225.8.77 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=12320 PROTO=TCP SPT=2953 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
Jan 2 21:30:01 firewall kernel: Shorewall:all2all:REJECT:IN= OUT=eth1 SRC=66.168.89.166 DST=216.34.94.184 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30768 PROTO=TCP SPT=1590 DPT=25 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0
SRC=66.168.89.l66 is my LEAF box internet interface. The DST=209.255.8.77 is my ISP's smtp server (smarthost) and DST=216.34.94.184 is mydomain.com in the 2nd example. Destination port is 25 in both cases.
Here is my shorewall rule that I think allows a connection to any port 25 on the internet from the f/w:
ACCEPT fw net tcp smtp
With this rule, why would connection attempt to my ISP be rejected by f/w? Yet I am sure a connection does occur since I can use qmail as my smtp server in mozilla to send mail (at least until the /var/log goes to 100%).
Well, the place to start is: why does the firewall want to route them out eth1? Are you using a non-standard external interface (LEAF systems usually use eth0 for "net") or is there some problem with the LEAF router's routing table?
If the first ... did you make the needed changes in Shorewall so it knows that "net" refers to eth1?
I set up LEAF/Bering over a year ago and kept the interface names the same as a previous old LRP system that someone else did for me many years ago. It does have the default eth0/1 swapped but "net" is set to eth1 and "loc" to eth0 in /etc/shorewall/interfaces.
Anyhow, I am now sure that the f/w REJECT is a red herring and due to operator error (me). It occurred because I did not have the smtp outgoing rule shown above entered into shorewall and the repetitive attempt by something to send emails to mydomain.com was triggering it. The REJECTs all occurred before shorewall was restarted with this additional rule added to the file.
Depending on what eth1 is, we need to see either your in-place rulesets ("shorewall status") or your routing table ("netstat -nr") to figure out what is up.
Because the rest of your questions (deleted here) were specific to qmailm not routing/firewalling questions as such, I'll leave them for someone who uses qmail to answer.
With the outgoing smtp rule removed from shorewall, I should be able to find where qmail queues the messages and see what is being sent to mydomain.com.
Thanks you again for the help Ray. And thank you Shed. for info on fs memory allocation.
-gene
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
