Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify multiple listener IP addresses (for CARP VIPs) #101

Closed
Fail-Safe opened this issue Mar 14, 2020 · 1 comment
Closed

Specify multiple listener IP addresses (for CARP VIPs) #101

Fail-Safe opened this issue Mar 14, 2020 · 1 comment

Comments

@Fail-Safe
Copy link
Contributor

Fail-Safe commented Mar 14, 2020

Here's my scenario, nextdns client has been happily running on a single pfSense node. Just moved to a two-node pfSense HA setup with a CARP VIP for each VLAN (4 currently) on my LAN. Both pfSense nodes are running the nextdns client with listen :53 in each config file.

The nextdns clients on both nodes resolve just fine. However, the issue is when performing a dig command from *nix/BSD based hosts. In this case, dig reports a ;; reply from unexpected source: 192.168.2.1#53, expected 192.168.2.5#53, where 192.168.2.1 is the MASTER pfSense node and 192.168.2.5 is the CARP VIP on that particular VLAN.

Based on some research within pfSense forums and such, it sounds like the proper way to address this issue is to have the nextdns client bind specifically to the CARP VIPs for each VLAN. Obviously this would require multiple listen IPs in the nextdns config which doesn't appear to be supported currently.

Does having the nextdns client bind directly to the CARP VIPs seem like the logical resolution? If so, any chance multiple listener IPs can/will be supported by nextdns?

Thanks for the continued great work on the NextDNS service and client--it's awesome!

@Fail-Safe Fail-Safe changed the title Specify multiple listener IP addresses Specify multiple listener IP addresses (for CARP VIPs) Mar 14, 2020
@rs
Copy link
Contributor

rs commented Mar 14, 2020

The solution is to set the source addr to the dest addr of the incoming packet. It’s easy to fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants