@nanda said in Outbound issue in NAT:

nbound traffic forwarded to 10.3.68.4, but outbound traffic from 10.3.68.4 is denied. See the below logs.
[Action] [Interface] [Rule] [Source] [Destination] [Protocol]
Allowed WAN 443FWARD (1710406287) {public_ip}:30797 10.3.70.3:443 TCP:S
Blocked WAN (1000003570) 10.3.68.4:443 {public_ip}:30797 TCP:SA
Blocked WAN (1000003570) 10.3.68.4:443 {public_ip}:30797 TCP:SA
Blocked WAN (1000003570) 10.3.68.4:443 {public_ip}:30797 TCP:SA
Blocked WAN (1000003570) 10.3.68.4:443 {public_ip}:30797 TCP:SA
Blocked WAN (1000003570) 10.3.68.4:443 {public_ip}:30797 TCP:SA
Blocked WAN (1000003570) 10.3.68.4:443 {public_ip}:30797 TCP:SA

The blocked packets are not expected to enter on WAN, since the request packet was sent out on hn2 (HLAN presumably).

I suspect, that there is a misconfiguration in the hypervisor network.

@GblennNAT Rule.JPG Icarus Alias.JPG

Here are the screenshots.

Alright, that was an easier fix than I thought.
After I thought about it for a few minutes, I realized that since I moved the proxy manager to another subnet I had to choose it in the UPnP service in pf too.

Thanks for the suggestion. I think my problem is the source IP that I had entered was the virtual interface (wg1) address of the remote host. I think this is supposed to be the physical IP of the remote host because the tunnel isn’t alive until access to the internal Wireguard server is physically possible. Mobile devices on cellular have dynamic IPs as far as I know, so not really possible to allow a device only that has a ever-changing IP. I wish there was a way to only allow a mobile device on cellular without setting allow “All” sources on the port forward.
I feel like I’m rambling. My apologies :)

@ErrorHandler Can you port forward all ports to pfSense? Say, 1025-65535?

uPnP won't have any effect if the packets aren't getting to pfSense.

@jhonfer3000
Of course, the devices behind pfSense have to use its LAN IP as default gateway. I presumed, that this is already given.

Best would be to disable the VirtualBox DHCP in this subnet and enable DHCP on pfSense. This set the proper gateway IP automatically.
Otherwise you have to configure the VirtualBox DHCP to hand out the correct gateway IP, but don't know, if this is even possible.

@Rafandium said in Acesso endereço link externo dentro da rede interna:

Nessa situação, ainda não esta conseguindo acessar.

É split ou full tunnel ?
Se for split tunnel, o acesso ao IP externo deve passar por fora do túnel, dessa forma seria um acesso http/https normal vindo da Internet.
Se for full tunnel, você deve atribuir o servidor DNS do pfSense ao cliente, que quando conectado na VPN, use o DNS que tem a entrada A.

@johnpoz Thank you so much, i missed that part as normally on the previous version i would add the NAT by default would be tcp thank you

@carlosRamos said in set up port forwarding:

from interface wan to destination Lan and then specific IP

As you sure that is how you did it, in which case you need to change destination to WAN address instead. Otherwise there is no difference port forwarding to a device on a VLAN or the LAN. Just use whatever IP the target server has...

It might be easier to assist if you could provide some pictures showing your rules.

@D4nt33 said in >Port Forwarding not working for Gameserver on Unraid.Please help me out:

before i could just type the ip of the server using a pc on my local network and it would bring me directly to it now that doesnt work and the only way is to type the domain name

There is nothing in the firewall (pfsense or other) that would prevent your from accessing your internal servers via IP. The only thing that would make it not work as before, is if the IP has changed, and you need to find the new IP.

@D4nt33 said in >Port Forwarding not working for Gameserver on Unraid.Please help me out:

i am very new to Pfsense or any firewall in general

Do you use static IP settings for your servers in pfsense?
Might be easier to assist you if you paste some pictures of your NAT rules and firewall rules here.

@mvbif Yes, you're right, port forwarding is a DNAT, actually, I was wrong. The thing is, this port forwarding is SNAT-ing too.

Nat lonely should not allow anyway traffic not allowed from a security rules.

The port forwarding was done and a rule has been added to allow the traffic. Also, the IPSec traffic is allowed via a different rule, so the traffic is allowed.

So now i will check but, i feel to say that yes that nat rule will apply only on traffic coming from openvpn and has that destination.

Well, this is what should happen. Only traffic coming in via the OpenVPN interface should match. But it doesn't.

About the ipsec traffic, are you saying that with nat on, your ipsec host can ping 172.x.x.x , with nat off can't anymore?

Yes, that's what I mean. If I exclude the IPSec connected subnet (10.41.13.0/24) from the NAT rule OR I disable the NAT rule, the IPSec traffic cannot go to 172.31.254.100.

Btw ipsec should have rules permitting traffic to 10.41.99.65 isn't it?

Yes.

Also, the thing is, the rule's SNATing too: With the rule in place, 10.41.13.225 for example, can curl 172.31.254.100 and get a reply. On the 10.41.199.65 (the actual IP that the port forwarding rule is set on) I see the traffic coming from 10.41.199.2 (PFSense).
Test scenario: Via the IPSec, I'm sending, from 10.41.13.225 a curl 172.31.254.100:2345 (port was chosen so no traffic is going to disturb the test). With the port forwarding rule enabled, I can see traffic on 10.41.199.65, coming from 10.41.199.2 (PFSense IP address) dst port 2345. This clearly matches the traffic. Checking the firewall logs I can see the traffic being allowed from 10.41.13.225 to 10.41.199.65 (translated IP address). This means that PFSense matched the traffic and DNATed via the above rule, but it also SNATed (why?).
Disabling the above rule and running the same scenario: curl 172.31.254.100:2345 in the firewall logs I can see the traffic as being allowed from 10.41.13.225 to 172.31.254.100 (not translated) but the traffic doesn't reach the 10.41.199.65 VM (normal, since it was not translated).
What's going on?!

Also, check this out: states tables filtered by 2345 (dst port):
8710e90a-870d-4772-8d91-8056ab5d502a-image.png
So it sees the traffic as coming from the IPSec interface, but it's SNATing it and then delivering it to 10.41.199.65.
I have NO NAT RULES to match this traffic (outgoing on VLAN199 interface) so there should be no SNAT done, from what I can say. There's no NAT rule matching 10.41.13.225 or 10.41.13.0/24 or 10.41.0.0/16.
Can't I somehow see what NAT rule is this traffic matching?

@McMurphy Hello,
So now seems that at network level the connection is working,
Now you should check on apache logs to see if it get's the request, and if there any error about.
Connection reset by peer, should be that you reached the server.

@tknospdr Yeah your fine this way - unless you worried about their warning ;) If so you could uncheck it and look into the other option.

Let me see if I can explain my proble... I'm running tailscale in PfSente (in the end that is the main problem). I'm alo running on my network Headscale (a open source self hosted aleternative to pfsense servers) and also a DERP Relay serve self hosted, to use my own replay server and decentrelize from Tailscale servers.

DERP Relays servers when configured on Tailscale clients, need to be accessed directly from the public IP, so it can know all the public IP's to rout the traffic. This roules out making split DNS and accessing the DERP server by local IP address... Tried it and it says that the range of ip's is not valid. So I need to access the DERP server making my local service "belive" that the connection is form the public IP.

If I access it from outside my home the NAT forwards the traffic and all works OK... When I'm inside my home I need to access it bu the wan interface, and this works with the NAT Refrection, allowing me to access the WAN interface and "follow" the NAT forwarding rules... This works ok to ALL my devices! But PfSense, that also haves a tailscale client installed, does not seems to be following this forwarding rules! When I it tries to access the WAN interface I have a message saying that it was denied, and this only happens in pfsense, all other devices work.

I'm now dealing with the same issue. Still not 2028, but only 3 years shy.

I posted a new thread about it as it wasn't until late in the posting process that I realized it may have had something to do with NAT reflection specifically.

The rub here is that I am running DNS split horizons and still have my issue.

Feel free to answer here or comment on my new thread.
Thread here

@SteveITS What I meant by "one type of client device" is the following:

The customer has a number of application servers that provide a whole range of services. Their clients have devices that connect to their services. They recently updated their servers to a new major release and it seems the problem is that some clients, running an older version of the client software, were having trouble connecting to the new servers, which it turns out has nothing to do with the port forwarding at all.

@Tiny-0

Repeatedly ran into this and was wasting time trying to re-install and restore config each time, only to have the packages "disappear" again...

Is there a Redmine report for this?

Does anyone know what the root cause might be?