Yessir

Create a port forward for ssh to that LAN server via Firewall - NAT - Port Forward. Since you're in private IP space, you will also need to edit your WAN config to stop it from blocking inbound access from rfc1918 addresses via Interfaces - WAN - Uncheck Block private networks and loopback addresses. https://docs.netgate.com/pfsense/en/latest/nat/forwarding-ports-with-pfsense.html https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

First of all, thank you for your time. I tried on VMWare Forum without success, maybe people are in holidays :) If I can, I would like to recap what you wrote that for sure make it sense. What I understand is that now PFSense WAN interface is under VKernel (default Port Group: VM Network) and under its firewall. So I created a new Port Group named WAN and conenct it to Physical adapters, then move the WAN PFSense interface on it: [image: mSUZ9HX.png] Topology shown now that WAN Port Switch is connected to Physical adapter (the only one I have) [image: jkyIFO5.png] On vSwitches side I left untouched i.e. vSwitch0 (default) and vSwitch LAN. [image: TSW1jPo.png] [image: JNsyphC.png] But still doesn't work, maybe I still miss some config, or maybe I have to add/modify the VMKernel NICs section... I'm lost.... [image: F0N8nYr.png]

The routes? So you've created a Site-to-Site OpenVPN server? Also added firewall rules to allow that access? You'll need a rule on pfSense1 WAN interface as well as on the VPN interface on pfSense.

here are some follow up log entries. Jul 17 15:54:10 miniupnpd 85109 SoapMethod: Unknown: GetPortMappingNumberOfEntries urn:schemas-upnp-org:service:WANIPConnection:1 Jul 17 13:26:33 miniupnpd 85109 http://192.168.254.1:2189/rootDesc.xml not found, responding ERROR 404 Jul 17 13:26:33 miniupnpd 85109 http://192.168.254.1:2189/rootDesc.xml not found, responding ERROR 404 Jul 17 13:26:33 miniupnpd 85109 http://192.168.254.1:2189/rootDesc.xml not found, responding ERROR 404 Jul 16 16:49:46 miniupnpd 85109 Listening for NAT-PMP/PCP traffic on port 5351 Jul 16 16:49:46 miniupnpd 85109 no HTTP IPv6 address, disabling IPv6 Jul 16 16:49:46 miniupnpd 85109 HTTP listening on port 2189

@X2LR said in Port open yet firewall still blocking traffic: Yes I reset states after changes Well the client doesn't know that... So he had connection open, and wanted to continue to talk - so yeah your going too see those sorts of blocks until a new session is created. Why are you resetting the states? You would only need to do that on a specific sort of rule change for any active states related to that specific rule.. Say you wanted to block 192.168.1.100 from talking to X.. So you created a block rule, you would have to clear the states for 192.168.1.100 talking to X to make sure that rule takes effect. You don't need to clear all of them ;) So that right there explains what your seeing! You can adjust the pfsense settings so that wan going offline because monitor doesn't get an answer.. One sec and post screen of where you do that. edit: Uncheck this system / advanced / misc [image: 1563282256197-killstates.png] But yeah your going to want to setup your p2p client not to use up your whole pipe ;) Have not had to deal with any of that in many years... I don't do any p2p to my home connection.. I run a seedbox elsewhere.. But you can setup limits in the client.. And could also limit with pfsense via limiters or shaping.

@Grimson - I implemented these settings over the weekend [24/7 operation] and this clearly corrected the audio problem with the SIP trunks! THANK YOU

Have no freaking idea what he is doing - seems like he wants to source nat his vpn users? Just at a loss to why want to do that - just love not knowing what vpn client is connecting to your server ;) Firewall rule on the dest device? It has no gateway - or different gateway would be the only reasons I could think of wanting to source nat. If it was using a different default gateway, you could just host route on the device.

As was already said (and apparently ignored) An iperf client or server running on pfSense consumes CPU cycles. If you really want to test throughput put an iperf server (known to be able to easily saturate a gigabit link) locally outside the WAN interface and an iperf client (known to be able to easily saturate a gigabit link) locally on the lan and test THROUGH pfSense, not to it or from it.

@chrismacmahon Thank you. That post is exactly what I was looking for. We will explore TNSR as an option. It looks very interesting.

@KOM @KOM said in (SOLVED) Problem with client connect through static IP cable internet: Both pfSense and OPNsense are based on FreeBSD, 11.1 and 11.2 respectively. It doesn't make sense that you could install OPNsense based on 11.1 but not pfSense based on 11.2 on the same hardware. Oh well, at least it's working for you. 11.1 and 11.2 respectively. A lot of things did not make sense in this whole process Maybe it was the hardware, maybe it was pfSense. Same to me if I am honest since OPNSense with the new machine installed/worked just fine and from the functionality they seem to overlap quite heavily. Works for me.

If your LAN rules allow traffic to hit Unraid, then the wifi clients traffic will pass as well. Are you sure the AP isn't blocking it for some reason? A packet capture on LAN while you run some connectivity tests will show if pfSense is even seeing that traffic or not.

@maverickws said in IPv6 over IPv4 Tunneling: You don't need to configure NAT for this. The rule you need is a Pass on the WAN interface (Firewall > Rules > WAN), I believe allow any to any or any to host and on protocol (not address family) you select IPv6 I think that's it. Yes, I did that. Protocol IPv4 IPV6 Source any Destination (tried any or my VM IP) and this rule does match the state that is created when I ping out. But still after it times out incoming connections are dropped and don't show up in firewall logs. So it's inbound NAT that isn't working and I suspect it has to do with that error I'm getting in the original post.