UPnP and VLANs

stephenw10

What do the logs show when you try to start it?

bearhntr

I am a Verizon customer... LOL

It is inside my network - those IPs are not exposed to the Internet. They are subject to change at some point once I get this working.

bearhntr

@stephenw10

This is all I see in the logs that has to do with MiniUPnP

This is GENERAL for when I made the change:

Do not know where to look there is nothing under logs which states UPnP

johnpoz

@bearhntr and what are you not understanding about those errors.. Clearly states contains public IP, should contain private.

100.9.x.x is not some IP range you should be using that is public range.. Use IP range from rfc1918 space - there is lots you can use 192.168/16, 10/8, 172.16/12

Why would you be using 100.9 on an internal network and want that do UPnP?

stephenw10

Yup, it's thowing an error at the public IP internally. Which is interesting.

Gblenn

@stephenw10 UPnP seems to be rather picky about Private vs Public IP...
It doesn't work behind an ISP router providing a Private IP towards pfsense WAN. And I never got it to work with the games that require UPnP, using STUN. However, changing to a Public IP range on the upstream router makes it work just fine, as long as pfsense is in DMZ (or the relevant ports are open at least).
I wish there was some toggle that would allow bypassing those checks...

stephenw10

Yup, code was added upstream for that. Though you can workarund it by manually setting the external address: https://redmine.pfsense.org/issues/10398

Gblenn

@stephenw10 Hmm, that patch may work but it seems like there is only one person who even tried it, and failed?

Anyway, UPnP works fine for me and all gaming right now. BUT, even if there was a simple toggle for the WAN IP check, it will still not work in a failover scenario unfortunately... or is there some way to make it work?

I mean, you can't select the failover Group so when WAN 1 is down, UPnP no longer work...

bearhntr

@johnpoz

I was trying to use something that 'stood out' to me for LAB Addresses - so that I could easily know when I found any traffic - I could say...."Oh, that is the lab". There are many times I have to review (or have reviewed logs by engineers) and wanted to make sure that nothing crazy was in the mix.

So that being said, I have a Server 2019 DC in the mix of the lab. 100.9.28.250 - I also cannot get things working 100% the way I want them,

For example - when I do this on the DC - I get the following:

If I do the same on the lab server itself - I get the following (yes, the lab server is joined to the domain and has the DC as the DNS entry #1 for IPv4 and IPv6) -- the masked IP is the IPv6 of the LAN port in pfSense:

The DC is set to use (IPv4 and IPv6) pointing to pfSense as DNS Forwarder, pfSense is set as below:

bearhntr

@johnpoz

I am guessing I am gonna need to completely rebuilt the DC if I make the address something like 10.100.28.1/24

stephenw10

You need to change the subnet on that VLAN to something in a private range. That would mean renumbering everything using that interface, yes.

bearhntr

@stephenw10

That is gonna be fun - Domain Controllers hate to have their IP changed.

stephenw10

I mean if you actually own that subnet then you can just route to it and UPnP becomes unnecessary. But.......

bearhntr

@stephenw10

Own it? I own it on my home (inside my firewall) network. LOL

I am doing this with the lab domain stuff, because at some point I want to possibly put my WiFi on its own segment (for SmartHome stuff) - seeing how people are persuading me not to use the pfSense box as a WiFi controller AP/router, etc.

johnpoz

@bearhntr if you want something that sticks out then use one of the other rfc1918 address schemes from your other networks use 192.168 on your other networks and 10.x.x on the other..

10.20.30.x would standout I would think ;)

Pulling public space out your u know what and using internally - while technically possible, it almost always going to lead do some issue.

stephenw10

The number of people I've seen using 1.1.1.0/24 still boggles the mind.

bearhntr

@johnpoz

Shame I could not use 10.90.280,xxx LOL

I am still trying to get my head around the IPv6 Private IPs of fdxx:xxxx:xxxx:yyyy:zzzz:zzzz:zzzz:zzzz

I was toying with the idea of fd10:0009:0028:1977:zzzz:zzzz:zzzz:zzzz and let DHCP handle the :zzzz:zzzz:zzzz:zzzz part

I simply do not understand the "Track Interface" to the WAN in the LAN setup well enough to get that part working.

Thanks to you and all others for the input/guidance.

johnpoz

@stephenw10 yeah, which hey if that is what they do fine. But what bugs me is when the same person comes here and wonders why they can't talk to cloudflare for dns ;)

Still in favor of basic network understanding test to even download pfsense ;)

@bearhntr you could for sure use 10.90.280

You can also use whatever local IPv6 range you want that falls in the link-local range fe80::/10 . -Not going to do you any good if you want those clients talking to the internet.. And using a link-local address has zero to do with tracking what gua prefix you get and using one of the subs on lan side interfaces.

Did you want to use the ULA range? fc00::/7

Personally I would get a handle on IPv4 before messing with IPv6 ;)

If you don't like prefixes that change, or the size of the prefix your isp will give you, or if they will give you one at all.. You can always just run a tunnel from Hurricane Electric - they will give you a /48, that never changes. And you can use whatever prefixes out of you want for your networks.. I match them up so they line up with an octet I use out of my IPv4 range. So I can easy look at the prefix and know what network it is since it lines up with the IPv4 I have on that network.

example my lan is 192.168.9.0/24 my IPv6 on that network is 2001:470:xxxx:9::0/64

And the last number matches, so for example pfsense IP on my lan is 192.168.9.253, while its IPv6 is 2001:470:xxxx:9::253

johnpoz

@johnpoz said in UPnP and VLANs:

@bearhntr you could for sure use 10.90.280

Oh just noticed - sorry no you can't use .280, that isn't a valid octet.. You could use 10.90.255 or maybe 10.90.28. would be better and closer

bearhntr

@johnpoz and @stephenw10 and @Gblenn and @WN1X

I changed the VLAN to be another 10.xx,xx,xx/24 segment and UPnP starts up with no errors. Thanks everyone for your assistance. I managed to do it all without breaking the DC either.

NSLOOKUP still does not function properly - it never has since I built the DC (well it works on that server - but nothing else in the lab domain). There are FWD and REV Lookup records in DNS on the DC...but they still do not work. :-(