@Djkáťo

The one and only question that answers your question while answering me : do you have a working Internet connection ?
If yes, then nearly all is fine, and you can stop looking, as you've already mentioned what your current situation is : its doesn't break your internet access if your WAN IP is a RFC1918.
But you can probably forget about NATting so you can make internal (on the pfSense LANs) devices accessible from the Internet, as you have no access to the ISP equipment to do so.

If your "TP-Link Archer VR300" is truly working as a modem, its just converting POTS VDL signals to "Ethernet" signals and it doesn't do routing , firewalling etc. Its not the "TP-Link Archer VR300" that has a WAN, and a DHCP server that gives you the "10.101.37.22" pfSense WAN IP : this "10.101.37.22" comes from way up, somewhere from the ISP.

Why they do so ? There is the classic $$$ rule : they have no more free routable IPs left as IPv4 free available stock has been sold out meany year ago, and what's left has a huge price tag. Its seen before ; you want a real routable IPv4 ? You $$$ or €€€.

@JustAnotherUser said in Port Forward over VPN not working....:

If you want to go over WAN anyway, assign an interface to the wg instance and enable it at site 2. This brings up a new firewall rule tab for it then.
Now go to the "Wireguard" tab, edit the existing rules and change the interface to the new one.

I'm not sure what you mean by your last sentence but, I've done the rest.

You mean, changing the interface in the filter rule?

In Firewall > Rules you will see a tab called "Wireguard". pfSense might have created a rule on this tab automatically, when you set up the Wireguard tunnel.
So go to this tab and edit the existing rule and change the interface from "Wireguard" to the interface, which you have assigned to the Wireguard instance before.
Then the rule disappears from the Wireguard tab and appear on the new interface tab.

Also in the WG settings on router 2 you have to change the "allowed IPs" to 0.0.0.0/0 to accept public forwarded traffic.

@felipefonsecabh said in Access service in device connected via IPSEC trought public IP:

I have change local network to Any to carry traffic from any external IP?

Yes, if you are using policy based IPSec and need to keep using that. The policy has to match that traffic and the source IP could be any IP.

But if you do that it will match traffic at the other end for 'any' destination. All traffic from site1 will go over the IPSec tunnel. Which you probably don't want.

A route based VPN tunnel of some sort would give you more options.

@emc

This issue has been fixed. NAT is working. It was a firewall issue in the PBX. I've whitelisted the IPs on the PBX's firewall and it works. Thank you everyone for your help.

But anyway you don't need NAT reflection on pfSense for this now. It's useless, since nothing points to its WAN IP.
And the port forwarding rule with the WAN IP is useless as well.

@viragomann no I need both, I tested it. As soon as I remove the reflection from the port forward, the service is not accessible from within LAN. If I deactivate the WAN port forward Rule, I can't access it from the internet. Maybe because of the first main forward "everything" to pfsense rule in proxmox's network interfaces file. So I will leave as it is for now. I'm just happy that it finally works.
Yes, got a scheduled job doing VM backups every day.

Hi @chpalmer,
You were right; the problem was an incorrect gateway configuration on the webserver.

Thanks again!

Not sure if possible with udp.. And have never tried it with tcp either.. It is listed as an option, but not sure on the details of that option.

We can call in maybe @Derelict he would have better understanding here of these options. I would think ;)

Hi,

No need to go to http//whatever.on.the.internet.tld
Like Mercedes knows all about Mercedes cars, Netgate/pfSense knows all about pfSense : https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

I would open my tool box, that is : clicking on " Diagnostics > Packet Capture" and set up for a capture on port 1194 and UDP (?) and start it.
Then, try to connect using your remote App.
Stop the capture.
Look at the result : something came actually into on your WAN (?) NIC on this 1194 port ?
If not : the problem is up stream : traffic didn't make it to pfSense.

Read the entire check list on the trouble shooting page : execute every step, and if you do not understand : ask.

"before using Pfsense I open NAT-DMZ on the router from WAN to local IP. " pfSEnse is not any different from any other router on planet Earth.
You have to create a NAT rule, using incoming port, outgoing (destination) port, a 'LAN' (DMZ) IP address and that's it.
But if 1) applies, and nothing comes in ... well yeah .... 1 explains 2.

"I have a program that does not work in the domain environmen" : I don't understand.
That's a typical user that describes an error.
Your are the network admin ? Start detailing what actually happens. We, from here, know nothing about your network / needs / setup.
Give details and we figure it out.

@silviowmelo
o RDP para acessar interno, vc vai usar o IP da maquina e porta padrão.

What I ended up doing was using pftop, filtering on the dst port (which should be the internal port on the internal host), and looking for established connections.

@Gertjan shodan.io is a service that scans the internet for known exposure and for vulnerabilities

i remember you are french, so I link you here a video in French on the subject https://youtu.be/SxjmOFBtsvk

@Grimson said

RTFM: https://docs.netgate.com/pfsense/en/latest/interfaces/interface-settings.html#private-networks

Thankyou Grimson, after Reading The Fine Manual.
I concluded that
since the WAN IF of pfSense router actually does not have a public IP and has a IP Address 192.168.1.253
RFC1-918, I think it is secure from outside attack over internet even after turning off the block Private IP Address and loop back address and this is the proper way to configure and it's not a work around. Please correct me if i'm wrong.
WAN-IF.JPG
RFC-1918.JPG
Thanks

It might be an edge case we can't really detect well since it may be valid in some other way, even if it isn't an IP address (e.g. a hostname, other alias name, etc)

Tried killing the firewall states ?