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

@kom

The first link I glanced over before but I can now access the web server both on the WAN and LAN. I'm even able to ssh to it from LAN to OPT1. I don't remember if it was one of the videos you linked or some random third video but I didn't understand that request get sent out on a random port. So those source ports would have never worked. Sorry for not understanding that sooner.

Thank you for the references and your time.

If we all got $1 for every "Gah! pfSense is hacked/broken/whatever!" and it turned out to be a configuration issue, we would all be able to retire.