@Anaerin It looks like the issue is Wireguard. Disabling Wireguard, removing it's interface, tunnel and peers removes the rules. Quite why Wireguard is grabbing the wrong subnet for the VPN subnet and redirecting it to the local net is an issue.

@ruqen001 Show also the related WAN firewall rules.

@Vinibo1 I'm going to assume your servers have already been mapped on the NAT. Here's my two cents beyond that: Your cisco set up was masking the internal IPs using "overload". This function automatically performs a port address translation and you'll have to manually input that into pfsense if you want to specify the external IP used by your servers when reaching out over the WAN. You can do this in firewall>NAT>outbound. Select "Manual Outbound NAT rule generation." Create a rule similar to the Cisco setup: Interface: WAN Source: 192.168.0.0/24 (DMZ network) or 192.168.1.0/24 (LAN network) Translation Address: Use the WAN address or specify the public IPs.

@Gertjan thanks - that damn curiosity cat was really meowing at me about this one ;) clawing at back of my brain as well - what would you want use such an alias for?? hahahha

Since your devices are isolated for security reasons, it could be blocking the communication needed for those alerts. You might need to tweak your firewall settings or NAT rules. If the issue persists, it could be worth exploring how systems like Vivint security system handle network segmentation while still delivering reliable push notifications.

@Legal_Brick_527 With two VPN clients running on the same pfSense ? I didn't really insist when testing (things start to behave very bad). I'm sure that a first VPN client can used as the 'gateway' for a second VPN client on the same device, but you probably have to set them up the old way : manual config file creation and all that. That's not possible on pfSense. I hope to be wrong of course. What was possible : Setting up a pfSense VPN client to 'some' VPN-ISP, routing all outgoing traffic over this connection, that's classic and works fine. Then I activated a VPN client on my NAS, used 'another' VPN-ISP, and that connected also "just fine". Now, I had a tunnel over a tunnel. As I was using some web https sites to test, I actually had a a tunnel in a tunnel in a tunnel. Btw : you go beyond what is needed to protect the launch codes of the nukes .... are you sure you need this protection ?

@viragomann Hi, I have new information. After some tests that I install pfsense on a VM to check if I connect to PPPoE through it and then do "CG-NAT" to the main pfsense to see if it will work. And it works!!!!!! The only thing I changed in the main pfsense is in the gateway group that the interface from the virtual pfsense will be the main one and all traffic will go through it! What it looks like is as long as the external IP address of the client trying to access is the same external address that is visible in pfsense then it just won't work. Now I have no idea what rule and where I should put it to solve this problem. I have never encountered this problem in my life. So I don't even know what to call it to google it

@Gertjan I think its a checksum error that is preventing it if I disable the hardware checksum offload it work perfectly so I think that is the main cause. I did forget to mention I was on virtual and I forgot to disable the checksum in there now everything is working as it should I am sorry to cause so much confusion. Thank you again.

@midnightfm Good to hear the firewall side is resolved. Sounds like you'll need to dig into some Windows event logs to diagnose the barracuda LDAPS issue. I'd expect to at least see failed connection and/or authentication attempts on the DC in the event logs.

i finally found the cause, i changed the 'Filter Rule association' from 'pass' to other, i then works [image: 1723103470124-c64cd004-70ad-491e-b301-eafe18d333f1-image-resized.png] but the thing is we have default gateway and even i allow all in firewall rule, but nat with filter rule association 'pass', nat still not forward the traffic; looks like it's the bug of pfsense [image: 1723103505590-3375e8e7-e1fc-4306-8f6a-80cc70841df5-image.png]

@phipac it is possible to do reverse proxy with tcp ports - I haven't had a need to do such a thing. but why would you not just have munin.domain.tld for that service and other.domain.tld for whatever other services your trying to talk to.. they could resolve to the same IPv6 or different. edit: or if you happy with how IPv4 is working - why throw ipv6 into it at all.. There is nothing saying you have to use IPv6, unless your behind a cgnat and that is the only way to get unsolicited inbound into your network. Just because IPv6 is the future, doesn't mean that future for you is now ;) Could be 20 some years before IPv6 is the main protocol to be honest. My isp doesn't even provide it - I have had ipv6 from like 2011 or something via HE tunnel.. I sure don't use it for any services I provide or use while I am remote to get into my network. As you said IPv4 with nat and port forwards work just fine. ;) Providing those services via IPv6 gets me nothing other than more complexity. Shoot most of my users of my plex server don't have IPv6, or even know what IPv4 is let alone IPv6 ;) Not sure what all services you want to provide to the internet - but any services I need to access on my network while I am about I just vpn in - via IPv4 ;)

@SteveITS Thank you so much. Let me take a look at this article.

@negeji8010 yeah I hear yeah.. oh btw IT make this nonsense work.. Yeah we didn't bother to ask you if we "could" do such a thing - just make it work! To make it work.. You will need to nat them, and will need different natting devices.. The "cheapest" way to do it is find some small little router.. Some little travel router or soho router going to be the easy cheapest solution. Sure you could do it as vm, etc. But that is going to cost more for sure.. Unless you have something laying around to use as the host were you could run multiple natting something - wouldn't have to be pfsense doing the natting. If you go the soho or travel router I would make sure it runs some 3rd party firmware (openwrt for example) vs native like linksys or netgear router OS.. Maybe tiny router from Mikrotik, they have something like the hex lite for like $40 that can be powered via poe, etc.

@viragomann Thank you.n Problem solved

I wanted to give an update to this since I have been going back to this problem and believe I have finally found a working solution. My experimenting has involved a few different firewalls and setups, and all the time I have been able to get Open NAT on MW2 (2009 version) only when the game has been "seeing" UPnP. Regardless if there has been a second firewall upstream that only had "traditional" port forwarding set up. I'm writing "seeing" UPnP as I recently did some packet capture and started noticing some similarities between the scenarios with and without UPnP active. When not having UPnP I have manually set up port forwards for 28960-63, which are the ports showing up in the UPnP status page when this game is running. What I found was that regardless if the game reports Open or Strict NAT, I always have the following "pattern" showing up in the pcap data: [image: 1720109675357-e61ff4f5-1a6b-42dc-83ca-5e20cf7109ae-image.png] The only difference when UPnP is active, is that before this communication starts, I also see the following nat-pmp request and response sequence. [image: 1720110610065-15bbeb55-5dac-409a-bf01-8988f2e68b0e-image.png] So I started thinking that the communication actually seems to be working on port 28960 and the game's reporting of Strict NAT might not be accurate? So I got some help from my friends to do some further testing and sure enough, I am able to host a game as well as connect to any other party hosting a game without issues! So, I'm guessing that this particular game is actually reporting NAT status solely based on getting a response on it's nat-pmp request, and not based on actually doing a communication test... which in my case is giving me incorrect information and has had me chasing a nonexistent problem for quite a while... So all I have now are ports 3074-79 and 28960-63 opened towards my game PC... And for port 3074 I have to make sure to use static port.