@Tzushca There's a list of things to check here:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html

@viragomann The 1:1 nat to the 2 internal Ip's worked so thanks for everyone's help. Much appreciated.

@rossc719

I did find another solution to this problem, and it is no more harmful (I believe) than the default operation of a firewall if done carefully. It could possibly be fine-tuned somewhat, by placing this rule at the bottom of a rule list. I'm sure others here will advise. I only needed mine to transfer a few email accounts, to new email server software that had been installed. It needed to be run on the same server, and I had to use the reflection used for incoming external email, to get out of the machine. Once done, I disabled the rules.

I created a rule for the VLAN for our mail server to allow All outbound traffic through the firewall to the web, reflection redirects it back again if it's on the same ports as per the inbound NAT rule.

Action Pass
Interface MAILSERVER
Address IPV4
Protocol: TCP

Source: Single host or alias, Mailserver_ip
Destination …
**Invert match: Checked
LAN.net ← Lan for users – this blocks the email server from connecting outbound to the main_lan via reflection
(You may need to set a rule for each VLAN if you intend to run it permanently, I had to do another for our phone system)

And that's it.

I hope it's useful to someone.

Mike

Rookie mistake. Testing using a cell phone and missed the DNS issues on the new subnet ;(
Thanks for being so responsive.

@viragomann said in PLZ Help!!! Failing at Publishing a Nextcloud Instance:

The source address and port have to be "any"

good catch - yeah that is wrong too for nat..

Happens to be a user-error! :shushing_face:

A typo.

@SteveITS

Yes, OK, I got it. It is no longer blocking everything else so the rule works, but the issue with my Android, eludes me.

Thanks for the very patient help.

@viragomann
I'm having more than one DNS issue, not just mine.
At the moment I preferred to do two things: move all my DNS back to the original ISP and install a new pfSense, testing it step by step with every change because now the only way to make it work is to have an "all open" rule, but this is not possible.
I put this thread on stand-by and if necessary I open a new one for DNS.

In the meantime, I thank you

@mcury thank you, that fixed it

@twg

Where are you trying to ftp from?? Where is the client?

So this server is on say 192.168.0.100 behind pfsense.. And you out on the internet want to ftp to it..

So you forwarded 21 to your ProFTPD Server (ProFTPD) [192.168.0.122] on pfsense.. Did you forward the passive ports? You setup in proftpd to use?

Did you setup proftpd to send your correct public IP?

I connected to the IP you use to connect to the forums so I could see if ftp even answered.

For passive to work, you also have to forward the ports the server will use for its passive ports.. I can not get logged into see what it sends, If you PM me an account that would work I could see what its sending for the port, or try active where it would connect to my client.

Is your server a plesk?

https://www.plesk.com/kb/support/how-to-configure-the-passive-ports-range-for-proftpd-on-a-plesk-server-behind-a-firewall/

It defaults to a really large passive range 49152-65535 , I would for sure change that to something more like 100 ports or even just 10 if you don't have lots of clients at the same time.. Then you need to forward those ports on pfsense to I assume 192.168.0.122, without the passive ports being forwarded then no the data channel will never work when the client uses passive mode. Even if you told the client to use the IP you connected to when the server sends rfc1918 IP.

@VincentEmmanuel
The outbound NAT should not be required here. All traffic will be controlled by routes if pfSense is the default gateway in both networks.

With the static route, when the DMZ server sends a packet to 172.16.1.3, it is routed to pfSense, since that's the default gateway. pfSense forwards it to the CATO due to the static route and the CATO forward it to the destination host, since it knows the route to it (however, your graphic is missing 172.16.1.3, so I don't know, how this is set up).

Presupposed the CATO is the default gateway on 172.16.1.3, the response packet will be routed to it, and there it is forwarded to pfSense, since this is the default gateway on the CATO, as you said. pfSense has an existing state for the packet and will forward it to the DMZ server.

@pedreter it is routed through pfsense is it not?

If I look up in the internet routing.. for the IP on this server it ends up on the pfsense wan IP does it not? If the network is routed at the isp and you bridge this network to the servers.. I do not think the redirection via a port forward would work..

@depam said in Utilizing single tunnel to be routed to different gateway:

Anyway, the latency between Site B and C is quite high hence I want to route it via Site A which is faster since its already in the hosted in AWS cloud.

I don't get it. If there is high latency from B to C I'd assume, it's either on the B's upstream connection or on C's. So if you go from C > A > B > internet, I'd expect that you have at least the same high latency, since the problematic path is inevitably part of this new path.

Preferrably, go to Site A but can have the slower connection as backup via Gateway Group. I have tunnels across all sites A, B and C configured with /30 (Peer to Peer TLS) approach similar to the depracated Shared key. In addition, Site B have openvpn client connecting to an external site.

The problem you're facing with this is, if set the routes in the VPN connections with the "Remote Networks" and both VPNs are connected (A <=> B / A <=> C and B <=> C) you would have two routes between B and C. I don't know, which one is taken in this case. I guess, that one which is established at last, but not sure.
So I cannot say, that this will work as intended.

However, it should work if you desable B <=> C though.

How did you configure the gateway groups?

@viragomann That Worked!

Thanks a lot ✌

Also make sure you are not blocking multicast traffic if you are UPNP will not work.

@viragomann Thanks, I'll check the link.