Delete 1,,2,3,4,5,6,7,8. There are useless. Normally, on a WAN interface you have no rules at all. Exception : NAT rules .... Rule 9 is part of a NAT rule ? There should be a "from port" as there is a "To port", the 59045. Do not edit the firewall rule, edit the NAT rule. What are you trying to achiueve with these WAN firewall rules ? The NAT rule is for what ?

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