Https port forward on non-standard port failing
-
Not new to the port forwarding game or pfsense (onboard ~V1.2).
I'm trying to hit an embedded device from a web server for the purpose of locking the firewall to only the web server IPs, because I don't trust the embedded gadget to be secure if I were simply to port forward its interface.
This works as expected when forwarding 443 to one of the devices, but there are two of these things so I was going to put them on port 6443 and 6444 or somesuch and redirect them to the right gadget. Obviously I went to the NAT rules, told it what to do and let it generate the firewall rules.
The problem of course is that it's not working. curl says "connection refused", and packet capture on the pfsense WAN shows SYN packets hitting the firewall and getting no answer. The only slightly unusual item is that I used an alias for the four IPs of my webserver, but that's the same in the plain 443 forward I was testing with. I've tried it with just one of the IPs as well and get the same results.
I've spent a solid hour or two thinking it through and I'm forced to blame the firewall, but I just can't figure out what could be different or unusual about the situation. This same firewall has 2222 forwarded inside to 22 for ssh on a machine. Any ideas anyone?
-edit-
Further info. I considered the possibility that this is some problem with https over a mix of ports, but I would think the NAT should handle that. I'm running php-curl with verifypeer and verifyhost set to false because the gadgets have self-signed certs. This problem also occurs when running curl manually on the webserver via ssh.
That said it's the packet capture that has me blaming pfsense… it clearly shows the connect attempt from the source IP getting no response hitting the WAN. I've never had pfsense fail at port forwarding?
- edit-
Yes I realize pfsense doesn't fail at port forwarding, users fail at configuring it. That said, I'm looking at two NAT rules that only differ in the wan destination port. One works and the other doesn't, and both NAT rules wrote their own associated firewall rules. I'd love a theory that doesn't involve pfsense doing impossible things, but that's where the evidence has me.