Quoting Jeremy Chadwick <[EMAIL PROTECTED]>:
On Thu, Oct 30, 2008 at 01:36:58PM +1100, Terry Sposato wrote:
Quoting Jack Barnett <[EMAIL PROTECTED]>:
yes, that is my setup.
hrm... well, I disabled the firewall completely, restarted, but still
doesn't work.
I have gateway and natd both enabled. x10 is the "external" interface
(the one that is dhcp and connects to the cable modem).
I don't want to redirect anything to my windows box. I just want
anything that connects out from my windows box to be able to connect
or send data back in.
For example, I load up a client (game) and it connects out on XYZ
port. The server will send data back on ABC.
The problem, from what I can tell; is that I can get a connection out
- but when the server tries to send data back on ABC it is discarded.
Polytropon wrote:
If I understood you correctly, your setting is:
(Modem/Router)---DHCP---(FreeBSD)---("Windows")
I may respond directly on your configuration settings:
On Wed, 29 Oct 2008 20:19:31 -0500, Jack Barnett
[1]<[EMAIL PROTECTED]> wro
te:
gateway_enable="YES"
#firewall_enable="YES"
#firewall_type="open"
firewall_type="simple"
#firewall_type="open"
firewall_logging="YES"
Use instead:
gateway_enable="YES"
natd_enable="YES"
natd_interface="xl0"
You may add special redirect directives to NATD's settings, such
as
natd_flags="-redirect_port tcp 192.168.1.2:5900 5900"
natd_flags="-redirect_port tcp 192.168.1.5:23 6666"
or
natd_flags="-redirect_address 192.168.1.2 141.44.165.58 \
-redirect_address 192.168.1.5 141.44.165.58"
Examples taken from a very old configuration. :-)
Then,
firewall_enable="YES"
firewall_type="/etc/ipfw.conf"
Then, be sure to have nice firewall settings, you can use things
similar to this, enabling just the services you really need and want,
it's easy to write your own one or to rewrite this:
-f flush
add divert natd ip from any to any via xl0
add allow tcp from any to any ftp in recv xl0
add allow tcp from any to any ssh in recv xl0
add allow tcp from any to any auth in recv xl0
add allow udp from any to any ntp in recv xl0
add allow udp from any to any ntalk in recv xl0
add deny udp from any to any x11 in recv xl0
add reset tcp from any to any x11 in recv xl0
add allow ipencap from any to any
add allow ip from any to any
This should work fine. NB to use the correct interface names.
References
1. mailto:[EMAIL PROTECTED]
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
Jack,
It is most likely caused by your ruleset not being stateful. If packets
are going out certain sessions and your firewall isn't then allowing back
in you would see the issue you are seeing. I am not sure how this is
accomplished via ipfw as I use pf but there would be a tonne of
documentation out there on how to make your rules stateful.
Are you sure about that? Read his statement once more:
For example, I load up a client (game) and it connects out on XYZ
port. The server will send data back on ABC.
Ahh yes correct, I was going on the assumption that the traffic is
trying to return using the same session details. This is usually how
it is with gaming traffic and the non stateful ruleset is usually the
cause of why this sort of traffic get's blocked. Would like to see if
the OP has actually sniffed the traffic and can say without a shadow
of a doubt that different ports are being used ingoing & outgoing.
I assume based on this, the following is happening:
- 192.168.x.x:aaaaa sends packet to gameserver:xyz
- NAT gateway translates packet (where "natgw" is a public WAN IP)
192.168.x.x:aaaaa <--> natgw:bbbbb <--> gameserver:xyz
- gameserver sees packet to port xyz, and initiates new connection
to natgw:abc
- NAT gateway drops packet destined to WAN IP port abc, because the
gameserver:abc connection is *new*, and does not relate to the
previous NAT'd gameserver:xyz connection.
If this is **truly** how the protocol works (the OP will need to be
absolutely 100% positive of that fact; I recommend he reconfirm how it
works), then the only solution is to set up a port forward on the NAT
gateway for port abc to point to 192.168.x.x.
This also means that only one computer on the LAN will be capable of
playing this game. Not much one can do about that, other than write
the authors of the game and explain that their protocol is absolutely
disgusting.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Regards,
Terry Sposato
[EMAIL PROTECTED]
Have you been sucked in?
http://www.sucked-in.com
-------------------------------------------------------------------------------------
This message was sent from the Sucked In Webmail Interface -
http://www.sucked-in.com
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
