I figured it out. Initially, the packet below would travel correcly, like so: REQUEST: Client -> Site B WAN -> Site A Webserver RESPONSE: Site A Webserver -> Site B WAN -> Client Occasianally, this would happen: REQUEST: Client -> Site B WAN -> Site A Webserver RESPONSE: Site A Webserver -> Site A WAN -> Lost/dropped packet The packet is going out the wrong WAN, thus getting dropped See diagram: +-----------------+---------------------------------------+-------------------+-----------------+ | Internet | Site A | Site B | Internet | | | | | | | | | | | | | | | | | | | | Packet | | <-----------------------------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ +---+ | +---+ | +---+ | | | | | | | | | | | | | | | | | +-----+-----+ | | | | +-----+-----+ | | +-----+----+ | | + | | WAN | | | | OPENVPN | | WAN | | | | 1.1.1.1 +---+ +---+ | +---+ 2.2.2.2 +---+ | | | Web pfsense | pfsense | Client | | | Server 10.0.1.0/24 | 10.0.2.0/24 | | | | 10.0.1.100 | | | | | | | | +-----------------+---------------------------------------+-------------------+-----------------+ Site B NAT +-----------+----------+----------------+--------------+---------------+-------------+------------+-------------+-------------------------------------+ | Interface | Protocol | Source Address | Source Ports | Dest. Address | Dest. Ports | NAT IP | NAT Ports | Description | +-----------+----------+----------------+--------------+---------------+-------------+------------+-------------+-------------------------------------+ | WAN | TCP | * | * | WAN address | 443 (HTTPS) | 10.0.1.100 | 443 (HTTPS) | Site B Internet to Site A Webserver | +-----------+----------+----------------+--------------+---------------+-------------+------------+-------------+-------------------------------------+ Site B Outbound (Source) NAT +-----------+--------+-------------+---------------+------------------+-----------------+----------+-------------+-------------+---------+ | Interface | Source | Source Port | Destination | Destination Port | NAT Address | NAT Port | Static Port | Description | Actions | +-----------+--------+-------------+---------------+------------------+-----------------+----------+-------------+-------------+---------+ | OpenVPN | any | * | 10.0.1.100/32 | 443 (HTTPS) | OpenVPN address | 443 | | | | +-----------+--------+-------------+---------------+------------------+-----------------+----------+-------------+-------------+---------+ Site A Firewall Rules OpenVpn Interface (interface not assigned) +--------+----------+--------+------+----------------+------+---------+-------+----------+-------------+---------+ | States | Protocol | Source | Port | Destination | Port | Gateway | Queue | Schedule | Description | Actions | +--------+----------+--------+------+----------------+------+---------+-------+----------+-------------+---------+ | 0 /0 B | IPv4 * | * | * | SITE_A_LAN net | * | * | none | | | | +--------+----------+--------+------+----------------+------+---------+-------+----------+-------------+---------+ The fix was to assign Site A's OpenVPN connection as an interface and create the firewall rule there instead. Also, you no longer need a Source NAT at Site B. The combination of rules to get the packet routing back to Site B's WAN consistently is below: +-----------------+---------------------------------------+-------------------+-----------------+ | Internet | Site A | Site B | Internet | | | | | | | | | | | | | | | | | | | | Packet | | | +--------------------------------------------------------------+ | | | | | | | | | | +------------------------------------------------------------+ | | | | | | | | | | | | | | | | | | +---+ +---+ | +---+ | +---+ | | | | | | | | | | | | | | | | | | | +-----+-----+ | | | | +-----+-----+ | | +-----+----+ | | v + | | WAN | | | | OPENVPN | | WAN | | | | 1.1.1.1 +---+ +---+ | +---+ 2.2.2.2 +---+ | | | Web pfsense | pfsense | Client | | | Server 10.0.1.0/24 | 10.0.2.0/24 | | | | 10.0.1.100 | | | | | | | | +-----------------+---------------------------------------+-------------------+-----------------+ Site B NAT +-----------+----------+----------------+--------------+---------------+-------------+------------+-------------+-------------------------------------+ | Interface | Protocol | Source Address | Source Ports | Dest. Address | Dest. Ports | NAT IP | NAT Ports | Description | +-----------+----------+----------------+--------------+---------------+-------------+------------+-------------+-------------------------------------+ | WAN | TCP | * | * | WAN address | 443 (HTTPS) | 10.0.1.100 | 443 (HTTPS) | Site B Internet to Site A Webserver | +-----------+----------+----------------+--------------+---------------+-------------+------------+-------------+-------------------------------------+ Site A Firewall Rules OpenVpn Interface (assigned interface) +--------+----------+--------+------+----------------+------+---------+-------+----------+-------------+---------+ | States | Protocol | Source | Port | Destination | Port | Gateway | Queue | Schedule | Description | Actions | +--------+----------+--------+------+----------------+------+---------+-------+----------+-------------+---------+ | 0 /0 B | IPv4 * | * | * | SITE_A_LAN net | * | * | none | | | | +--------+----------+--------+------+----------------+------+---------+-------+----------+-------------+---------+

Haproxy can receive traffic on the pfsense-wan ip that comes from a internal network just fine (normally at least, maybe if its a ppp interface that could change things.).. Using split-dns tricks isn't needed either.. I do agree that opening the admin page of a consumer NAS to the world-wide-web wouldn't be advisable. (Perhaps if you secure it by using client-certificates it would be okay..) For this purpose listening on a lan-ip with a specific frontend could be nice to have some separation.. As for why it doesn't currently work.. thats pretty much impossible to tell without some more information about what you did and didn't configure.. Perhaps sharing a haproxy.cfg from bottom of settings tab would help us help you..? Or telling something about your network layout / subnets / IPs used for client / pfSense / NAS.

Ok.. Got it. I was assigning DNS entries from my PFSense box which was using NordVPN DNS servers. I plugged in my ISP DNS entries and voila'... All is good now.

Trying Manual Outbound NAT also. I found that rules weren't created so I found out that I didn't have a gateway set, once set the rules populated. [image: 1584717584051-screen-shot-2020-03-20-at-8.19.05-am.png] So now I'm back and can ping out to the WAN gateway but The rule that should disable NAT for source 192.168.1.0 dest 192.168.2.0 doesn't do anything even if I put it on top. [image: 1584717842746-screen-shot-2020-03-20-at-8.23.40-am.png]

No it had not cached dns.. Once you set an override any "cached" records would of been overwritten since the act of creating a host override restarts the dns service.. You were not pointing to pfsense for dns..

I'm an idiot. I'm so used to cisco fw rules that I totally misinterpreted this. I feel Sheeeeepish ;) Thanks man! you truly deserve the thumbs up.

Order priority of NAT rules ? I advise you to use firewall rules to achieve known ordering. See https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html and https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-queries-to-external-resolvers.html

@g146m026 no worries. I'm getting a bit further now. I got packet capture from the WAN side and I can see some 443 traffic trying to hit 8123 but getting dropped. [image: 1584570748132-2020-03-18_2318-resized.png]

I would prob look to doing a packet capture of the traffic to see where your having a problem as a good place to start.

@bbirdwell said in Connecting to printer across vlans: Its awful annoying to have to jump on my home wifi every time I have to print something. Ypu want to make your printer available to a (your) device on the Internet ? The first part of your question : VLAN are the same thing as LAN's here. Example, you have a LAN interface setup like the default 192.168.1.1/24 - a printer having, say, 192.168.1.10 on this LAN. When you connect to another LAN, like 192.168.2.1/24 - you could use the IP of the printer - 192.168.1.10 and print just fine. Jo just use your router as a ..... router. If you have firewall rules on your second 192.168.2.1/24 interface that block access to the first LAN, 192.168.1.1/24, you have to place a "PASS" firewall rule on 192.168.2.1/24 interface. Now your are using your router as a router, and firewall ^^ Note : the second LAN on any pfSense has no rules, thus it blocks everything initially. You have to add some rules to make it useful. [image: 1584440750681-931bb871-967d-4968-87a2-88ea4f61dece-image.png] The printer alias is the list with IP's of all my printers on the LAN interface. With this rule on my (captive) PORTAL interface, my captive portals visitors can print on my printers. Note : my visitors don't no sh*t about my printers, neither the IP nor network names, but the Avahi packages, and the DHCP registration into the DNS, makes devices that are capable to printer to find them, list their capabilities, and print.

It worked with NAT Reflection. Thanks

@viragomann yes, that is what that rule is doing on the sonicwall, s-nat and d-nat on the same rule while also matching a port/service. as you suggested the way to do that on pfsense is to use both port forward and outbound nat to achieve the same. the thing is: there's hundreds of those rules, and they will need to be maintained in the future, effectively doubling each sonicwall rule while migrating them to pfsense will make maintenance much harder. My IT manager suggested looking at using 1:1 NAT rules and dealing with service/port matching in a different ways, maybe something can be done to effectively do that using firewall rules or policy routing. I'm in the process of exploring those options on a test deployment in our lab, any suggestion towards that would be greatly appreciated.

And you also need to do this for all domains hosted on local mail servers. And also manage this and external dns changes as needed.