MULTIWAN Support for PFSENSE

Hi! How is everything going?

I just want to follow-up as to when MULTIWAN on PFSENSE can be supported by adam:ONE?

Bumping up! Any possibility of this happening soon?

Hey @edanpedragosa, we supports multi-WAN when configured on a system level but not on a firewall rule level.

“On a system level” meaning? Can you please explain more? Does this mean it can support load-balancing on multi-wan setup now?

Sure, whatever you can set under System / Routing / Default gateway (for default IPv4 and default IPv6) is what will be used for traffic allowed by DTTS.

Oh, so that means it still can’t do multi-wan load balancing then. I hope you can implement multi-wan with load balancing support at least on PFSense. This will help us eliminate additional server to manage.

@edanpedragosa just to give you a quick update, in speaking to our dev team it appears due to how DTTS is implemented in the firewall it will be too much overhead on the system to implement support for this. But if we ever re-design it, this will certainly be considered.

Hi! Is this working now on version 4?

Yes it is. Because in v4 the DTTS pass rule is a regular pfSense firewall rule, you’re able to assign your Multi WAN gateway group to it.

Once v4 is released to stable (currently it’s only available in the test/rapid release channel) then we’ll update the KB article on this topic as well.

Thank you! That’s good to know! I will try out the rapid release of V4. Thanks again!

Hi!

So I’ve installed V4, everything seems to work fine except that it cannot resolve local DNS queries against our AD DNS as before. Is the Rainbow List/Forwarding to AD still applicable with V4? it does not seem to query the AD anymore. I need to manually add an authoritative list for our internal domain and it works for those domains on our list but not for AD resolution.

MULTIWAN seems working though.

One more thing that’s off is when I go to a command prompt and type nslookup I get this, sometimes it’s a different random website and it only happens when Adam:One V4 is active.:

C:\Users\edan>nslookup
Default Server:  jeehathu.com
Address:  172.27.77.7

What is jeehathu.com and why is it showing like that when V4 is enabled?

Also, there are some computers that cannot connect to the internet. When I check the logs it says:
Rule Applied = System - System | no upstream available

I tried to changed the policy to no effect. Note: This only happens to Windows Servers.

@edanpedragosa it seems you have multiple issues, some of them are probably best solved with a support request to our team, but:

  1. the nslookup resolving to jeehathu.com is something you’ll have to investigate because whatever your dns server is set to on the client, it is reverse-resolved and then displays the PTR record (reverse DNS) for the IP address of your client OS resolver settings

  2. When no upstream servers are available, it means just that – if you’re on a whitelist/allowlist policy, it’ll use your gateway’s WAN-interface defined DNS servers, and if you’re on a blacklist/blocklist policy, it’ll use what you’ve selected

  3. AD domains still resolve via forwarding rules as before, make sure your rule is enabled on the respective policies

If you’re submitting a ticket, set log level to 6, restart the service, re-trigger the problem, and then use adamone-issue as a way to submit relevant diagnostic details to our team.

Thank you for your reply David!

1. the nslookup resolving to [jeehathu.com](http://jeehathu.com) is something you’ll have to investigate because whatever your dns server is set to on the client, it is reverse-resolved and then displays the PTR record (reverse DNS) for the IP address of your client OS resolver settings

There’s no way that will be in our AD DNS. I double-checked it and there is no PTR record for that domain. And to note, this only happen if I enable the Adam:One V4 service.

2. When no upstream servers are available, it means just that – if you’re on a whitelist/allowlist policy, it’ll use your gateway’s WAN-interface defined DNS servers, and if you’re on a blacklist/blocklist policy, it’ll use what you’ve selected

I’m only using blocklist policies and as I’ve said it only happens so far to clients running Windows servers on our ESXI hosts. I will try it our more this Sunday to see the extent of which can and cannot connect.

3. AD domains still resolve via forwarding rules as before, make sure your rule is enabled on the respective policies

I verified that it is activated in all the policies I have. That is why I’m wondering if something is off in V4 as it worked fine in V 3.4.23_1 .

If you’re submitting a ticket, set log level to 6, restart the service, re-trigger the problem, and then use adamone-issue as a way to submit relevant diagnostic details to our team.

It has been a while since I sent a ticket. Can I still use the @dnsthingy… e-mail?

Thanks again!

Okay, so I’ve run it side by side and it verifies that on V3, it is resolving fine. Here’s the result for V3:
host: filter.aims.ac.th

C:\Users\edan>nslookup
Default Server:  filter.aims.ac.th
Address:  172.27.7.7

> sis
Server:  filter.aims.ac.th
Address:  172.27.7.7

Name:    sis.aims.ac.th
Address:  172.27.7.71

> lms
Server:  filter.aims.ac.th
Address:  172.27.7.7

Name:    lms.aims.ac.th
Address:  172.27.7.71

> dev
Server:  filter.aims.ac.th
Address:  172.27.7.7

Name:    dev.aims.ac.th
Address:  172.27.7.71

Here’s the result for V4:
host: gateway.aims.ac.th

Default Server:  gateway.aims.ac.th
Address:  172.27.77.7

> sis
Server:  gateway.aims.ac.th
Address:  172.27.77.7

Non-authoritative answer:
Name:    sis.aims.ac.th
Address:  110.164.136.124

> lms
Server:  gateway.aims.ac.th
Address:  172.27.77.7

Non-authoritative answer:
Name:    lms.aims.ac.th
Address:  110.164.136.124

> dev
Server:  gateway.aims.ac.th
Address:  172.27.77.7

Non-authoritative answer:
Name:    dev.aims.ac.th
Address:  110.164.136.124

Please note that I’ve verified that the forwarding list to our AD DNS is turned on in all policies.

Also, I’ve tested psiphon, it seems blocked but if you just let it run, it will eventually be able to connect.

It can now bypass in both V3 and V4 installs.

Psiphon windows client version: 168

It seems that psiphon has upgraded their tech again?

Consider this case resolved. Thanks David and Bill for your support!