No ipv4 set on interface, only virtual ip set - is this wrong?
-
We have a pfSense VM on Proxmox and a couple of public ip address ranges in use.
The primary range is setup on the WAN port and is a /25.
We have quite a few internal VLANs on the LAN bridge interface.
For a particular host (VM guest) we then create a virtual ip from the public WAN range with a /32 mask. We also set a 1:1 NAT for that address to the internal LAN address of the particular host and add firewall rules as needed.We use CARP to facilitate failover with another pfSense instance, so we need virtual ip's set up with CARP.
For example, supposing 197.213.66.0/25 is the public ip range, we would add 197.213.66.10/32 as a virtual ip and set up 1:1 NAT for 197.213.66.10 to translate to 192.168.10.55.
The above works well.
We have a second public ip range we use for VM guests that require a non-NAT'ed public ip. We created a separate VLAN (25) for these guests. The VLAN is added as an inteface to pfSense as BLA_PUBLIC. In the interface config, the public ip range has been added as a /28 network and this makes the ip addresses available to the guest VMs.
We have a third dedicated public ip address range (/28) for a specific group of servers. Although we have a VLAN for these servers and the virtual ips with CARP have been added (as a /28 vip range), the interface does not have an ipv4 range added. When I look at the routes, this /28 is there, correctly routing to the WAN port (through which all these ranges route).
Now come the actual questions: Should we add the ipv4 /28 range to this interface or does adding it a vip's achieve the same purpose?
Will I disrupt traffic if I add the ipv4 /28 to the interface now?
3 ranges, different setups, similar results. I'd like to set up all in the same way. Which way should it be done correctly? -
This post is deleted! -
Are you using this new range directly on hosts or NATing the IPs?
If you're using them directly you'll need at least one IP on the interface to use as a gateway for the hosts.
-
@stephenw10 We're using them to NAT to the host via the port forwarding interface under NAT. It works 100%, but there is no ip address assigned to the interface.
Note: This ip range is routed through the WAN gateway as are all the other ranges. So we don't have multiple gateways.
-
If you're NATing to an internal private subnet then the pfSense interface in that subnet must have an IP address in it. Otherwise pfSense could not send traffic to hosts there and hosts would have no route to reply.
But since you say it's working already I assume something else is happening. Maybe you're saying the WAN interface doesn't have an IP address in the new /28? That doesn't matter as klong as it's being routed to you via some public IP that does exists on the firewall.
-
In the above 1, 3 and 4 have ip addresses in their interfaces, but 2 not. This is from the routing table in the GUI. As it shows:
1 is routing to the WAN with is vtnet1.650
2 (the one that doesn't have an ip in the interface) also routes to the WAN vlan
3. This is interface for un-NAT'ed hosts (no route to WAN port, so it's directly connected from the guest VM's to the upstream router I think?)
4. The default network on VLAN1, also routing to WAN vlan 650.From this, it seems to be that creating a virtual ip address creates a route even if there is no ip address set on the interface that these addresses are NAT'ed to.
-
To clarify the setup I have created a graphic representation:
All the public ip addresses are routed via the WAN port. The purple and yellow VLANs are all on the LAN port bridge. Like I mentioned earlier, we have a CARP vip for each ip address that is in use, be it a network or a single /32 vip address, including the public ip addresses used on the the yellow VLANs (15 and 16).
It now seems to me that the virtual ip's provide the mechanism for traffic to be routed and/or NAT'ed to the correct VLAN and hosts and the VLANs that have hosts with public ip addresses don't need to have public addresses specified on the interface that their VLAN connects to in pfSense. Is my assessment correct?
Since this is not a test environment, I don't want to experiment with settings, but rather gather info about which changes to make and then test then during a maintenance window.
-
Yes in the base OS adding a secondary IP to an interface (using a VIP) still adds that subnet to the interface.
I assume you're doing that so that you don't need to use two of the available IPs from the subnet on the firewall pair?
-
@stephenw10 Yes, we set up a vip so that in the event of a failover it's business as usual.
However, we add the ip addresses of each firewall on the interface. 192.168.100.1 (vip), pfSense01 interface for VLAN 5 is 192.168.100.2 and pfSense02 interface for VLAN5 is 192.168.100.3.
Are you saying that we don't need to set 100.2 and 100.3 on the interface and can set a 100.1 as a vip only? -
@stephenw10: I tested this. If I don't set an ipv4 on the interface of the VLAN, then I cannot add a vip on that interface.
-
Normally you would have one CARP VIP from a public subnet on the WAN and one IP from that subnet on each node. So that uses 3 IPs from the subnet.
If you have additional public subnets on that WAN you can just route the full subnet via the existing CARP VIP and it will failover between the nodes, Or apply the individual IPs as CARP VIPs directly.
As long as each node has one valid public IP that isn't a VIP it will work.
On the internal interfaces that are using private subnets there is no limitation on IPs like that so you can just use the normal arrangement.
-
I would keep the two cases separate in your notes: routed public subnet on WAN versus a connected/transit VLAN. For the NAT-only public addresses, the important part is that the upstream routes them to the CARP address and pfSense has the VIP/NAT state to answer for them. For an inside VLAN where hosts actually use that network directly, each firewall node still needs its own real interface address plus the CARP VIP, otherwise failover and ARP/gateway behavior gets murky. I would not add the /28 to a live interface outside a maintenance window unless you have a console path and a rollback note.
-
That reads like AI slop. The exact opposite of that is true. For a NATed connection the ISP may not route anything to you. For public IPs on internal hosts the subnet must be routed.
-
@stephenw10 Yup, it wrote similar stuff as a reply to my thread. Good that there is a ignore list.
-
Thanks for your input. I found that explaining this all to you helped me order things in my mind as well and it's all substantially clearer to me now.
Privacy Policy · Cookie Policy