VIP direct to host, no NAT?
-
So in ESXi you have a vswitch on with the WAN NIC connected to it and all the VMs that need a public IP get a NIC that is also on that vswitch and you just set a public IP on that VM.
I assume the gateway set on the VMs is the ISPs upstream router in the public subnet?Then I agree that is not a routed subnet and you can only use those IPs in the same layer2 as the ISPs router.
How is the pfSense WAN connected to that?
What have you actually tried? What happened?
-
In ESX, I have no special config what so ever.
The only thing configured is the management IP which is on the LAN side.Traffic from public IP subnets are routed to the ESX host and either something responds or it doesn't.
A mail server for example, is configured with one of the public IPs so it responds. It doesn't have a LAN IP at all. It's IP is set to the upstream router for gw.The pfsense is not involved in this in any way, traffic is direct to the vms if they have a public IP.
On the LAN side, if something comes in that should be NATed to a LAN address on any vm on the same host, then pfsense handles it but as mentioned, it's NATed.
I didn't try anything on the pfsense side of things but it clearly wasn't working when they moved the subnet in error before I was ready.
Traffic to the ESX host/vms simply stopped dead. They routed the subnets to pfsense and nothing was happening.
That's when I decided to enter the IPs as VIP's and see if there was a way to forward WAN to LAN/VLAN to see if vms would respond.
That was a no go so I had them reverse the change so I could look into this otherwise I'd have kept it working that way even if I was not ready for the move.
-
From everything you're saying this is not a routed subnet. The DC simply put that subnet on the link. So it's not routed to ESXi or to pfSense.
If they moved the subnet to the pfSense WAN then you could use those IPs using VIPs in pfSense and port forwards but those public IPs would have to be removed from the VMs. They cannot exist in both places.
The VMs must reply via pfSense so will likely need that to be their default route.Steve
-
I have another subnet that was also moved to that server (pfsense).
So basically, just use the public IP on the vms but set their gw to pfsense and NOT add the test IP in VIP.I could test that.
-
No you can't use the public IPs on the VMs if the DC have moved the subnet to the pfSense WAN segment. pfSense cannot route that traffic as it would then exist on WAN and LAN.
You have to use VIPs on pfSense and port forwards to the VM private IPs.
Then in order for the VMs to reply back via pfSense they must have a route back that way. So either a default route or at least a route to the source of the incoming traffic.
You could use an outbound NAT rule on the pfSense LAN to allow the VMs to reply without changing anything on the VMs but they would lose the source IP info for the traffic. That may or may not be important for your application.Steve
-
Understood. Just hoped there might be some not well known way of creating some sort of zone on the WAN side that could forward to hosts with public IPs rather than going through the firewall.
Guess I have a lot of work ahead of me.
Thank you very much Steve for your help.
-
The only way you could do that would be to bridge the interfaces in pfSense. But you would still have to move the public IPs to the other interface on all the VMs, or swap the NICs. And it would break everything else behind pfSense(that would now be in the WAN subnet) unless you used a new interface.
If it was a routed subnet the DC would just change the route and you could add a static route to pfSense. But it isn't from everything we can see here.
Steve
-
Yes, time to get to work it seems. Thanks again.
-
At first, I really don´t know the goal you try to reach here.
I have some servers that have public IPs directly.
Again, those hosts have public IPs, they are not NAT.There are two well known and common ways to realize it.
-
You set up the real public IP adresses on the pfSense
firewall directly and private ones on the servers. -
You set up the real public IPs on the servers, but you
also install and enable LightSquid between the firewall and the servers in the DMZ, that they will not having pure contact to the internet itself but they are useable and reachable.
Dobby
-
-
@dobby_ said in VIP direct to host, no NAT?:
At first, I really don´t know the goal you try to reach here.
The problem is that the IPs have to move away from the hardware that they are on now. However, the only place to route them is to the network where pfsense is installed.
I cannot have any down time and I cannot change some of those servers to NAT as doing so would become rabbit holes that we don't have time to deal with right now.
The easiest thing would be if there would have been way to let the IPs hit the firewall but that traffic get forwarded to the servers that already have those public IP's so that no changes need to happen other than something on the firewall.There are two well known and common ways to realize it.
Well known? I don't think this is well known to most because I can tell you that I do a lot of searching before I ask in forums :).
- You set up the real public IP adresses on the pfSense
firewall directly and private ones on the servers.
I assume you mean as VIP's then?
- You set up the real public IPs on the servers, but you
also install and enable LightSquid between the firewall and the servers in the DMZ, that they will not having pure contact to the internet itself but they are useable and reachable.
Just so you know, I have no additional interface on that pfsense. It has two only so I suspect this would not work in my situation.
I certainly could install another server on the LAN side with LightSquid for example but that would imply that those VIP (or other method) would know how to reach the LightSquid server to be forwarded on.
Sounds a bit complicated for my environment which is already quite complicated.
- You set up the real public IP adresses on the pfSense
-
I don't think a reverse squid proxy will help here. Though it may be worth looking at if the servers are all web servers. LightSquid is the traffic analysis add-on for Squid.
There are only two ways I can see this working without changing the VMs and I don't think either is suitable for your situation.
Some sort of bridge between the pfSense WAN and the hypervisor so the VMs are still in the same layer2 as the DCs gateway.
VIPs on the firewall with port forwards and outbound NAT so the VMs reply back via pfSense. They will lose any source IP data though.
Steve
-
I started looking at what it will take to add private IPs on some of the servers. It would have been a lot simpler to just leave the guests as they are but sometimes, there is no magic to keep life simpler, you just have to do what you have to do.
-
Ah, if some of the VMs don't have private IPs that pfSense can reach already then that might be all you can do.
Otherwise it's really only the bridge option and that would definitely be a last resort solution for me.Steve
