VRRP and Alias address - some questions

[tjk]

Hey All!

Evaluating Untangle to replace pfsense and sophos and I have some vrrp/networking questions.

Testing Setup:

VRRP on External:
1.2.3.101 Untangle 1
1.2.3.102 Untangle 2
1.2.3.100 VRRP Alias

VRRP on Internal:
172.16.4.101 Untangle 1
172.16.4.102 Untangle 2
172.16.4.100 VRRP Alias

#1 - I want outbound nat to use the VRRP alias for all outbound traffic. I added a nat rule that says if source interface is Internal use custom address 1.2.3.100, I have the Internal gateway set to 172.16.4.100, if I do a traceroute out I see 1.2.3.101 or 1.2.3.102 depending if I failover or not, but if I do an curl ifconfig.me from the Internal machine I see the 1.2.3.100 VRRP Alias. Just curious why traceroute wouldn't show the 1.2.3.100 as the next hop vs the physical address of 1.2.3.101/102 depending if I failover or not?

#2 - Is it possible to use the VRRP Alias address for services? I configured wireguard, and by default it used 1.2.3.101 and .102 for the configs. I can change the config on the client to use the 1.2.3.100 VRRP Alias and it works fine, just curious why I can't tell the service to bind/listed/generate the config for the VRRP alias vs the physical unit interface address.

[sky-knight]

#1, default Untangle will use the primary IP on any given WAN interface for NAT. If you wish this to change you have to create a NAT policy to make that change. VRRP Aliases are just aliases otherwise, and behave the same way as a normal alias on any given interface.

The problem is if you do that, you're going to break any form of multi-WAN... that is unless you get VERY specific with your NAT policies.

Tracert might change... but usually doesn't. It's ID'ing interfaces, and those IPs are real so that's what comes back.

#2 Yes! Again it's just an alias, port forward based on it away! Now if you're talking about services on Untangle itself, it's a little unintuative but you need to forward from the alias to the main IP to get the VPN stuff to work.

[tjk]

#1, default Untangle will use the primary IP on any given WAN interface for NAT. If you wish this to change you have to create a NAT policy to make that change. VRRP Aliases are just aliases otherwise, and behave the same way as a normal alias on any given interface.

The problem is if you do that, you're going to break any form of multi-WAN... that is unless you get VERY specific with your NAT policies.

Tracert might change... but usually doesn't. It's ID'ing interfaces, and those IPs are real so that's what comes back.

#2 Yes! Again it's just an alias, port forward based on it away! Now if you're talking about services on Untangle itself, it's a little unintuative but you need to forward from the alias to the main IP to get the VPN stuff to work.

Thanks!

#1 - I have the nat rule already setup and working for most of the traffic, just trying to understand why traceroute doesn't show the vrrp address on outbound traces vs the physical interface address.

#2 - Not looking to port forward, I am talking about the services and the IP they bind to on the Untangle device. Example, when I setup 100 WG roaming profiles, unless I change each one manually to use the VRRP address to connect to, and if my primary Untangle fails, those folks can no longer connect since the profile has the primary Untangle interface in it. Replace this with any of the S2S vpn options, they default to the units IP address and not the VRRP address, so the moment you take the primary unit offline your S2S tunnels won't be established unless you change the endpoint address to use the VRRP alias.

[sky-knight]

You misunderstand...

Untangles services bind to primary IP addresses and direct aliases only. The VRRP aliases are special in this specific case. You can access Untangle's services via the VRRP shared address, but you need an appropriate port forward for traffic impacting that address to one of the real local addresses.

In short, you have to port forward Wireguard traffic off the VRRP IP to the primary interface IP to get what you want. That being said it's been awhile since I've attempted this... and for some reason my memory is itching on something here. If forwarding to the real WAN address doesn't work, try 192.0.2.200. That's a special address buried in Untangle where the real services live.

[tjk]

You misunderstand...

Untangles services bind to primary IP addresses and direct aliases only. The VRRP aliases are special in this specific case. You can access Untangle's services via the VRRP shared address, but you need an appropriate port forward for traffic impacting that address to one of the real local addresses.

In short, you have to port forward Wireguard traffic off the VRRP IP to the primary interface IP to get what you want. That being said it's been awhile since I've attempted this... and for some reason my memory is itching on something here. If forwarding to the real WAN address doesn't work, try 192.0.2.200. That's a special address buried in Untangle where the real services live.

So, Untangle is listening on primary interface on device 1, device 2, and the VRRP address, this just happens by default and there was/is nothing I need to do to port fwd to the VRRP address. The end client will connect to all 3 addresses without port forwarding that you mentioned.

My concern is, that when you generate a vpn profile, it uses the device 1 address and not the VRRP address. So, 100 users configured and working, device 1 goes down - the tunnels go down since it is using the physical IP address and not the VRRP address in the configs, no port fwd'ing will fix that since .101 is down and not responding.

What would be nice is a check box to tell the roaming profiles when you create them, what IP address to connect to, and let you put in the VRRP address, so the tunnels will work if any of the UT appliances fail.

[sky-knight]

OH...

Yes, that's in config -> network -> hostname.

You need to tell Untangle what IP to use manually there, or even better configure a public DNS name and use that instead! It'll update all the scripts so when you push client details it has the DNS name instead of an IP address, or at very least an IP address you're choosing.

[tjk]

Perfect, I'll give this a shot, thank you very much!