@johnpoz said in pfSense with port forward AND outbound NAT - rewrite source IP address:

@jarlel said in pfSense with port forward AND outbound NAT - rewrite source IP address:

WHY? Because the DNS servers have different filters based on which source IPs the request comes from

Even if you get that to work - you have a problem with the answers being cached in unbound.

client A asks for something.tld, which is allowed for client A.

Now client B asks for something.tld which should be blocked for client B, but unbound already has it cached, so it sends client B the answer.

There is no difference in the filters for clients in the same "client group". All clients using VIP 1 as DNS-server has the same filter/rules. All clients using VIP 2 as DNS-server has the same filter/rules.

The DNS-server is a public one with some special services/filtering, so all requests are considered and evaluated without caching.

@stephenw10

Let me know if you need any info.

@Gertjan Thank you so much!

@viragomann said in NAT 1:1 through Wireguard:

@_deadpool_
It should work with an 1:1 like this:
interface: WG (you wrote above you have assigned OPT1 to the wg instance)
External subnet IP: 172.16.1.0
internal IP: Network > 192.168.1.0/24 (or LAN subnet)
...

ok, i modified the configuration using the interface WireGuard instead of OPT1 as you stated, but i'm in the same situation. in the peer configuration the subnet is already allowed.

@viragomann said in NAT 1:1 through Wireguard:

...

However as mentioned, you have to ensure, that 172.16.1.0/24 is allowed in the remotes WG settings and firewall.

...

i don't understand this, tou mean there is something to do at site A? i don't think so, as at site B if i use a mikrotik it works without touching site A configuration. if it means that i have to do something in firewall>rules at site B i don't understand what i'm missing, even in site B i can't ping machines in LAN using 172.16.1.0/24 class. pinging from site A shows in packet capture:

17:44:47.026691 IP 172.16.0.1 > 172.16.1.1: ICMP echo request, id 8335, seq 7, length 64
17:44:47.026710 IP 172.16.1.1 > 172.16.0.1: ICMP echo reply, id 8335, seq 7, length 64

which seems that packets are arriving from site A and they get replied, nut pinging another machine existing and up i get no reply, like this:

17:46:37.026691 IP 172.16.0.1 > 172.16.1.100: ICMP echo request, id 8335, seq 7, length 64

pinging from site B the WG ip of site b pfsense i get:

17:48:44.450593 IP 172.16.0.1 > 172.16.0.2: ICMP echo request, id 55040, seq 57612, length 36
17:48:44.450614 IP 172.16.0.2 > 172.16.0.1: ICMP echo reply, id 55040, seq 57612, length 36

and i get the same pinging every host in 172.16.0.0/24 subnet from site B.

i still can't figure out what i'm missing.

@frawnsmoc said in DNS Port Forward Inglês DOES NOT REDIRECT:

replace pfsense with mikrotik matter solved pfsense has this bug

ok

@viragomann

Yes the Public IP is assigned to that interface.

I changed the Mappings to use the drop-down entry instead.

Still did not work.

Static Ports are in use because of VoIP Calls.
If I do not use Static Ports, the calls end up with one-way audio.

What did fix the Mapping issue is:
I rebooted the pfSense this morning - then it started working as expected.

I have seen issues with KEA DHCP resolved with reboots.
But now also this...

I should not have to be rebooting pfSense in production environments to make things work.
I am quite disappointed with what I have been seeing with pfSense recently.

@viragomann Ohhh wow, thank you :)

@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.