Ray Olszewski wrote:
At 08:31 PM 10/19/2004 -0400, Sean Covel wrote:
HELP.
I'm not sure if the problem is my LEAF config or the application, but here goes:
LEAF uClibC Bering 1.1, 3 interface setup. Public, Private, DMZ.
The app in question is Azureus 2.1.0.4, a BitTorrent client. BT uses ports 6881-6999. I have port-forwarded the ports to an internal PC on the private network:
DNAT net loc:192.168.1.6 tcp 6881:6999
The client was working VERY SLOWLY so I decided to look at the firewall logs. I recently started blocking out-going ports so I thought I had messed something up. Here is what I discovered:
Oct 20 00:23:16 firewall Shorewall:rfc1918:DROP: IN=eth0 OUT=eth1 MAC=00:03:47:08:40:1a:00:0b:bf:7f:44:a8:08:00 SRC=84.24.193.64 DST=192.168.1.6 LEN=64 TOS=00 PREC=0x00 TTL=109 ID=52587 DF PROTO=TCP SPT=6881 DPT=33649 SEQ=2893004602 ACK=982285315 WINDOW=65535 ACK SYN URGP=0
Oct 20 00:23:26 firewall Shorewall:rfc1918:DROP: IN=eth0 OUT=eth1 MAC=00:03:47:08:40:1a:00:0b:bf:7f:44:a8:08:00 SRC=83.116.64.150 DST=192.168.1.6 LEN=64 TOS=00 PREC=0x00 TTL=112 ID=18647 DF PROTO=TCP SPT=6881 DPT=33660 SEQ=1681451538 ACK=982106032 WINDOW=65535 ACK SYN URGP=0
I'm not sure how the "Peer" is getting my private IP address, but it appears to be?
No. That part is okay. The PREROUTING chain in the nat table does this destination-address rewriting before the packet goes to the FORWARD chain in the default table. The FORWARD chain is what eventually routes this packet to the rfc1918 chain.
And the firewall is doing its job I guess, blocking an RFC1918 address. Anybody got any ideas what's going on here?
Assuming eth1 is your internal interface and that interface actually uses network 192.168.1.0/24, then I find this result odd. But if the host in question (192.168.1.6) is actually on your DMZ, and that interface is eth2, then I **think** the DNAT rule above incorrectly use "loc" where it should use (probably) "dmz". In that second case, rfc1918 is blocking the packets because 192.168.1.6 is not a valid address for the LAN.
The actual details of the problem depend on the specifics of your setup, which you didn't report completely enough.
Ray,
Thanks for your response. Tom Eastep was correct, it was a stale RFC1918 file. The address that the request was coming from USED to be in the RFC1918 range but was recently re-assigned. The NetFilter message was confusing because it was reporting the 83.116.x.x address as the problem and I was assuming it was the 192.168.x.x address. DNAT had already transformed the external IP into the internal IP. Confusing, eh?
I updated the RFC1918 file and all is well!
Thanks all for your help.
Sean
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ------------------------------------------------------------------------ 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
