@tomsawyer2k5 other than maybe setup a new machine with the software.. I would assume it should have the details to login built in, or ask the user for the info, like their username and password, etc.. For all we know the machine that was not working, they put in some bad info when it asked them.. Typo'd IP or fqdn they were suppose to put into the config on setup, or username/password, etc.

@Jarhead i limit both internet access and inter vlan communication. I think the complete ruleset would be a bit much :) In principle, there are rules that, for example, allow all devices in the home VLAN to access destinations on the Internet via HTTP/HTTPS, but there are also rules that allow all devices in the home VLAN to access services in the other VLANs. For example, all devices may contact the NTP server in VLAN X on UDP 123. However, I now have to maintain the same rules for the Wireguard VLAN, as these are virtually the same for me as if they were devices from the home VLAN. So now I also have to create a rule that allows all devices from the Wireguard VLAN to access destinations on the Internet via HTTP/HTTPS or the rule that they are allowed to access the NTP service in VLAN X. That's what I mean by ruleset copy. If I now create a new rule for the home VLAN, e.g. that they are allowed to access a DNS in VLAN Y, then I must also create this rule for the Wireguard VLAN. This is a bit tedious. It would be better if I only had to create a rule for the home VLAN and didn't have to worry about creating the same rule for the wireguard VLAN. I don't see how aliases could help me in this case. Maybe i have to mention that all subnets are on different physical interfaces. So basicly each subnet/vlan has its own physical network interface.

@adude42069 Don't confuse random, ephemeral source ports (which is the scope here with the random port translations in outbound NAT) with destination ports on which services are listening for connections (Which is the scope of IANA registration).

@johnpoz Thanks for the reply. The metro interface address at building A is 192.168.0.252. Building A WAN address is the ISP address, building B WAN is 192.168.1.252, the gateway IP assigned to the metro at that location. I know the setup isn't correct. I should have the firewall address as the gateway with a route to other networks setup such that all traffic not seeking another network, just goes out the WAN address and when traffic is seeking an internal network, it gets properly routed. However, when I do that, it doesn't work. I think it's because I have yet another pfsense firewall at another location with it's own ISP/WAN. Dual WAN's from a single exit point are easy, but I haven't figured out how to make it work reliably if one ISP goes down to send traffic out of another networks WAN. For now, it "works", I'm trying to see if I can solve this one issue and clean up the rest down the road. Thanks.

@Gertjan It was standard sutiations, ISP support didn't understood pfsense so they told me that i must make port forward like on ptlink but issue was that they forgotten disable firewall on router. Since it was on bridge mode but firewall blocked input.

@scapino So you have network 192.168.2, and a network 192.168.0 on pfsense.. There is nothing to do, pfsense auto connects networks it directly attached too. If you want some client on network A to talk to network B that are both attached to pfsense, you would need your firewall rules to allow for it. You would have to bypass any policy routing you might be doing that shoves traffic out a gateway or vpn. And the destination IP would have to be using pfsense as their gateway, and their host firewall would have to allow the traffic from this other network.

I definitely haven't ever had issues registering Yealinks phones, we aren't using FreePBX though, I think maybe change the post title to be about 3CX? Doesn't sound like a Yealink specific issue to me. As for why it worked on the Sonicwall, this is one of the reasons I don't like sonicwall and most other "enterprise" firewalls, they do too much for you "automagically" so then when things don't work it's hard to know why; since we can't always know why it worked in the first place lol. Anyway, anti-Sonicwall rant over. So some devices register fine, do they make calls OK or just register? Same subnet and all that I presume? If you do a pcap, can you see the Yealinks trying to reach out on 5060 and just not getting a response?

@Djkáťo The one and only question that answers your question while answering me : do you have a working Internet connection ? If yes, then nearly all is fine, and you can stop looking, as you've already mentioned what your current situation is : its doesn't break your internet access if your WAN IP is a RFC1918. But you can probably forget about NATting so you can make internal (on the pfSense LANs) devices accessible from the Internet, as you have no access to the ISP equipment to do so. If your "TP-Link Archer VR300" is truly working as a modem, its just converting POTS VDL signals to "Ethernet" signals and it doesn't do routing , firewalling etc. Its not the "TP-Link Archer VR300" that has a WAN, and a DHCP server that gives you the "10.101.37.22" pfSense WAN IP : this "10.101.37.22" comes from way up, somewhere from the ISP. Why they do so ? There is the classic $$$ rule : they have no more free routable IPs left as IPv4 free available stock has been sold out meany year ago, and what's left has a huge price tag. Its seen before ; you want a real routable IPv4 ? You $$$ or €€€.

I have noticed that the Unifi Controller software has become increasingly dependant on background links "phoning home". Last time I ran a local traffic audit I found packets from the controller to muliple mystery sites. After adding firewall rules to block the traffic, I found I could no longer adopt new devices. Maybe check the current documentation for your controller version for required TCP and UDP ports. cheers

@NickJH This would require options to state external and internal ports and the proper rule association for each. A bit complicated and it's not, what NAT 1:1 is meant for. The sense of 1:1 is to map in external IP to an internal and also the other way round. While port forwarding is meant to what it's name implies. And if you forward a port to an internal IP you usually also want to pass this certain traffic.

@rjcab said in Issue to manage pfsense from internet: It accepts when I do from LAN but no from WAN whereas traffic seems come in :-) And that's a pretty good default security setting. But you've decided to admin this device also from 'the internet'. I'm pretty sure the device has settings, so it's time to inform the device it should also accept connection from the Internet. Exactly like "MS RDP".

@Gblenn Great suggestion! That is my plan. I originally spun up the Windows box because I was familiar with the ARK Server Manager software. However, I've been reading up on Pterodactyl and Wings, which can be run on a Debian platform. It looks interesting and has the added advantage of being able to host multiple self-hosted game servers.

Anybody?

@johnpoz I ditched that buggy interface in the first pfSense, even the whole vlan, and built a truly new one and it is working just fine. Sometimes pfSense can get messy.

@kloy You can do NAT 1:1 in IPSec to masquerade a whole subnet with another one. But this has to be done within the IPSec phase, and you will have to translate both sites to get bidirectional communication. Other NAT rules on pfSense don't work with IPSec. For instance, both have the same LAN, which should be able to connect to each other: site 1: 172.16.0.0/24 site 2: 172.16.0.0/24 So you configure the phase 2: site 1: local: 172.16.0.0/24 NAT/BINAT translation: 172.16.1.0/24 remote: 172.16.2.0/24 site 2: local: 172.16.0.0/24 NAT/BINAT translation: 172.16.2.0/24 remote: 172.16.1.0/24 Then site 2 has to use 172.16.1.0/24 to access site 1, i.e. to access 172.16.0.10 on 1 from 2 use 172.16.1.10. And site 1 has to use 172.16.2.0/24 to connect to 2. You can also nat to a single IP by selecting address for the type at NAT/BINAT translation, but this works for outbound connections only. There would no possibility to access any IP from the remote site then.

Just wanted to let you all know that we've made a workaround, since it was urgent and could not easily be solved. Thanks for your help!

@Swami_ did you remove the conflicting ports forwards? (Try one at a time)