@johnpoz said in Virtual IP subnet cannot connect to internet:

@BlueSun said in Virtual IP subnet cannot connect to internet:

There's an Automatic NAT Rule, which I don't see

You said your outbound rules were auto and it was added, I was just adding that screen for completeness

Well, I set the outbound NAT rules to Automatic, but for some odd reason it didn't create the rules you have in your screenshot, so I had to add them manually.

d60a6317-0b25-4106-b407-971b002cdac0-image.png

@viragomann
Thanks !
Went with the port forward + outbound option, NAT is working finally.

@kiokoman Thank you Sir. You're correct.

I can see from here - https://www.calculator.net/ip-subnet-calculator.html?cclass=any&csubnet=29&cip=155.70.7.55&ctype=ipv4&printit=0&x=109&y=13 -
that the first usable is 155.70.7.49, which will be the ISP router (pfSense default gateway) set into the WAN interface. Can I rather use 155.70.7.48, the network address in a bid not to waste IP addresses?

Invariably, is this how to reuse IPs (network and broadcast addresses)?

Pardon me, it was indeed 155.70.7.56/29. And sorry, I'm trying to learn the IP addresses by heart. In this case, can I use 155.70.7.56 in the WAN as against 155.70.7.57, the first usable IP? I'm trying to maximize the IP addresses.

CARP/VRRP/etc. are using not only virtual IPs but also virtual MACs to make failover a smooth experience without clients or network equipment having to learn a new MAC address of a failover server like with only IP based configurations (early linux HA cluster for example).

The VHID setting is influencing which MAC is handed out for that CARP style VIP. All of them are (IMHO) using the failover MAC space of

00:00:5E:00:01:XX

so with changing the VHID you are also configuring the last "XX" segment of said MAC address. That's why it has to be unique on that network segment (L2) and you also have to watch out for other cluster/HA-grade setups, that are using VRRP or HSRP style VIP/MAC combinations. But if your pfSense cluster is the only cluster in that network segment, VHID 1 is commonly fine on all interfaces. We're using VHID 4 and 6 (for IP4 / IP6 VIPs on the same VLAN) over multiple VLANs just fine :)

Closing this. Thanks for pointing me into the direction of testing the Ping on the CARP VIP. That ended up being the issue. Turns out somehow ISP took back one of our 3 IPs, we got them to put it back on our account and now we are back to normal. Can ping off that CARP VIP as well as port forwarding works now using the CARP VIP as Destination Address.

Thanks again @Derelict

@jpod2019 said in Can you run DHCP, DNS and NTP on different VIPs?:

(I’m assuming everything will be done through the LAN interface and VIPs)

I'm assuming you mean WAN there. 😉
You can have a single interface and it will be WAN and that's fine. The anti-lockout rule will be applied there instead of LAN in that case.

If you add a VIP on the WAN all services will listen on it by default so you can add VIPs for NTP and DNS and it will work. DHCP will only run on the interface address though.
By default DHCP wil hand out it's own IP for NTP and DNS so you would need to make sure you set those values in the DHCP setup. Though it would still work fine for anything using DHCP since those services would also be listening on the interface IP.

Steve

i've solved the problem. its very similar to bridge behavior i encountered in another installation. I only have vlans defined for my LAGG. once i created another interface that would be untagged on the LAGG, it picked up my native vlan as expected. all of the VIPs for the tagged interfaces started working.

so just for my own curiosity i deleted the native interface i crated and rebooted. everything still works. all in all i must have just jiggled the handle