@naiw said in Host Website over IPsec to a QNAP:

The two systems are connected via IPSec and work very well.

Policy based IPSec, I guess?

It would work with routed IPSec if you assign an interface to the IPSec instance on the home pfSense and move over all firewall rules to it.

With routed IPSec, however, possibly it works if you nat the traffic on the remote pfSense in the phase 2 to a local address. But I never did something like that.

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

@alvescaio said in SNAT IPsec not work:

Assuming I have 5 openvpn networks to do this, will I have to do 5 phases 2?

Not really necessarily, but each network has to be part of the "local network" in the NAT phase2 at least. This means, if you can set the network mask so that it includes all you can also go with a single phase 2.

In any case you can only use a single NAT address.

And how would this work on the client side? Because he will only see my native network 10.193.10.0/24, he will only have one phase 2 on his side while I would have 5

The NAT address has to be part of this network.
Maybe not all IPSec implementations accept this, however.

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