Messages

[DNS-CloudFlare tag needs to be set on Host.]

Posting this in case anyone else needs the reference in the future when trying to wrap their heads around how DNSMasq handles static assignments vs dynamic ranges within a subnet.

Hosts:

• .1-.89: Clients Static Reservation, use Pihole
• .90-.99: Clients Static Reservation, use Cloudflare.  DNS-CloudFlare tag needs to be set on Host.
• .100-.150: Clients Dynamic, use Pihole
• .200-.253: Infrastructure/Proxmox Static Reservation, use Pihole

I found that while you can configure multiple static ranges on a subnet, the definition with the lowest Start Address will always override the others since we cannot define an End Address.  This means you cannot have a split DNS assignment within a subnet that is only managed by setting the Tag on the DHCP Range, variance from lowest Start Address Range definition MUST be set on the actual Host configuration itself.  The same thing applies to Blackhole Gateway/DNS, you can logically define a "range" but it must be applied on the Host configuration.

Works:
DHCP Range: LAN-Static-Pihole

• Range Start: 192.168.157.1
• Mode: Static
• Domain Type: Range
• Tag: DNS-Pihole

DHCP Range: LAN-Dynamic

• Range Start: 192.168.157.100
• Range End: 192.168.157.150
• Mode: Nothing
• Domain Type: Range
• Tag: DNS-Pihole

Does not work:
DHCP Range: LAN-Static-Pihole

• Range Start: 192.168.157.1
• Mode: Static
• Domain Type: Range
• Tag: DNS-Pihole

DHCP Range: LAN-Static-CloudFlare - This is ignored

• Range Start: 192.168.157.90
• Mode: Static
• Domain Type: Range
• Tag: DNS-CloudFlare

DHCP Range: LAN-Static-Infrastructure - This is ignored

• Range Start: 192.168.157.200
• Mode: Static
• Domain Type: Range
• Tag: DNS-Pihole

DHCP Range: LAN-Dynamic

• Range Start: 192.168.157.100
• Range End: 192.168.157.150
• Mode: Nothing
• Domain Type: Range
• Tag: DNS-Pihole

I'm going with the alternative of locking the ISC DHCP 4 package and hoping this DNSMasq crap blows over

Not sure what you mean by "blows over", but ISC DHCP is dead, and it's not coming back. If you want a supported solution going forward, your choices are dnsmasq or Kea.

None of the "tag" based designations are intuitive.

I haven't fully tested this, but I think you should be able to do something along these lines (replace 0.0.0.1 with whatever "blackhole" means to you, but note that 0.0.0.0 has special meaning (this host) in dnsmasq)...

Create tags: blackhole_dns, blackhole_gw

Create options:

        Interface: Home
        Type: Set
        Option: dns-server [6]
        Value: 192.168.1.10      # PiHole

        Interface: Work
        Type: Set
        Option: dns-server [6]
        Value: 1.1.1.3

        Interface: Any
        Type: Set
        Option: router [3]
        Tag: blackhole_gw
        Value: 0.0.0.1

        Interface: Any
        Type: Set
        Option: dns-server [6]
        Tag: blackhole_dns
        Value: 0.0.0.1


Create hosts:

        Host: less_trusted_thing_1
        Hardware addresses: ...
        Tag [set]: blackhole_gw

        Host: quest_vr_thing_1
        Hardware addresses: ...
        Tag [set]: blackhole_dns

THANK YOU dseven!  That set of examples helped connect the dots for me this morning and it appears to be working now.

I do appreciatiate the attempts at help.

Thank you for the attempt at "tag" explation, I'm going with the alternative of locking the ISC DHCP 4 package and hoping this DNSMasq crap blows over with the next couple years before an upgrade fails that requires bare metal reinstall.

None of the "tag" based designations are intuitive.

I do not have an overly complex network setup.  I run two local subnets:  Home and Work.

Home
- Uses a pihole DNS server running on a separate Proxmox LXC
- Several less-trusted devices are pointed to a non-existant gateway to prevent external access in addition to firewall rules for multi-tiered restrictions.
- Sometimes setting a DNS blackhole for Quest VR devices that still need local network access

Work
- Uses 1.1.1.3 as DNS server

In using the ISC DHCP v4 configurations (and equivalent) for the past 4 years, I have not had issues with this setup.  However, I started to look into DNSMasq due to the intended migration and for the life of me cannot identify how to setup separate DNS severs per subnet (or client) much less a gateway blackhole.

Am I missing something?  Or are we taking a decades step back in configuration control by moving to DNSMasq?

I also checked OpenWRT and have seen similar configuration issues, so this is not an Opnsense implementation limitation but rather DNSMasq limitations.

Not your network info I requested but instead the information on what the settings required on a router are. Those are useful though, will do for now.

Minor clarification:  Posts 18 and 19 were not from the OP requestor Mister J that you were interacting with.  I am a different user with a working configuration for these servers that the OP should follow if he wants to get this work :)  In hindsight, I should have been more clear about that at the start of post 18.


Summary of issues:

• UT2004 - The 4th port (7788) on Opnsense side of NAT port forwarding was missing.
• Xonotic - Need to add that outbound NAT rule as the tracking server expects the communication to come from a port matching inbound.  Not having this rule results in a randomized outbound port that results in the tracking server not being able to validate his local server is running.
• UrbanTerror - Need to add that outbound NAT rule as the tracking server expects the communication to come from a port matching inbound.   Not having this rule results in a randomized outbound port that results in the tracking server not being able to validate his local server is running.

[UrbanTerror]

UrbanTerror

 Opnsense

NAT Port Forward Rule

• Only 1 UDP port, can be changed at server launch
• Default:  27960

NAT Outbound Rule -- UrT and Xonotic both used Quake3 networking, this applies as well. (https://forums.xonotic.org/showthread.php?tid=7956&pid=84430#pid84430)

• Go to Firewall-NAT-Outbound
• Click  on Hybrid outbound NAT rule generation
• Click +Add
• Interface WAN
• Protocol UDP
• Source Address Single host or Network 192.168.100.142/32
• Source port (other) 27960
• Destination address any
• Destination port any
• Enable Static-port

Proxmox Container (ubuntu 24.04 with ufw)

• Add the following UDP entries to UFW:

• 27960

Have a little patience (few minutes) for the server to then start showing up on the UrT server list.  https://www.urbanterror.info/servers/list/
https://www.urbanterror.info/servers/list/0.0.0.0:27960  <- same drill, replace with your external IP for direct status check.



That should wrap up what is needed for all 3 servers to be fully functional.

~ [LGN]Besalope
LanzGaming.net Game Server Admin (2005 - Present)

[Pass]

Not the exact same config, but when I was setting up Wireguard there was a setup to add a Firewall Rule for that new virtual interface to allow traffic out of the tunnel.


    Go to Firewall > Rules > vpn_wan
    Click +Add

• Action:  Pass
• Interface vpn_wan
• Direction: In
• Protocol:  Any
• Source Address vpn_wan net
• Destination address: any
• Destination port: any

Check if that works, then run a tracert to confirm that the devices' path is flowing through the tunnel as expected.

Edit:  My setup was for a phone/tablet to connect back to Opnsense so that the connection kept traffic "internal."  If this is more of a VPN Service connection, it would be good practice to confirm traffic from the otherside of the tunnel would be blocked for your other LAN interfaces.  That may require adjusting the above policy or secondary Deny rules that take effect first.

[UT2004]

Op / Mister J -- These are the configurations you need in Opnsense and your LXCs in order to get the servers communicating with the master servers:

UT2004


Opnsense

• UDP Port Forwards
• Default:  7777, 7778, 7787, 7788   <-You are missing 7788 in your config which might affect server identification here.
• Firewall > Settings > Advanced:  Make sure the following options for NAT are enabled (reflection for port forward and auto outbound rules)

Proxmox Container (ubuntu 24.04 with ufw)

• Add the following UDP entries to UFW:

• 7777, 7778, 7787, 7788

• 10777, 11777 –LAN-only ports

Add the following TCP Entries to UFW:

• 80 – Webadmin port (ut2004.ini - [UWeb.WebServer] -- ListenPort)
• 28902 – Master Server (outbound) port

UT2004.ini

Code Select Expand

[IpDrv.MasterServerUplink]
ServerBehindNAT=True
DoLANBroadcast=True


Opnsense Portforward Example (Firewall > NAT > Port Forward)

• Interface:  WAN
• TCP/IP Version:  IPv4
• Protocol:  UDP
• Destination:  WAN Address
• Port:  Other – 7777
• Redirect Target IP:  Single Host - 192.168.100.142
• Redirect Target Port:  Other - 7777

This should be created for 7777, 7778, 7787, 7788.

 
This will setup the server to allow external connections and communication with the Openspy master server that you already setup in the ut2004.ini.


(Note, if you also setup the Proxmox firewall for the LXC within the administrative ui.. you'll also need to add the container forwards there as well).


Xonotic

Opnsense

NAT Port Forward Rule

• Only 1 UDP port, can be changed in server config.
• Default:  26000

NAT Outbound Rule  (https://forums.xonotic.org/showthread.php?tid=7956&pid=84430#pid84430)

• Go to Firewall-NAT-Outbound
• Click  on Hybrid outbound NAT rule generation
• Click +Add
• Interface WAN
• Protocol UDP
• Source Address Single host or Network 192.168.100.142/32
• Source port (other) [port of Xonotic Server]
• Destination address any
• Destination port any
• Enable Static-port

Proxmox Container (ubuntu 24.04 with ufw)

• Add the following UDP entries to UFW:

• 26000

It took awhile for the master server list to show the server, but it is now there.  It might help to try navigating to your external IP to check if a record is present:
https://dpmaster.deathmask.net/?game=xonotic&server=0.0.0.0:26000   <- swap 0.0.0.0 for your external IP

Might be a placebo, but my game server only showed in the list after I manually navigated to its entry for external IP.  Arena.sh appears to just be a cache of dpmaster.deathmask.net and there was decent delay (20+ min) between my server showing on deathmask and finally appearing on Arena.sh.


I will test out Urban Terror this weekend, it has been 18 years or so since the last time my group played that at LANs.

I also recently upgraded from 22.1 to 22.7_4 and am seeing similar behavior with the Firewall NAT and Rules section seeming to be disconnected compared to prior functionality.  Even with existing rules, if you toggle enable/disable on the NAT-Port Forward Section it is not cascading to the Rules area automatically.  Or if any existing NAT configurations are changed, the "apply changes" now needs to be executed on both the NAT page and the Rules page independently.