@STEPHANK Freepbx runs fine behind pfsense in various setups and is rather straight forward to configure
In general not much is needed and in most cases not even any port forwards too.

Do describe your configuration and setup.

@lukeluke1979
There is no need to assign the public IP to sn interface. Just add NAT rules on both WANs with custom translation address.

@viragomann said in Outbound NAT over IPSEC tunnel not working:

@shaunmccloud said in Outbound NAT over IPSEC tunnel not working:

And the minute I add a P2 entry in my pfSense box for a remote network of 0.0.0.0/0, all network traffic but local dies.

So I'd assume, that the traffic is routed over the VPN, but not out on WAN.

But this is only the half of the battle. The traffic must be natted on the remote site

If the Meraki doesn't masquerade your subnets there is no way to go out to the internet through it.

I decided to cheat, and throw a virtual pfSense box in the data center to connect to. I'll see how that works tomorrow.

@TheCalvinator glad to hear finally sorted. Thanks.

@viragomann

Morning my friend, some news about topic?

@Yasir Yeah, well unfortunately that's the way it's implemented so unless you can push for and get an update/improvement of the implementation, a script is the only other solution.

@viragomann Thank you very much. you helped me understand very good whats going on.
Moreover i managed to to make it wotk bu adding an snat outbound rule to the openvpn interface. thanks again.

@Zak-McKracken
If the issue is suspected to be with the external IP and the Ricoh firmware, then it might be worth trying siproxd.

@viragomann Thanks. going to do some reading up on this before I kills my pfselnse.

@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 :)