@airone-0 said in pfSense and NAS port opening:

Do you have an answer?

We already went over that answer - if your not asking the dns where you setup the override, then no your override wouldn't work..

If I ask billy for john's phone number, and billy doesn't even know a john how would he know john's phone number..

Not sure what your pc is asking, 192.168.0.1 - is that pfsense?? If so then it should resolve the PTR for the server name, and not come back unknown..

As to that first example - that is just asking itself, ie lookback 127.0.0.1, where it actually gets forwarded you would have to check on wherever system that was - your nas?

Thank you Viragomann,

It worked -- though I did have to make a few unexpected tweaks (this is very likely due to my very incomplete understanding of what's actually going on here).

For posterity, my settings are below:

Port Forwarding Rule:
interface: LAN2 (which is where my pcoip device lives)
protocol: TCP/UDP
source: any
dest IP: 1.1.1.1
dest port: 4172
target IP: NetworkA IP
target port: 6666

Outbound NAT Rule:
interface: WAN
source: any
dest NETWORK: [upstream subnet ]
dest port: [no such parm for the network]
translation: interface address

My current setup is:

isp modem -> udm pro -> pfsense -> pcoip zero client

Thank you again for taking the time -- there is soooo much to learn!

Best,

G

Thanks for the help guys. I have fixed it by setting up a port forwarding for my external IP

VPN wasn't possible because I have not set up 1 for them. I'll use it for the meantime while I'm studying how to set up vpn

@jordanet

Why not setting up the VPN part at the AVM FB and then
you may be securing your entire LAN behind the AVM
with the pfSense? OPNVPN, WireGuard and IPSec are
all on board as today (if your Fritz!OS is fresh enough!)

You connect the AVM FB to the other VPN end, set up
at the AVM FB site also;

Able to open Ports by itself (for the pfSense) Give that device even the same IP address
Or set up an static IP address at the pfSense

You should set up at the pfSense site now;

WAN set up uncheck the private IPs blocking

All should be fine for you now. If there is an NAS, server
or other devices that must be reached from the outside
(Internet) and also from your LAN it is the best to set
them between the AVM FB and the pfSense (real DMZ).

It is common, you can VPN to the AVM and use also the
APPs from them and on top you may be able to use the
My!Fritz service from AVM and by side your LAN is secured
anyway by the pfSense.

@bvohwk said in WAN(local network) to lan pfsense:

Also a rule is made on the wan to allow wan net to any

This is not needed for the NAT rule to work, and it will allow any device in the WAN network to connect to the pfSense web GUI (and DNS, and SSH if enabled). On an Internal network that may not be so bad but if WAN was a public IP address I would strongly advise against it.

@viragomann Thank you for the guidance. I couldn't add a ph2 because the other end wouldn't connect, but I was able to configure the local as 10.0.0.0/8 and that covers everything we need.

The port forward ended up working for 1433 and it went through !

Thank you for your help!

@stgeorge said in FTP Server outbound?:

10 port range of data ports

Are those the 10 ports specified in your FTP server?
Check your logs - there will be blocked traffic calls. I have my own PureFTPd server set up with a hard-set range of ports for transfers and those are blessed in the firewall and it works flawlessly.

@issa2023 and so did you sniff on pfsense to actually make sure that traffic to 32400 got to its wan, so it could forward it..

This is step 1 in trying to figure out what your doing wrong in a port forward - if the traffic never gets to pfsense wan, pfsense can not forward something it never sees.

On your nat device in front of pfsense, you forwarded 32400 to pfsense wan IP that 25.20 address?

@bvohwk
I assume, you have a single WAN IP on pfSense and want to pass access to Proxmox through.
So simply add a NAT port forwarding rule to WAN. State the WAN address as destination and 8006 as port. At redirect target enter 10.10.10.100 and port 8006.
Let pfSense create an associated filter rule.

Additionally you need to disable "Block private networks" in the WAN interface settings to allow access from the WAN net.

You can also assign an additional virtual IP (Firewall > virtual IPs, type = IP alias) to the WAN for this purpose if you want.

However, if your WAN is exposed to the internet, I recommend to use a VPN to access Proxmox instead.

@santammapr
Do you want to go over NAT or do you want to simply access devices behind pfSsense?
Basically there is no reason to go over NAT, but if you want to go this way you might have to assign proper IPs to pfSense WAN. Simply doing NAT 1:1 without assigning IPs would only work if the traffic is routed to pfSense WAN address. I assume, that's not the case.

Anyway if the network on WAN side is a private one as I suspect, you have to disable the blocking of private networks in the WAN interface settings and add proper firewall rules to the WAN to allow the desired access.

@santammapr see https://forum.netgate.com/topic/178996/solved-nat-1-1-for-whole-network-not-available-after-version-2-4-5/2

@soner_balci
The the request does obviously not come from the internet.
Otherwise you should not see a private source IP.

@viragomann Awesome answer! I really appreciate you taking the time and attention to detail, to go through and answer each question. Very helpful!

Had thought of and actually made groups after posting, but the time limit for editing had run out when I tried to do so. Makes sense.

Q6: Apologize, I wasn't clear, I meant referencing the picture. Source any and inverted on LAN address. Should have specified.

Q2: What's been interesting in practice, is although all are on the same rule redirected to 127.0.0.1, some worked and redirected to 127.0.0.1 and others redirected to the static ip on the interface. Therefore those did not work with the firewall wall pass rule specifically for port 53 to 127.0.0.1. I.e. No DNS until 127.0.0.1 was changed to xyz interface address in the pass rule.

Prior to changing the pass rule, the interface static IP could be seen in the firewall logs as -p 53 blocked (from a lower separate block rule to 'this firewall') on many of the interfaces, so had to change the pass rule from single host/alias --> 127.0.0.1 to xyz 'address'. Then once change to just the xyz interface address, dns resumed and all worked again. No changes to the lower block rule.

Any ideas as to why the explicit redirect to 127.0.0.1 would lead to that result on some interfaces, but others redirected specifically to the static ip of the interface? Anything to do with resolver functionality?

edit: When I went back and didn't have it as an inverted rule, but rather * (any) for destination, it redirected to 127.0.0.1 as expected. I'll not delete and leave the above though, for anyone that might experience the same with the inverted rule.

Thank you again for your time and great detailed answer above!

@steveits
Thank you Steve, that explanation makes perfect sense. I never realised it could mess up my setup but I learned the hard way, it took me two full days of troubleshooting, wiping the MacBook and rebuilding its setup before it dawned on me that it came down to my silly mistake. Oh well. At least it broadened my understanding of the way it works.

Hi, I had upnp working behind a private ip using CE 2.6.0. All I had to do was to add an outbound NAT mapping with static port. Now it's not working in 23.01.
Screenshot 2023-04-15 153535.png

@jimp Interesting, yeah I dug through the PHP for it a bit but I'm no expert when it comes to coding so couldn't find a reference to why it would have picked that. Just seems odd to me since it's a higher IP address than the VLAN it's bound to, and it's a VIP, so doesn't really make sense for it to be picked.

I'll see if I can find more info on it purely because I'm curious.

Final reply:
I could not find a way to make this work. The IPSec client was not able to make use of the port forwarding and Outbound NAT rules. The replies form the RDP server never reached the IPSec client. Disabling the firewall with pfctl -d did not make this work either, so i suppose it is some kind of system rule that cannot be overridden (i.e. "do not forward port forwarding replies to IPSec interface".

My solution:
Port forwarding from the firewall that seperates VLAN1 and VLAN2 to the RDP Server
Outbound NAT rule for RDP with the LAN IP address of the pfSense.
IPSec client connects to the RDP port / IP address of the Firewall that separates the VLANs.
RDP Server sees the pfSense as Origin and replies accordingly
pfSense sends packets back to the client with the IP address of the firewall
Request and reply have the same IP address (of the firewall) -> connection established

This is not my prefered solution, but after three days i am out of ideas. I am sure there is a more elegant way.