We have a situation where remote users are logging into a firewall and the firewall attempts to to authenticate to an Active Directory server that’s located in the cloud, but the traffic between the firewall’s tunnel interface and the AD server hosted in Azure does not pass. The tunnel interface has a 169.254.0.1 IP per the configuration file for the connection. I’ve added inbound and outbound rules to the Network Security Group to allow traffic to/from that IP. However traffic does not pass. We are using AD servers instead of Azure AD. This allows us to continue to use Group Policies.
Is there some routing somewhere in Azure that can be modified to allow this traffic? Capturing traffic at the firewall, I can see traffic exiting the firewall on the tunnel interface to Azure, but nothing in reply.
***EDIT***
I found the answer, see the comments.
So I was running a Sophos xg PAYG in azure at my last job and it’s been some time since I set that up so bear with me. If I recall on the Sophos appliance you pretty much needed everything external to be routed to interface A, and everything internal routed to interface B.
Due to Azure networking the Sophos couldn’t intelligently automatically handle the routes for the internal subnets, so I think I had to explicitly route all of the internal subnet traffic to the B interface. As far as using tunnel interfaces, the azure based internal subnets will need routes pointing to those.
I recall that using the Azure appliance zones and vlans didn’t really come into play, it was all just making sure routes and address based rules were correct.
I wish I could give more specifics but I just don’t work with azure/Sophos these days.
Adding Solutions here so one doesn’t have to dig through comments.
***SOLUTION #1***
When I worked with Sophos support initially, there was no option to source the traffic from the LAN interface like some routers can do.
I argued with them about this and the case was escalated last night. Yes, we can NAT system sourced traffic.
https://community.sophos.com/sophos-xg-firewall/f/discussions/129656/show-system-generated-traffic-snat-rules
Translating the generated traffic via NAT
Go to the command line of your firewall.
Select Option 4. Device Console.
Run the following command:
Syntax:
set advanced-firewall sys-traffic-nat add destination <destination IP address> snatip <SNAT IP address>
Example:
set advanced-firewall sys-traffic-nat add destination 172.16.16.5 snatip 192.168.2.1
I still have a case open with Microsoft to see if there is a way in Azure to allow this.
***SOLUTION #2***
it took weeks but I finally spoke with an engineer at Microsoft. The solution is simple.
Microsoft has a configuration file for the VPN tunnel that one downloads after selecting their firewall/router platform that represents their Local Network Gateway. In this file, when using the generic configuration, the IP address they recommend for the Tunnel interface built in the firewall would be 169.254.0.1/32.
As others have mentioned, this is an unroutable LINK-LOCAL (APIPA) address. So how to change it?
Simple, The IP address does NOT matter. So change it to whatever RFC-1918 address you desire. After I disabled the NAT rule in the firewall, I set the xfrm tunnel interface IP to 192.168.219.1/32. I then, in Azure, added this to the Local Network Gateway and to the inbound rules in the Network Security Group. Badda-Bing, all is right in firewall land. Now the firewall can connect to the AD server to authenticate users connecting to the Remote Access VPN.
You will need a route in azure to tell it that the remote user vlan needs to be sent down the tunnel.
By any chance are you using an asa firewall?
Been a long time but I pretty much just set up a S2S and it works fine. The aPIPA addresses are not routed. They are on the tunnel interface.
Tutorial - Create S2S VPN connection between on-premises network and Azure virtual network: Azure portal - Azure VPN Gateway | Microsoft Learn ← this for adding networks?
Also you’ll need to point a route to 10.0.0.4/32 with a next-hop of the Azure gateway; I’m assuming the address used is 169.254.0.1/31 on your side, and 169.254.0.0/31 on their side? If so, 169.254.0.0 will be your next-hop.
Thanks for your response. In asking around, it sounds like the issue is due to using Link-Local addresses that cannot be routed per the RFC. Microsoft forces the use of such addresses and there is no way to change the address they assign for the Virtual Tunnel Interface. If I deploy a Sophos Firewall appliance in Azure, then I’d have control over the tunnel interface and addressing and could use RFC 6598 addressing.
It’s not a VLAN, it’s a VPN tunnel interface IP.
The Firewall is the source of the authentication traffic, trying to reach the AD server from it’s tunnel interface IP which happens to be an APIPA address as this is what Azure Connections use. I cannot modify this on the Azure side that I can see.
Address space is 169.254.0.2/255.255.255.252. gives 2 addresses usable, .1 and .2. 169.254.0.0 would be a gateway IP.
Route is already in place for anything 10.0.0.0 and this works, per packet capture, traffic routes from the network to 10.0.0.4 when I ping or tracert from the firewall. The Sophos firewall is sending user authentication traffic for remote access VPN from src ip 169.254.0.1 which per RFC is not routeable.
I didn’t use any of Azure’s tunnels, I just routed the wan and lan to the Sophos and did all of the tunnels in there.
It sounds like it was a VTI (route based) VPN and so you would need to route traffic over it. If it is a policy based VPN then you need to make sure the remote access addresses are in the “interesting traffic” list.
Ahh I got you now, sorry about that!
Does the XGS give you an option for specifying a source IP address for requests to come from? Maybe it’s something hidden in the CLI somewhere?
Or perhaps you could run an agent on the 10.x network?
Did you save any money using a Sophos Firewall Appliance in Azure vs using a VNet Gateway? We are considering that for several clients.
Yes, it’s VTI. Microsoft forces the use of link-local addresses and they cannot be routed. Thus the traffic sourced from the physical firewall that sources from the tunnel interface cannot cross the boundary to the LAN subnet.
When II worked with Sophos support initially, there was no option to source the traffic from the LAN interface like some routers can do.
I argued with them about this and the case was escalated last night. Yes, we can NAT system sourced traffic
https://community.sophos.com/sophos-xg-firewall/f/discussions/129656/show-system-generated-traffic-snat-rules
Translating the generated traffic via NAT
Go to the command line of your firewall.
Select Option 4. Device Console.
Run the following command:
Syntax:
set advanced-firewall sys-traffic-nat add destination <destination IP address> snatip <SNAT IP address>
Example:
set advanced-firewall sys-traffic-nat add destination 172.16.16.5 snatip 192.168.2.1
All of our other sites were using xg appliances so it made for ease of integration.
These addresses are not routed. They are on network.
Traffic src ip 169.254.0.1 dst ip 10.100.30.4 or whatever has to pass through some routing process. They are not on the same net.