OK, what I thought would be a simple autofw problem turns out to be much more in-depth than I thought it would be. My slip up is that I assumed that I could forward based on the source port, and not the destination.

You are absolutely correct -- I am "plowing new ground" here, because there is very limited information on exactly how this service works. From all the documentation I found on the web (almost all from end-users), they are all using linksys routers (or similar devices), and their end-all answer is to "put it on the DMZ". I was trying to avoid setting up any kind of DMZ setup off my router. The only IP-specific (and not router model specific) information I have found is to simply forward 6000-6999/udp to the PS2. Of course, they never mention if thats a source port or destination port, but going by the tcpdump trace, I can only assume its a source 6000-6999/udp. Again, lack of techincal specifics on how this service works is holding me back.

You were correct to assume that my address is the rr.com address. I apologize for not going much more in depth when I started out this thread, because as I said, I thought it would be much simpler (incorrect ipchains syntax, for example). I was actually a little unsure about just posting only the "relevant" parts of network.conf and ipfilter.conf. From reading prior posts, at least for me, its very easy to get lost in all of the extra information presented when people post complete conf files. So that is my fault for not giving at least a little more detail on my setup.

I assume with iptables, the --source-port and --dport would be the keys to doing what I am trying to do. They would allow me to specify packets which match the source ports I am looking at and forward them to an internal host. IPChains/IPMasqadm don't have this functionality built in, right?

It sounds like I will have to take this discussion off-line and do some research on my own. I appreciate all the help and explanations you guys have given.

Billy

_______________________________________

Please explain a bit more carefully what you are trying to accomplish. There are two items of significance in what you've told us that require clarification. (And it appears that your calling this problem "simple" in the Subject line is a bad call ... but read on.)

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 -0600

On 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]
-------------------------------------------------------------------------------



_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail



-------------------------------------------------------
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

Reply via email to