AnsweredAssumed Answered

SMB 1400 Mesh VPN and Identity Awareness with ADQuery

Question asked by Dylan Merida on Feb 23, 2018
Latest reply on Mar 26, 2018 by Maarten Sjouw

Hi guys,


I've got a a mesh / site-to-site VPN question with SMB 1400s and Identity Awareness. It may or may not apply to GAIA proper as well. The environment is working currently like this:


1) 9 x SMB 1400s in a mesh VPN community with no NAT inside the community.

2) SMS is R80.10 on a VMWare VM and the SMB 1400s are on the latest R77.20 firmware.

3) VPN Community is set to default encryption for phase 1 and 2 with certificate based authentication.

4) Accept all encrypted traffic is not checked.

5) Permanent tunnels are on with RIM, but I've tried with RIM on and off.

6) The management server is behind one of the gateways at a central building.

7) The gateways' main IPs and objects are configured as their public addresses aside from the gateway local to the mgmt server. The local gateway in layer 2 with the mgmt server has its object configured as the local layer 2 private IP.

8) The AD servers used in AD Query are at three main building sites that each have an SMB 1400 gateway.

9) Firewall rules are set up to allow all traffic between the internal private IP subnets for each gateway in the VPN community.

10) Manual NAT is set so that private IP to private IP traffic is always original and never translated.

11) All VPN traffic between clients and the VPN subnets is working with no issues. The AD servers are able to communicate with each other directly with no problems.

12) Identity sharing is enabled between the gateways and only the sites with AD servers are sharing.


The issue we're having is that AD query is only working between the local gateway and local AD server at the three main buildings. I'm getting monitor errors every 30 seconds or so one or more AD servers are unreachable. When I investigated with fw monitor and tcpdump, it appears that each gateway is using its public IP address as the source for AD query traffic to tcp/389 and also for log traffic over the VPN. When attempting to ping or telnet directly from the CLI to one of the AD servers or any other host over the VPN, the same is true about the source address.


What we're seeing is that the source address for gateway traffic to a VPN IP is always its public address. This appears to follow convention with the route table. My understanding is that the internal address should present itself over the VPN. Short of a VTI and real routing, is there any way to control this source address for AD query, logs, etc? Should I bite the bullet and try to allow these gateway public addresses over the tunnel and to each private subnet?


Thank you and kind regards!