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

    Supreme Commander , Static UDP Port problem *SOLVED*

    Scheduled Pinned Locked Moved
    Gaming
    2
    5
    9.5k
    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.
    • GruensFroeschliG
      GruensFroeschli
      last edited by

      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

        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
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          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
          • GruensFroeschliG
            GruensFroeschli
            last edited by

            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

              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
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.