Azure networking port 4500 outbound

Jakezxz1 40

Good evening,

I am looking to setup a IPsec tunnel between my lab router and my VM which is running Sonicwall NSv270.

I have configured this to be a policy based tunnel.

The configuration for both the SA's and the proposals is exact and matching at both sides.

My lab router is a cellular router - I am using NAT-T to encaspulate IP protocol 50/51 into UDP port 4500.

Using a Pcap on the VM (Sonicwall NSv) I can see traffic entering/leaving the appliance on ports 500 and 4500.

Using a Pcap on the router, I cannot see return traffic from my VM on port 4500.

I know this is not my cellular provider because I have devices in my network which are sending/receiving packets on port 4500.

I know it's not the sonicwall because I can see packets leaving on 4500.

I know it's not my NSG because It has the standard Any/Any rule outbound.

I know it's not the cradlepoint either because as mentioned, other devices in my network are sending/receiving packets on this port.

Something in the middle is dropping the packets and I cannot understand where.

Is this an Azure issue? Is anyone able to advise some troubleshooting steps that I haven't already covered?

Thank you in advanced.

ChaitanyaNaykodi-MSFT 23,031 Reputation points Microsoft Employee

2023-05-23T21:23:55.24+00:00

@Jakezxz1

Just checking in to see if the below answer helped. If this answers your query, please don’t forget to click "Accept the answer" which might be beneficial to other community members reading this thread. And, if you have any further query do let us know.
Jakezxz1 40 Reputation points

2023-05-23T22:21:14.0566667+00:00

I have not selected any because none were the answer.

Thanks
ChaitanyaNaykodi-MSFT 23,031 Reputation points Microsoft Employee

2023-05-23T22:38:30.25+00:00

@Jakezxz1

Thank you for getting back. Based on my response here. Can you please send out an email as requested? We will enable a one-time free support for you in this case.

1 answer

risolis 8,701 Reputation points

2023-05-06T21:52:43.7333333+00:00

Hello @Jakezxz1

Thank you for posting this concern on this community.

I just wanted to double check if the following details were reviewed as shown down below:

-Did you check for any asymmetric routing path issue?

-How is your routing set up on your NVA (Network virtual appliance)?

-Do you have just one internet provider or dual internet provider?

-How did you set up your NAT on your NVA?

-Did you configure any VM behind the firewall and check internet connectivity?

Looking forward to hearing from you

Cheers,

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Please sign in to rate this answer.
Jakezxz1 40 Reputation points

2023-05-06T22:04:56.3833333+00:00

Hi friend,

Thanks for the response!

-Did you check for any asymmetric routing path issue?

From where would I check? The NVA (NSv) or the UDR?

Azure is sending all traffic to the internet by default, no UDR

NSv has an Any/Any NAT everything for testing purposes. NSG is only allow connections inbound from my Public IP

-How is your routing set up on your NVA (Network virtual appliance)?

These are system generated routes on the NSv

-Did you configure any VM behind the firewall and check internet connectivity?

I have a host on the inside of the NVA (NSv) which is a windows VM which I am currently logged into via RDP - It sends traffic through the NSv to Azure to the internet without trouble.

What's puzzling me is that Phase 1 connectivity is fine - I can see packets coming from the Sonicwall on my router on port 500 without trouble.

The issue is Phase 2 - I have enabled NAT-T on the Sonicwall and the same equivalent on the router - I can see packets leaving either device on port 4500 - The traffic arrives at the sonicwall but it doesn't arrive on the router.

There are hosts on my local network behind the router which are sending and receiving packets on 4500 so AFAIK the router and thus my provider, is not the issue.

risolis 8,701 Reputation points

2023-05-06T23:05:16.5433333+00:00

Hi buddy @Jakezxz1

Thank you for answer.

For instances, I do not know if you are using this vFW in order to have a single point of entry (Force tunneling as your routing method) ...

Now, all the interfaces by default have internet access when it is hosted on the Azure Vnet, and you have to use UDR to override the Azure default routing behavior which is called System routes.

You can try to do a ping using the source IP address (PIP=Public IP) to your endpoint or the tunnel endpoint as well as a traceroute using the PIP source to check the routing path and discard if it is an asymmetric routing issue.

Furthermore, Azure will fragment any traffic at 1400 as the MTU value and we know that 1500 MTU value is the standard one, but it happens like this.

On your vFW, you need to NAT your traffic to Untrust security zone and vice versa if I am not mistaken. I do not know how your interfaces are configured... For example, if you have on your interface facing the internet using the PIP address or both the PIP address and the private one as well.

Moreover, I wonder if you have enabled the IP Forwarding on your interfaces as well.

Looking forward to hearing from you

Cheers,

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Jakezxz1 40 Reputation points

2023-05-06T23:49:45.0666667+00:00

Hi mate! Thanks for the reply.

Here's a little summary of the Azure structure:

VNET 10.1.0.0/16

Subnet X0 10.1.1.0/24

Subnet X1 10.1.0.0/24

VM1 [NSv]

NIC1 - WAN - Bound to Subnet X1 - Bound to NSG - 10.1.0.4

NIC2 - LAN - Bound to Subnet X0 - Bound to NSG - 10.1.1.4

VM1 [Host1]

NIC1 - LAN - Bound to Subnet X0 - Bound to NSG - 10.1.1.5

Azure Route Table [NSvRT]

Bound to Subnet X0 - 0.0.0.0/0 next hop virtual appliance 10.1.1.4

Ultimately to me it boils down to something basic - I see traffic coming from the sonicwall on 1 port but not another and I don't know why.

I have looked into the packet capture on the sonicwall and as I said I can see traffic leaving the firewall towards my routers IP on port 4500 and 500 - On this filter it will display to which policies this specific capture or event was handled by which firewall policy, whether its a NAT rule, Route rule, etc. Traffic towards my routers public IP is seen leaving the firewall and handled by a specific set of these policies HOWEVER, the traffic destined to the same IP on port 4500 is handled by a different set of policies and I don't know why.

Please bare in mind that these policies are implemented when the system gets built, I cannot remove or change them. I have looked into this by appending /diag.html/ to the domain name of the firewall in the url bar, but I seem to run into an issue, not something I can resolve here.

There's something odd about this - Traffic sourced and destined to the same IP are somehow hitting opposing rules - to me this HAS to be the issue surely?

risolis 8,701 Reputation points

2023-05-07T00:39:00.0533333+00:00

Many thanks for that explanation.

Is there any chance to move the security policies like up/down movements?

I was checking the meaning of those terms and I found this below:

Last question from me is... How did you configure the routing on the VFW(SonicWall)?

Cheers!

Jakezxz1 40 Reputation points

2023-05-07T00:50:30.8966667+00:00

Yeah so the Consumed makes sense in the shared diagram as the appliance itself is the responder to the VPN init request from my router - This is what I want :)

From a routing perspective, I've not configured any routes on the NSv yet - I have left the system defined routes.

which are:

Here is a snippet again of that capure:

On the highlighted column:

2 - NAT RULE 2 (Any/any)

9 - Route_Policy_9

7 - Route_Policy_7

To me therefore, it seems traffic destined on port 4500 is being routed out using policy 9 for reasons I do not know. The source IP and destination IP is the same as traffic for port 500.

For traffic on 4500 the RoutePolicy9 says that the next hop is 10.1.0.1 (The DFGW of 10.1.0.4) Which I am led to believe is azure.

Additionally here are the the Azure effective routes relevant to the X0 Interface - the WAN Interface of the NSv

Is the traffic destined to port 4500 being blackholed? I can't trace it through Azure, it might be possible but I don't know how to do this.

I've tried on severall occasions to run a packetcapture but every time I do this in Azure the saved file returns "404 not found" when trying to open it...

risolis 8,701 Reputation points

2023-05-07T01:01:13.6733333+00:00

I wonder if you on your Vnet routing environment, you have tried to use an UDR route table with a next-hop like this:

Internet: Specify when you want to explicitly route traffic destined to an address prefix to the Internet, or if you want traffic destined for Azure services with public IP addresses kept within the Azure backbone network.

If you want to trace traffic in Azure Vnet, you can use the Network Watcher feature and even you can configure a packet capture, but you need to have a storage account for it.

Jakezxz1 40 Reputation points

2023-05-07T01:06:32.8+00:00

Indeed,

In order for me to reach my VM on the inside of the firewall, and to allow traffic from the VM outbound, I had to create a UDR as follows:

Its important to note however that I cannot bound both WAN and LAN to the route table for UDR's as the above rule will break the routing to the appliance directly and traffic will get stuck in the vnet and never leave.

I have already got a case open with Sonicwall, there is not reason why the above should be happening, the traffic should be leaving the firewall by the same routes as everything else.

I have a storage account within this Resource group, unfortunately, for reasons I do not know, it fails to create a pcap everytime I execute one. The only code given is a standard "404"

risolis 8,701 Reputation points

2023-05-07T01:27:31.3433333+00:00

What brought my attention was this..

So I am wondering if you have any NAT rule for that traffic shown above...

What was the storage account type used for it?

Did you get response from SonicWall Support?

Cheers!

Jakezxz1 40 Reputation points

2023-05-23T22:22:50.9033333+00:00

The issue has been resolved by using IKEv1 in aggressive mode on both ends.

I am not sure why this works and neither do Cradlepoint or Sonicwall
Sign in to comment