VIP direct to host, no NAT?
-
I have some servers that have public IPs directly.
Again, those hosts have public IPs, they are not NAT.I have added the virtual IPs to the pfsense and now trying to find a way to directly route from the firewall to the servers which have those IPs and not internal NICs.
I don't think there is a way to forward traffic unless it's to a MAC address or some other way I'm not familiar with.
Is there a way?
-
If the servers are using the IPs directly you shouldn't have any VIPs on the firewall.
The traffic is routed directly, you only need VIPs for port forwarding traffic when you can't use the IPs on the servers directly.Steve
-
@stephenw10 That's interesting but it didn't work that way.
The DC accidentally swapped the IPs from an ESX host to the firewall.
The guests/servers instantly became unreachable.
I entered the IPs into the firewall as VIP's but nothing happened.So in other words, before I entered the IPs and after I entered them, those servers were no longer reachable.
I have another IP range on the firewall not being used so I could test what you're explaining.
-
Yes, if the DC put them on the firewall directly you can no longer use them on the servers directly. You'd have to use private IPs on the servers and forward the traffic to them from the VIPs on the firewall.
That's the difference between a routed subnet and just getting more IPs on the host in the gateway subnet.
The public IP can either be a VIP on the firewall or on an internal host directly but not both, that breaks routing.
-
I should clarify.
When the put IPs on devices, the IPs are not physically entered into the device. I control that. It means that their router/s are sending traffic to that IP range to that device and it can do what ever it wants with them.
For example, prior to this change, those subnets were pointed to an ESX host. I didn't have to enter anything in the host itself to use them, I could simply add a public interface on a vm/guest and use the IP.
There was no firewall handing the IPs so all traffic could be seen on the public interface.
Moving them to the firewall means all public traffic is being seen by the firewall interface.
Unfortunately, that firewall only has two interfaces otherwise, I might be able to something else like a DMZ maybe.
-
So what exactly are you trying to do here?
If it's a public subnet that is routed to the firewall via a different IP (outside that subnet) then you can do whatever you want with those IPs.
If the pfSense WAN is in that subnet you have to use VIPs and port forwards.Steve
-
Example;
Server in DC has two NICs, One WAN, one LAN.
Server is configured as ESX host.
DC points a subnet to this hosts public interface.Some of the virtual machines have either only a public or a private IP or they have both in some cases.
The public side is direct Internet access while the private side routes through pfsense where all LAN sided servers can communicate.So, when I need to give a virtual machine a public IP, I don't have to add anything to the host, I simply assign one of those IPs to the public interface of one of the virtual machines on the host.
As mentioned, some of the machines don't have LAN IP's so mail server for example and some DNS servers etc.
I have to shut down one of those ESX servers but I have to keep those same IPs otherwise the move gets much more complicated.
All my other networks have pfsense on their public interface.
This is what I was told by the DC.
For subnets, we set it up as gateways on your vlans within front end >switch. Traffic is not routed but subnet is configured on desired
server's interface. -
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
