Hello, I Have the same issues with 2 Xbox One. The NAT is open for Xbox Live, but not possible to join a session in warframe (no probleme with rocket league). https://forums.warframe.com/topic/949122-no-coop-for-2-xbox-same-isp/

Jim, I am so sorry - I missed your response on this. I know it's been six months, but the problem reared it's head again. If I understand correctly, you are saying that the combination of NAT port forwarding and 1:1 NAT to my virtual IP's assigned to the CIDR block "could" be causing the issue when you say this "… if something happened to the port forward then it may misbehave.". It's a weird too as often getting the remote user to clear their browser cache causes the problem to go away - but other times it takes a day. We had been using NAT port forwarding in conjunction with 1:1 NAT to try and conserve our static IP's  - but it sounds like it might be safer to just do the 1:1 NAT and not port forwards. Is there any way to further pin this down? I have correlated Chrome browser network requests, with pfSense firewall logs and the request logs on the two web servers involved.  I can pretty clearly see where the first six requests from the browser are all to the IP address of the first web server, but pfSense shows the sixth request gets NATed to a different server - but of course no rationale for why it did that. UPDATE: Yes we are also using aliases a good bit. What type of issues might that cause? Thank you again - Richard

Note you don't strictly NEED a VIP if the traffic for those addresses is routed to the WAN interface. All that matters is the traffic arrives. If so, NAT will happen. If it is an address in the WAN subnet (or some silly, unrouted, secondary WAN subnet) then you must have something that will respond to ARP from upstream in place on WAN, meaning one of the VIP types except Other.

Perhaps. But firewall rules blocking everything but SMTP are far, far easier. Either way it looks like you want this behavior on whatever Lan2/Router are in your "diagram" and not on pfSense.

Because the OpenVPN tab is really an interface group consisting of all OpenVPN servers and clients on the firewall. Traffic passed by rules on an interface group tab cannot be flagged with reply-to because pf does not know which interface the traffic arrived on (it could be any interface in the group). The firewall processes interface group rules before interface rules so the traffic must not match any rules on the group because there will be no reply-to so replies don't get directed back out the way they came in but are instead routed according to the routing table. When dealing with connections from arbitrary internet sources, this usually means they go out to the default gateway. There would be no matching state on that interface so that traffic is usually dropped. Even if it wasn't dropped and made it back to the originating host, the firewall there would probably drop the traffic because it would be sourced from a different IP address than the connection was originated to.

Most people enter Hybrid mode then create the rule and just leave it in Hybrid mode.

Yeah. No difference. Just port forward to the inside address. As long as the target host's reply traffic makes it back to pfSense it will work.

If you want to use your /26 behind pfsense why would you not just have it routed to you?  Then you wouldn't have to nat even you could put these machines on that netblock and just firewall. Why don't you sniff and validate traffic hits your wan, and is sent on out to the machine..  If traffic is sent on to the machine and it doesn't answer then issue is on the machine - firewall common problem, different gateway another common problem, etc.

Can anybody answer this? Does it seem reasonable to have a checkbox for every gateway providing the possibility to exclude that particular gateway from automatic outbound NAT rules? Or perhaps have such a checkbox for GRE interfaces only?

Nevermind… something happened on the windows box and i had allowed RDP through the windows firewall previously for "Work" network's, but now it's identifying as public.

Dude if you have some downstream router that understands this 10.96.0 network then you would create a static route.. Still not understanding where this 10.96.0 network is… its on your VM host? your 192.168.1 is a transit to get to this downstream network.  If your doing some nat on some VM host.. You would send traffic to this VM hosts IP where this IP is natted too..

UP No idea guys?

What network is your WAN on?

Delete all the rules you created for SIP/RTP then start analyzing your SIP traffic.

here is mine i can access plex remotely .JPG) .JPG_thumb) [image: Capture3.JPG] [image: Capture3.JPG_thumb]