• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Supreme Commander , Static UDP Port problem *SOLVED*

Scheduled Pinned Locked Moved Gaming
5 Posts 2 Posters 9.6k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G
    GruensFroeschli
    last edited by Sep 4, 2008, 12:21 PM Apr 2, 2007, 9:39 PM

    setup:

    ADSL-Modem(with NAT)  –------  Pfsense (1.0.1) --------------------------- LAN
      (192.168.1.1)                WAN(192.168.1.6)  LAN(172.17.100.1)

    Every Port on the modem is mapped to 192.168.1.6 (default)

    Since a while i'm Playing Supreme Commander.
    A few friend from university and i tried to play a multiplayergame.
    everyone need's to be able to connect to everyone.
    so everyone of us opened TCP/UDP port 6112, UDP 9103, UDP 30350-30351
    we are 2 ppl who use pfsense and only we two have this problem.
    when one of us who uses pfsense hosts the game everything work ok. all can connect except the other person who uses pfsense. everyone can connect to the server, but the other person with PFsense connot be reached by the other 2 ppl.

    there is a tool called NATTrace
    http://cavesvr.caverock.com/~andrew/nattrace/

    even when everyone can connect to the server this tool say's: "NAT is availlable but port not mapped"
    TCP works but not UDP.

    so i've made a CARP-VIP on WAN side (192.168.1.2)
    mapped the ports on the modem needed for the game to 192.168.1.2
    and made a 1:1 NAT from 192.168.1.2 to the IP of the computer on the LAN and removed the normal NAT mappings

    –> it worked.

    i thought that maybe the "default"mapping of the modem is broken.
    so i changed the mapping to 192.168.1.2 to 192.168.1.6 and removed the default mapping
    removed the 1:1 and added normal mappings for the ports on pf.
    --> not working again with normal NAT

    this is a workaround that is ok for me.
    but i'm just curious as to why this is happening.
    is 1:1 NAT and normal NAT somehow different?

    greeting
    matthias may

    We do what we must, because we can.

    Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

    1 Reply Last reply Reply Quote 0
    • H
      hoba
      last edited by Apr 2, 2007, 9:51 PM

      When using 1:1 nat pf doesn't scramble ports outbound. The default outbound NAT DOES scramble ports for additional security. Some applications and protocols don't like that (SIP for example hates it). Search the forum for "static port" and create an advanced outbound nat rule accordingly. I guess that should fix the problem that you are seeing.

      1 Reply Last reply Reply Quote 0
      • G
        GruensFroeschli
        last edited by Apr 2, 2007, 10:26 PM

        thanks for the fast answer :)
        now when i think about it, i noticed in the log of NATTrace that it said something about communication happend but on the wrong port.

        thank you /bow

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • G
          GruensFroeschli
          last edited by Apr 3, 2007, 5:18 PM

          i have another question.
          how exactly does pf behave when 2 clients try to establish an outbound connection on the same port and there are rules for static port in place?

          is pf able to "merge" the two connections somehow or does it assigne the second connection just to another port?

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • H
            hoba
            last edited by Apr 3, 2007, 5:25 PM

            Not sure about that. Maybe it will work as long as the external destination IPs are different. Try it and watch diagnostics>states and let us know  ;)

            1 Reply Last reply Reply Quote 0
            1 out of 5
            • First post
              1/5
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
              This community forum collects and processes your personal information.
              consent.not_received