Wait... so you made two posts about the same problem but with different data? I don’t get it... Jeff

Thanks,PF1-LAN is 192.168.200.25,LAN--PF2 is 192.168.200.17. The problem is the same. ! PF1: 1.jpg

I now have a SYN packet passing through the NAT rule to the LAN NIC. I am NATting to a Windows VM in Azure. I added Wireshark to that VM. The SYN packet never reaches the VM. Also, I can ping the LAN NIC from the VM (I added a firewall rule), and I can ping the VM from the pfSense server using an SSH connection. On the Azure VM network security group, I have opened access to anything from the Azure local vnet. On the Azure VM, I have disabled the Windows Firewall. On the pfSense LAN NIC, I have added a firewall rule to allow all TCP traffic. So it looks like the packets to be NATted are being blocked on the way out of the LAN NIC. Any ideas? anyone?

The issue is resolved by removing this rule. I don’t understand where it came from [image: 1566321243757-4.png]

Thank you for your quick reply. I follow this article to setup the tunnel and configured the firewalls according to it. The servers are reachable when i disconnect the VPN connection on router2. The host names are resolving to the external IP of router1. I have set up the firewalls according to the above article. The servers are reachable when VPN is disconnected. Yes, as far as I can tell. Yes, as far as I can tell. UPDATE: I am not able to ping the remote external IP of router1 (ICMP timeout). Maybe that's a hint to something....

Thank you for your answer, yes i am using openvpn as my tittle said. i am running vpnclient on pfsense on both sides.

@Derelict You are perfectly right: one day later the problem is gone. I've changed a lot this day (and I am not an expert, so I have tested some ideas to find out they did not work), thus I assume I have caused some trouble on the network with needed some time to settle down.

Yeah putting a router on the same backside subnet like that will only cause you grief and pain.

Hi Steve, how are you? Seeing no problem during Polycom calls, I noticed that by selecting the "NAT is H.323 compliant:" checkbox does not connect to final destination, I will clear the H323 checkbox and select the H460 "Enable" checkbox. H. 460 "-Firewall" as shown in the image below. [image: 1566244217010-captura-de-tela-de-2019-08-19-16-30-25.png] Best regards, Wesley Santos

yes of course at home i'm using it only for toy/learning experience/test etc etc sure not something to do for work where we have professional ip with rdns and stuff configured as it should

Your 3 posts have been your having issues with ftp - but you have yet to get 1 detail that could actually let us help you. Your ftp server is where? Where is your client? Are you active or passive?

The traffic wasn't leaving on any interface. It turned out there was no default route in the route table. I changed the default gateway from the failover group to a specific one and a default route was created. Changed it back to the failover group and the default route stayed. I found this https://redmine.pfsense.org/issues/9004 because I'm still on 2.4.4_2 (didn't see the update notification because the firewall couldn't reach the servers to check....) What an annoying bug.

You will probably need a mirror port on a switch to a traffic analyzer for data like that.

@ptt said in Access port 80 on WAN GW: Just.... http://10.0.0.1 hehe what have I done wrong ? enter wrong IP adress ? I have played with rules etc... hehe THank you :)

@camay123 said in Outbound nat port 25 to external IP: catch all outbound port 25 smtp traffic I just block all outgoing "port 25" connections. Because I control all my mail clients on my LAN, and they use '465' for outgoing mails. I also run a Captive Portal : same rule.

Strange my settings where actually OK - Just needed toi change it to an ALIAS instead of IP address Now with 5 working public IP's

@rsaanon said in Selective NAT/Outbound to ISP or VPN Provider: For one LAN subnet, outbound connectivity should go through the VPN Provider Interface (VPN) Why would you not just policy route that? Don't pull routes, leave your rules on automatic, create a hybrid rule for the outbound nat for your vpn interface. And yeah as stated there just is no point to hide rfc1918 address space..

Yeah this was never pfsense, if you see the traffic sent on the pfsense lan side via a sniff. Pfsense did exactly what you told it too do.. See packet on wan, forward it to xyz on port abc.. If there is no answer that has nothing to do with pfsense. To be honest in the like 12 years I have been here, I don't actually recall ever a port forwarding question that was ever an issue with pfsense..

@Pippin Thank you for the reply. I went into VPN -> OpenVPN -> Clients and edited my client's configuration. Under Advanced Configuration I put into the custom options "ns-cert-type server; persist-tun; persist-key; mssfix 1400" and then saved. I then reloaded the VPN by going to Status -> OpenVPN. I did the usual ping/nmap verification checks to confirm connectivity. However this does not seem to have done anything. Below is a picture of the wireshark output (with the TCP stream from the browser being currently selected) and below that is the capture file. [image: 1564770848390-untitled.png] mssfix1400_full_cap.pcapng