First, you say you are forwarding ports 6000-6999 to an internal host. That's fine. But the tcpdump traffic you report seeing involves (according to your report) *source* ports in that range. Forwarding applies to *destination* ports. Does tcpdump find any packets going *to* 6000-6999 on eth0?
Second, you say the traffic goes to "(what I assume to be) an ephemeral destination port, which in this case happens to be in the 61XXX/udp range". This range is more than happenstance; it is in the range that the router uses for NAT'd connections.
So, what *appears* to be happening is that the router is NAT'ing outgoing connections from the Playstation 2, and remote systems are attempting to reply to the NAT'd ports. Why these attempted replies do not reach the Playstation is not apparent from what you have told us; the earlier suggestion that you need to use tcpdump to look at LAN-side traffic is probably still the right next step. Nor is it apparent why they do not send traffic to destination ports in the 6000-6999 range (or even for sure that they do not, since that traffic might appear elsewhere in your tcpdump outout).
Not being more than casually familiar with the Playstation 2 myself, I can't suggest a fix ... that will require help from someone with more intimate knowledge of the service you are trying to forward. I suspect you're actually plowing new ground, at least with respect to LEAF, and making this service work through a LEAF router will require some research on your (or someone's) part. It may also require that you move from Dachstein to a LEAF variant, like Bering, that uses the 2.4.x kernel and iptables, which offers more flexibility in setting up specialized NATing rules.
Looking at your tcpdump output, Lynn's earlier reference to UDP port 4 was simply a slip of the tongue (or, more apt, the fingers). The 4 in your listings is the packet length, not the source or destination port.
BTW, in all of the above, I've assumed that you are 66-108-7-175.nyc.rr.com, NOT pcp01120514pcs.flshng01.mi.comcast.net . You never actually tell us, and your use of a hotmail e-mail address doesn't help me to guess. If I am wrong in this assumption, I've done the analysis backwards ... ond once again, we've seen the difficulty of trying to troubleshoot based on fragmentary reports from users.
At 10:44 AM 11/16/02 -0500, billy jacobs wrote:
I attached the tcpdump snippet so you can see that there are indeed packets hitting the external interface, with a source port of 6000-6999/udp, and (what I assume to be) an ephemeral destination port, which in this case happens to be in the 61XXX/udp range.
The service being forwarded is the voice chat function in the Playstation2 game SOCOM Navy Seals. As I said in the first message, this service works when I bypass the firewall. Its only when I have the PS2 behind the firewall that I have problems *receiving* voice from other players. At all times, my voice can be sent to other players (since the firewall does not block any *outbound* services).
I have the autofw module loaded, as well as the following:
# lsmod
Module Pages Used by
ip_masq_portfw 2296 2
ip_masq_autofw 2356 0
ip_masq_user 2636 0 (unused)
ip_masq_raudio 2820 0 (unused)
ip_masq_ftp 2352 0 (unused)
wd 4404 1
ne 6276 1
8390 6220 0 [wd ne]
You said I am blocking udp 4...is this a special udp message type or what?
How would I go about opening it and forwarding this type of packet?
Hope this sheds some more light on what I am trying to accomplish, and why it isn't working.
All help is appreciated.
Billy
From: guitarlynn <[EMAIL PROTECTED]> To: "billy jacobs" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: [leaf-user] Simple autofw problem Date: Sat, 16 Nov 2002 01:06:49 -0600On Friday 15 November 2002 19:53, billy jacobs wrote: Comments inline ;-) > EXTERN_UDP_PORTS="0/0_domain 0/0_6000:6999" > INTERN_PS2_SERVER=192.168.1.9 OK, you've opened the 6000-6999 udp port range. > Relevant parts of /etc/ipfilter.conf (added right after other > forwarding 'if' statements): > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > if [ -n "$INTERN_PS2_SERVER" ] ; then > $IPCH -A input -s 0.0.0.0/0 -d $INTERN_PS2_SERVER 6000:6999 -p udp > -j ACCEPT > $IPMASQADM autofw -A -v -r udp 6000 6999 -h $INTERN_PS2_SERVER > fi OK, the port range is forwarded to 192.168.1.9 address. > Output of "ipchains -L -n |grep 6000" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # ipchains -L -n |grep 6000 > ACCEPT udp ------ 0.0.0.0/0 192.168.1.9 * > -> 6000:6999 > ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 * > -> 6000:6999 The changes appear to be active. > Output of "tcpdump -i eth0 | grep "\.6... " (to filter on range): > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 20:26:14.406460 pcp01120514pcs.flshng01.mi.comcast.net.6565 > > 66-108-7-175.nyc.rr.com.61717: udp 4 > 20:26:17.446460 dy251162.resnet.uky.edu.6091 > > 66-108-7-175.nyc.rr.com.61487: udp 4 > 20:26:19.406460 pcp01120514pcs.flshng01.mi.comcast.net.6565 > > 66-108-7-175.nyc.rr.com.61717: udp 4 > 20:26:24.396460 pcp01120514pcs.flshng01.mi.comcast.net.6565 > > 66-108-7-175.nyc.rr.com.61717: udp 4 > 20:26:27.446460 dy251162.resnet.uky.edu.6091 > > 66-108-7-175.nyc.rr.com.61487: udp 4 Ok, your blocking udp 4. This port is not opened much less forwarded. I'm not sure how this applies to your added configuration. > Any ideas? Help would be appreciated. It would help if we had any idea what you are attempting to forward service wise. I'm not clear on what you are attempting to show with the tcpdump. Have you loaded the autofw module? More information is requested so we can atleast make a guess at what the problem may be.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
------------------------------------------------------------------------
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
