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)
Capture3.JPG
Capture3.JPG_thumb

When you create a port forward, the default setting is to auto create the firewall rule on wan for you to allow..

If you have rules ahead that specific block other than the default deny then that could fail - and you would have move the wan allow for your nat to be above any explicit blocks of the ports your wanting to forward inbound.

Thanks you.
everything was ok when I switch to mode NAT + Proxy
Originally I chose the mode Pure NAT

Thank so much

Forwarding is no solution here. That translates the destination address to another one, however, your crap device won't work with that, since the source address is out of another subnet.
What you need here is translating the source address into one out of the subnet of the concerned device and which is assigned to the pfSense interface, so that responses are sent back to pfSense.
That can be achieved by outbound NAT in pfSense. Firewall > NAT > Outbound

If the outbound NAT is still working in automatic mode, select the hybrid mode and save that setting first.
Then add a new rule. According to your example, select the VLAN30 interface (the interface facing to the problematic device), at destination enter 10.10.30.200, at translation address select "interface address" which is the default value. Save it.
Accessing the device should work now.

The DNS load balancing feature doesn't see much testing, it's possible there is an issue there, or it may just be a limit of relayd. Last time I tried it, it worked, but I also wasn't trying to have it hit a different internal port.

How are you testing it to see if it works? Have you tried other monitoring types than ICMP?

One major thing to be aware of, when relayd does dns balancing it acts like a proxy, so your DNS servers will only see the address of the firewall itself and not the clients. Depending on your DNS server config that may make a difference in how it handles the queries.

Thanks for the responses!

Will be trying out the following as suggested by jimp:

The above on WAN, plus y.y.y.0/30 routed to x.x.x.2, then set y.y.y.0/30 as an outbound NAT subnet"