Ok Tom you asked for that output here it is. You might have to open it on a unix machine. Ray, we are not working this issue off-list. I sent one email offline, but that wasnt on purpose. I would also like your input cause you have offered up some good sugestions that have been helpfull.
OK. Let's review what we have.
1. You have a DNAT rule that looks right on its surface, and that does match 1 packet. To wit (from nat::net_dnat, called by nat::PREROUTING):
1 38 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:27015 to:192.168.1.3
Since the packet size looks right (see item 3 below), I infer that the one packet it did match was legit. (An earlier rule in the table causes this rule to be applied only to packets that originate on eth0.) Since this rule, semingly, *sometimes* matches, it might be a useful diagnostic to log the traffic it does match.
2. You have some traffic dropping through to the default::net2all chain; this rule logs it:
1512 63474 ULOG all -- * * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix `Shorewall:net2all:DROP:' queue_threshold 1
I doubt all the 1512 logged packets are to port 27015 (especially since the net2all logging included in the attachment is all different destination ports ... BTW, why do they all have a "Jan 4" timestamp?), but I'll assume some of them are and the attachment you sent just does not list them.
3. In a prior message, you sent this sample log output from the above rule:
aids Shorewall:net2all:DROP: IN=eth0 OUT= MAC=00:50:fc:99:90:89:00:01:5c:22:02:82:08:00 SRC=172.192.116.7 DST=12.212.68.51 LEN=38 TOS=00 PREC=0x00 TTL=114 ID=4266 PROTO=UDP SPT=1219 DPT=27015 LEN=18
(You resent this in a more recent message too.)
As Tom noted, this certainly appears to match the DNAT rule in item 1, and there is nothing preceding that in the nat or mangle table that should interfere with its arriving at that rule. The only thing I can think to double check here ... and this is grasping at straws, really ... is to verify that the MAC address is right ... that is, that the first 6 bytes of MAC= match your eth0 NIC (as reported by "ip addr show").
Oh, I am now assuming that 12.212.68.51 is your primary IP address on eth0.
And BTW, why doesn't this log entry have a timestamp before the "aids" entry ... are we sure it comes from the *current* version of the Shorewall rulesets (the set we are troubleshooting)?
4. As a matter of curiosity, I checked the source address in item 3 and found (via an incomplete traceroute, stopped by a !H, and a reverse lookup) that it is an AOL address. Since AOL remains notorious for doing weird thing with traffic, I mention this on the chance that it will suggest something specific to Tom (or someone else here). Josh, you should probably tell us if the AOL connection is common to all the packets the nat-table rule misses or if this is just a fluke, limited to the sample log entry you provided.
Last comment: I just saw Tom's latest reply, and from it I infer that he is seeing different output than what I saw. (He mentions 2 packets DNAT'd but I see only 1 in what I reviewed, for instance.) It really helps diagnosis if he and I both look at the same information, Josh.
Oops, a post-last comment: Although Tom suggests using attachments, you found they cause you problems with the leaf-user list. Since this is all plain text output, I suggest you just include it in the body of your messages in the future.
[old stuff deleted]
------------------------------------------------------- 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
