Responding to port 80 on WAN side
-
By default pfSense will redirect requests on port 80 to the webgui https port. Obviously that's usually blocked by the firewall on WAN. You wouldn't want to use that to respond to TCP heartbeats though.
It might be possible to do something with HAProxy though I've never seen it used like that.
Really it's better not to use the firewall as a server if you can avoid it.Steve
-
@stephenw10 said in Responding to port 80 on WAN side:
Really it's better not to use the firewall as a server if you can avoid it.
Agree completely with that... If you want to better leverage some decent hardware you were using for this. Why not just something like a little rasberry pi, or just a VM/Docker running on something else? If all your doing is answering with a 200 to some clients I would think a little raspberry zero model would work. If you didn't want to use it via wireless, they sell etherenet hats or usb to ethernet adapters that work with them for a few bucks.
-
If the clients are doing nothing more than a TCP handshake one thing you could do here would be to use a firewall rule on WAN with keep-state disabled and set to pass TCP:SYN only. That way only the initial handshake could ever succeed.
Not sure exactly what the UDP port response has to be though. Simply 'allowing' UDP ports does nothing.Steve
-
@stephenw10 sounds like he wants more than just the SA, I think he wants the 200 returned..
If I had some decent hardware that was being under used, and wanted to use it for more elsewhere - but maintain the little thing it was doing. I would just replace that little thing with min thing that could do it. A little pi would seem like a good cheap solution here to me, they sell little poe hats for them as well. So you could have really the little device just plugged into poe switch that would provide this function..
-
@johnpoz said in Responding to port 80 on WAN side:
I think he wants the 200 returned..
Ah, good point.
-
Thanks for all the responses. I think I need to clarify some things.
I cannot add/remove hardware, it's a server in a data center and it has these resources, no more, no less.
The server (like others in various data centers) is dedicated to this one function. The smallest servers are quad core with 16GB of memory and a gigabit connection to the Internet. They use
The TCP response is simply a 200. Text was stripped as much as possible to limit the amount of data transferred between clients/server as it's useless traffic. The UDP ports are just an ICMP tool, they don't actually respond to anything, they just need to be there with ICMP echos enabled. They use less than 1TB of data monthly and around 3Mbps 24/7.
They do nothing else so I'd like to convert one to something more useful, like a pfsense firewall then I could move some traffic over to these underutilized resources.
The problem is trying to figure out what, since the machine has to give a 200 response to the clients. At worse, I could convert one to a pfsense firewall and have those connections going to an internal server but I'm trying to search to see if I could get a WAN side response before doing that.
-
Hmm, that seems like the sort of function that should be using a VM or a container. Generally much better resource use with virtualisation.
-
It's a bare metal server because a vm or even a vm host doesn't work. It has to be direct to the machine, no sub layers between the clients and server.
-
That's hard to imagine. You have any details of why it requires that?
If clients are remote there's no way they could know if the target is a VM. As far as I know at least...
-
@stephenw10 even if they were local - how would anything possible be able to distinguish if vm or hardware - other than what the mac is for example. But those can always be changed to really anything you want.
I host a website to you - how could you possible know if that is being served off a VM or or actual running on the hardware - I don't buy it.. Maybe some nonsense your DC guys are giving you? That you can not run VM hosting software?
-
The reason is that the virtual hosts own network can respond and that causes false readings. It has to be direct.
Anyhow, it sounds like there is no way to do this so maybe it's a moot point.
-
@lewis said in Responding to port 80 on WAN side:
The reason is that the virtual hosts own network can respond and that causes false readings. It has to be direct.
Well if you don't setup your VM host and VMs correctly - that is on you. You can have a host that has no IP on that Layer 2, etc.
The HOST doesn't need to have any interaction with the nic or nics that are part of the host.. If you do not put an IP on the nic, there is no way for the HOST to respond to anything that hits that network card. Only the vms that are using that physical nic would be able to respond, and it can be a completely different mac than what is on the physical nic, etc.
-
The hosts are not set up incorrectly but as I said, using a vm behind a host cannot work as that causes false readings. It's my customers technology, they developed the software, have their own dev teram etc, I cannot argue their side, I'm only looking into the firewall side.
Anyhow, you've pretty much already said it cannot be done and so be it.
Thanks for your help.
-
@lewis said in Responding to port 80 on WAN side:
using a vm behind a host cannot work as that causes false readings
Responding with a 200 on port 80 for http..False readings? Ok sure ;)
If this company says they do not support running their software on a VM, ok sure - but seems like BS to me that is for sure.. You understand that most of the internet is running on some sort of VM somewhere.. What do you think make up all these CDNs serving up Millions and Millions of sites.. But this software that wants to see a heartbeat of a 200 returned when hit port 80 can somehow detect its a VM in that 200 response ;)
-
Mmm, it would be interesting to know what they're doing there.
If it really is something completely custom that requires bare metal that would almost certainly rule out running it on pfSense at least.
Steve
-
@johnpoz, I've done nothing for you to act so childish in this question and have provided what ever information I can but you just keep on making assumptions and even saying my info is BS.
There is nothing mysterious here, it's just something where I cannot share the customers technology. They are doing something that's proprietary and that's that.
The only thing I can share is my mention of UDP and that's where it doesn't work with a host, it has to be bare metal.
Again, thank you for your help.
