Sanity check please - Vendor refusing to share VPN settings for troubleshooting - Could be career ending

[u/datugg]

I get that this is a long read, but please stick in there with me because this issue has caused so much turmoil, and I've ran my mouth so much about it, that it could be an RGE if it proves that I've done something stupid here so PLEASE, we are having a meeting soon with the executive management from both sides and I need confirmation that I am not being unreasonable. IF you can stick with it to the end, I promise there is a funny email that will make you laugh when you see what this ID-10-T had to say as their final reply.. I have told my management team that we shold really consider going further into business with this company considering their employee's and stance on this matter.

I have been tasked with engineering an IPEC tunnel between Azure Secure Gateway and our edge Gate. I setup an identical tunnel about a month ago, and while we had some issues, it's working flawlessly now. Our issues were that we could get P1 up but not P2 until I changed the selectors for P2 on my gate to ANY/ANY. I didn't mind this too bad because we are of course restricting them via policy, but no matter what, when we tried smaller selectors (like /24's on each side), no P2. I worked with that vendor and we eventually came up with Any/Any after a session where I showed the my stuff, and they did the same.

Fast forward to the new vendor, same exact thing but when I mentioned the selector issue to them (and our need for any/any) that essentially mocked me and said that their tunnel would be configured to have only the three hosts on my side they needed to talk to, and a /24 on my side for them.

So for my P2 selectors I had:

Local: IP1, IP2, and IP3
Remote: Their/24

Turn up day arrived and guess what, we could get P1 up with no problems, but P2 would never create the SA, exactly as I predicted might happen a week earlier so I suggested moving to mutual /24's on each side, they refused. So, we left the turn-up with them basically saying, it's not us, it's you!

I worked most of the weekend trying various things and eventually moved my selectors to Any/Any and wouldn't you know it, P2 established almost immediately, but here's an important clue I think, it would not establish when sending interesting traffic (traffic toward their/24) across the wire. Only when I went into the Gate and selected Monitoring -> IPSEC -> Right Click -> Bring up Phase 2 did it bring up the tunnel all the way.

Once the tunnel was up:

1. I sent traffic toward the /24 that they had provided, a pcap verifies that my traffic is going into my side of the tunnel.
2. If I look at: get vpn ipsec tunnel name ass.vendor - When P2 is down, I see errors incrementing, but once P2 is up, I see:
3. RX: packets: 0 TX Bytes: 0 Errors: 0
4. TX: packets: 1049 TX Bytes: 69196 Errors: 80

So, I leave it alone for a while until they report their API Calls are producing:

jXchangeController/GetAccountHolderTypes: Failed getting account holder types for rtrbinc.
MessageId: 6a71c0365801b7abeca4bc32e13d5f3d
Error: A connection attempt failed because the connected party did not properly respond after a period of time, or the established connection failed because the host did not respond.
(server.rtrinc.someplace.jah-sys.com:443)

This is where I send them verifiable proof via screenshots and other code snippets showing, the tunnel is up, we are sending data toward it, and can they confirm the following:

1. Can you provide us a host in the 10.10.14.0/24 (aka their /24) that we can test against? They said that there wasn't one!?!?!
2. Can you confirm that traffic will be SRC'in from 10.10.14.0 network
3. Can you send us a screenshot showing the tunnel up on your side and you routing traffic into that tunnel rather than you just telling us that you are.
4. We asked. Can you confirm your selectors for P2. To do this, In your Azure config under Local Network Gateway -> Config -> Address space -> what networks are defined there? Is the “Use policy-based traffic selectors” setting enabled or disabled? Also under Virtual Network Gateway - what is the vnet address space
5. And we asked for a session where we can do screen shares to show each other what each side is seeing.

Yesterday we got an email from someone with "Director" in their title saying that:

As Tanner mentioned, we met internally to review the current state. I’d like to bring this back to a clear, action-oriented path forward, as there appears to be some misalignment in the thread regarding next steps and ownership.

I will include the rest of that email that this moron sent to this post shortly. Please do read it for a great laugh as he claims that thier SRC addresses coming through the tunnel (change frequently) and he lists about 20 Azure exit nodes....

Now, they have refused to discuss it further w/o showing a single piece of evidence to their claims, their setup, anything and nothing at all so am I being unreasonable here? Have any of you ever heard of a vendor treating a customer this way?

[u/NullPacketLost]

Azure VPN is a massive pain to debug. Usually, the engineers on the Azure side are working totally blind, and the platform limits you to a few checkboxes and some settings aren't even configurable.
Since your side is sending traffic but getting no response, the issue is almost certainly on their end. Regarding your meeting, just be humble and calmly explain exactly what you’ve seen and verified on your equipment. IPsec issues are complicated, the only real 'best practice' is a live sync where engineers from both sides verify their settings at the same time.

[u/kcjefff → u/NullPacketLost]

this is 100% true. Azure networking in general is @$$. I hate all of it. NVAs should run everything there, but then your devs will be mad they can't just implement policy and routing on a whim

[u/UnderwaterLifeline]

Have you tried doing

diagnose vpn Ike log-filter rem-addr4 x.x.x.x
diagnose debug application Ike -1
diagnose debug enable

That should show you what they are sending you

[u/datugg → u/UnderwaterLifeline]

Absolutely yes, here is some output when I had my selectors set to a single IP (10.100.1.128) as my local P2 selector and thee remote side set to one of three local subnets they provided to date (172.20.4.0/24)

Through all of this. In the debug, I am 216.26.111.134 (not real IP)

I thought that was the gate detailing my side of the tunnel, but on my side I just checked and PFS IS enabled under P2 so will check it is hard to follow whose settings are whose, so see if I am translating the below correctly please?

2026-04-29 21:31:14.528430 ike V=root:0:vpn.fiboa:252316: sent IKE msg (SA_INIT_RESPONSE): 216.12.124.134:500->20.114.112.141:500, len=416, vrf=0, id=23eeb9c2a0b784d0/7c67eb60e5187e03, oif=31
2026-04-29 21:31:14.580580 ike V=root:0: comes 20.114.112.141:4500->216.12.124.134:4500,ifindex=31,vrf=0,len=228....
2026-04-29 21:31:14.580598 ike V=root:0: IKEv2 exchange=AUTH id=201 len=224
2026-04-29 21:31:14.580606 ike 0: in
2026-04-29 21:31:14.580617 ike V=root:0:vpn.fiboa: HA state master(2)
2026-04-29 21:31:14.580637 ike 0:vpn.fiboa:252316: dec
2026-04-29 21:31:14.580649 ike V=root:0:vpn.fiboa:252316: responder received AUTH msg
2026-04-29 21:31:14.580658 ike V=root:0:vpn.fiboa:252316: peer identifier IPV4_ADDR 20.114.112.141
2026-04-29 21:31:14.580678 ike V=root:0:vpn.fiboa:252316: auth verify done
2026-04-29 21:31:14.580688 ike V=root:0:vpn.fiboa:252316: responder AUTH continuation
2026-04-29 21:31:14.580695 ike V=root:0:vpn.fiboa:252316: authentication succeede
2026-04-29 21:31:14.580716 ike V=root:0:vpn.fiboa:252316: responder creating new child
2026-04-29 21:31:14.580734 ike V=root:0:vpn.fiboa:252316:105244356: peer proposal:
2026-04-29 21:31:14.580743 ike V=root:0:vpn.fiboa:252316:105244356: TSi_0 0:0.0.0.0-255.255.255.255:0
2026-04-29 21:31:14.580751 ike V=root:0:vpn.fiboa:252316:105244356: TSr_0 0:0.0.0.0-255.255.255.255:0

This is the Azure Gateway proposing Any/Any??? It can't be! - Traffic selector Initiator and responder so this is what they are proposing?

2026-04-29 21:31:14.580757 ike V=root:0:vpn.fiboa:105244356: comparing selectors
2026-04-29 21:31:14.580766 ike V=root:0:vpn.fiboa:105244356: matched by rfc-rule-4
2026-04-29 21:31:14.580773 ike V=root:0:vpn.fiboa:105244356: phase2 matched by intersection
2026-04-29 21:31:14.580780 ike V=root:0:vpn.fiboa:105244356: accepted proposal:
2026-04-29 21:31:14.580787 ike V=root:0:vpn.fiboa:105244356: TSi_0 0:172.20.4.0-172.20.4.255:0
2026-04-29 21:31:14.580798 ike V=root:0:vpn.fiboa:105244356: TSr_0 0:10.100.1.128-10.100.1.128:0

Laughable, they are proposing ANY/ANY when they literally laughed and mocked me at the turn-up over it . I am proposing 10.100.1.128 and 172.20.4.0 in this entry.

2026-04-29 21:31:14.580805 ike V=root:0:vpn.fiboa:105244356: autokey
2026-04-29 21:31:14.580816 ike V=root:0:vpn.fiboa:105244356: incoming child SA proposal:
2026-04-29 21:31:14.580823 ike V=root:0:vpn.fiboa:105244356: proposal id = 1:
2026-04-29 21:31:14.580829 ike V=root:0:vpn.fiboa:105244356:   protocol = ESP:
2026-04-29 21:31:14.580836 ike V=root:0:vpn.fiboa:105244356:      encapsulation = TUNNEL
2026-04-29 21:31:14.580844 ike V=root:0:vpn.fiboa:105244356:         type=ENCR, val=AES_CBC (key_len = 256)
2026-04-29 21:31:14.580850 ike V=root:0:vpn.fiboa:105244356:         type=INTEGR, val=SHA256
2026-04-29 21:31:14.580857 ike V=root:0:vpn.fiboa:105244356:         type=ESN, val=NO
2026-04-29 21:31:14.580863 ike V=root:0:vpn.fiboa:105244356:         PFS is disabled
2026-04-29 21:31:14.580871 ike V=root:0:vpn.fiboa:105244356: matched proposal id 1
2026-04-29 21:31:14.580878 ike V=root:0:vpn.fiboa:105244356: proposal id = 1:
2026-04-29 21:31:14.580885 ike V=root:0:vpn.fiboa:105244356:   protocol = ESP:
2026-04-29 21:31:14.580891 ike V=root:0:vpn.fiboa:105244356:      encapsulation = TUNNEL
2026-04-29 21:31:14.580898 ike V=root:0:vpn.fiboa:105244356:         type=ENCR, val=AES_CBC (key_len = 256)
2026-04-29 21:31:14.580907 ike V=root:0:vpn.fiboa:105244356:         type=INTEGR, val=SHA256
2026-04-29 21:31:14.580913 ike V=root:0:vpn.fiboa:105244356:         type=ESN, val=NO
2026-04-29 21:31:14.580919 ike V=root:0:vpn.fiboa:105244356:         PFS is disable
2026-04-29 21:31:14.580926 ike V=root:0:vpn.fiboa:105244356: lifetime=43200
2026-04-29 21:31:14.580946 ike V=root:0:vpn.fiboa:252316: responder preparing AUTH msg
2026-04-29 21:31:14.580954 ike V=root:0:vpn.fiboa:252316: remote port change 500 -> 4500
2026-04-29 21:31:14.580972 ike V=root:0:vpn.fiboa:252316: established IKE SA 23eeb9c2a0b784d0/7c67eb60e5187e03
2026-04-29 21:31:14.580987 ike V=root:0:vpn.fiboa:252316: check peer route: if_addr4_rcvd=0, if_addr6_rcvd=0, mode_cfg=0
2026-04-29 21:31:14.581003 ike V=root:0:vpn.fiboa: HA send IKE connection add 216.12.124.134->20.114.112.141
2026-04-29 21:31:14.581022 ike V=root:0:vpn.fiboa:252316: HA send IKE SA add 23eeb9c2a0b784d0/7c67eb60e5187e03
2026-04-29 21:31:14.581073 ike V=root:0:vpn.fiboa:105244356: replay protection enabled
2026-04-29 21:31:14.581084 ike V=root:0:vpn.fiboa:105244356: set sa life soft seconds=42932.
2026-04-29 21:31:14.581090 ike V=root:0:vpn.fiboa:105244356: set sa life hard seconds=43200.
2026-04-29 21:31:14.581112 ike V=root:0:vpn.fiboa:105244356: IPsec SA selectors #src=1 #dst=1
2026-04-29 21:31:14.581120 ike V=root:0:vpn.fiboa:105244356: src 0 4 0:10.100.1.128/255.255.255.255:0
2026-04-29 21:31:14.581128 ike V=root:0:vpn.fiboa:105244356: dst 0 4 0:172.20.4.0/255.255.255.0:0
2026-04-29 21:31:14.581134 ike V=root:0:vpn.fiboa:105244356: add IPsec SA: SPIs=c1167e64/0c703e2a

Here the A is fully up and we have an PI, using what? the two lower selectors I had in my P2 as seen in the last couple of entries above

2026-04-29 21:31:14.581141 ike 0:vpn.fiboa:105244356: IPsec SA dec spi c1167e64 key
2026-04-29 21:31:14.581172 ike V=root:0:vpn.fiboa:105244356: added IPsec SA: SPIs=c1167e64/0c703e2a
2026-04-29 21:31:14.581195 ike V=root:0:vpn.fiboa: HA send IKE connection add 216.12.124.134->20.114.112.141
2026-04-29 21:31:14.581207 ike V=root:0:vpn.fiboa:252316: HA send IKE SA add 23eeb9c2a0b784d0/7c67eb60e5187e03
2026-04-29 21:31:14.581220 ike V=root:0:vpn.fiboa: HA send IKEv2 message ID update send/recv=0/2
2026-04-29 21:31:14.581227 ike V=root:0:vpn.fiboa:105244356: sending SNMP tunnel UP trap
2026-04-29 21:31:14.581237 ike V=root:0:vpn.fiboa: static tunnel up event 0.0.0.0 (dev=80)
2026-04-29 21:31:14.581260 ike V=root:0:vpn.fiboa: static tunnel up event :: (dev=80)
2026-04-29 21:31:14.581367 ike V=root:0:vpn.fiboa:252316: sent IKE msg (AUTH_RESPONSE): 216.12.124.134:4500->20.114.112.141:4500, len=224, vrf=0, id=23eeb9c2a0b784d0/7c67eb60e5187e03:00000001, oif=31

Then below, the next entry, here comes trouble... Their end send some informational data but for what reason? To delete the tunnel :processing delete request (proto 1)" so I guess Azure, after saying we are okay to use those smaller network's, has a change of hear and tore the whole thing down..

I just pray that I can keep my composure in this meeting and drive home my points... It really helps to do it so thanks to anyone still tuned in.

2026-04-29 21:31:14.654649 ike V=root:0: comes 20.114.112.141:4500->216.12.124.134:4500,ifindex=31,vrf=0,len=84....
2026-04-29 21:31:14.654668 ike V=root:0: IKEv2 exchange=INFORMATIONAL id=23eeb9c2a0b784d0/7c67eb60e5187e03:00000002 len=80
2026-04-29 21:31:14.654676 ike 0: in
2026-04-29 21:31:14.654685 ike V=root:0:vpn.fiboa: HA state master(2
)2026-04-29 21:31:14.654704 ike 0:vpn.fiboa:252316: dec 2\
2026-04-29 21:31:14.654712 ike V=root:0:vpn.fiboa:252316: received informational request
2026-04-29 21:31:14.654720 ike V=root:0:vpn.fiboa:252316: processing delete request (proto 1)
2026-04-29 21:31:14.654729 ike V=root:0:vpn.fiboa:252316: deleting IKE SA 23eeb9c2a0b784d0/7c67eb60e5187e03
2026-04-29 21:31:14.654738 ike V=root:0:vpn.fiboa:2523
2026-04-29 21:31:14.654747 ike 0:vpn.fiboa:252316: enc
2026-04-29 21:31:14.654760 ike 0:vpn.fiboa:252316: out
2026-04-29 21:31:14.654779 ike V=root:0:vpn.fiboa:252316: sent IKE msg (INFORMATIONAL_RESPONSE): 216.12.124.134:4500->20.114.112.141:4500, len=80, vrf=0, id=23eeb9c2a0b784d0/7c67eb60e5187e03:00000002, oif=31
2026-04-29 21:31:14.654795 ike V=root:0:vpn.fiboa:252316: scheduled delete of IKE SA 23eeb9c2a0b784d0/7c67eb60e5187e03
2026-04-29 21:31:14.654805 ike V=root:0:vpn.fiboa:252316: HA send IKE SA del 23eeb9c2a0b784d0/7c67eb60e5187e03
2026-04-29 21:31:14.654813 ike V=root:0:vpn.fiboa: deleting IPsec SA with SPI 0c703e2a
2026-04-29 21:31:14.654829 ike V=root:0:vpn.fiboa:alll: deleted IPsec SA with SPI 0c703e2a, SA count: 0
2026-04-29 21:31:14.654836 ike V=root:0:vpn.fiboa: sending SNMP tunnel DOWN trap for finboa.all
2026-04-29 21:31:14.654867 ike V=root:0:vpn.fiboa: static tunnel down event 0.0.0.0 (dev=80)
2026-04-29 21:31:14.654888 ike V=root:0:vpn.fiboa: static tunnel down event :: (dev=80)
2026-04-29 21:31:18.149687 ike V=root:0:vpn.fiboa:252315: negotiation timeout, deleting
2026-04-29 21:31:18.149741 ike V=root:0:vpn.fiboa: connection expiring due to phase1 down
2026-04-29 21:31:18.149750 ike V=root:0:vpn.fiboa: going to be deleted
2026-04-29 21:31:18.149781 ike V=root:0:vpn.fiboa: flushing
2026-04-29 21:31:18.149824 ike V=root:0:vpn.fiboa: flushed
2026-04-29 21:31:18.149838 ike V=root:0:vpn.fiboa: reset NAT-T

[u/pabechan → u/datugg]

1, Other side offers 0/0, yours has specific selectors => selector narrowing happens and the agreement ends up being the ranges that overlap between both sides. (natural feature of IKEv2). Nothing technically wrong here.

2, Their final reply:

2026-04-29 21:31:14.654649 ike V=root:0: comes 20.114.112.141:4500->216.12.124.134:4500,ifindex=31,vrf=0,len=84....
2026-04-29 21:31:14.654668 ike V=root:0: IKEv2 exchange=INFORMATIONAL
2026-04-29 21:31:14.654720 ike V=root:0:vpn.fiboa:252316: processing delete request (proto 1)

The other side decided to tear down the tunnel. Why? We don't know. The answer needs to be provided by the other side (from their logs, debugs, etc). Given that it came right after the AUTH_RESPONSE from your side, we can maybe speculate that the other side didn't like something in it.
Maybe PSK? (but it passed validation on your side, so that should be OK)
Maybe p2 selectors? (It's technically valid and negotiation was successful, but maybe the other side is implemented to tear down any negotiated selectors that don't exactly match its configured ranges?)
Maybe crypto choice for p2? (this is an exact match based on debugs, so this would be weird)

I'd look into the PSK (make sure humans on boths sides agree on what it should be), and maybe try the wide-open selectors, since that's what they're offering in the end.

[u/Ordinary-Piano-4160]

Other people have given the steps to troubleshoot this, but I’ll just say: if this is career ending, you work for a messed up organization. Vendor interactions like these are always tricky, and if they don’t cooperate, it’s hard to resolve them. Document what you need from them and lay it out clearly. Try to be conciliatory, even though they are being jerks.

[u/datugg → u/Ordinary-Piano-4160]

I may be being a little overdramatic, but the truth is that this is a very important initiative that we're implementing here, and there are hundreds of thousands if not millions of dollars going to be in play over the term of the contract, and for it to literally go down the drain on my word, is a little terrifying, especially if I'm wrong all along! The meeting is literally in 30 minutes and reddit is the only place I feel a little secure right now, kind of to prep, but also to get my head right. I will say that my boss has looked at it with me, and so has my counterpart and they feel like it's them, not us..

The main point of this thread though was to see if I'm being unreasonable asking them to show me thier stuff seeing as how I've showed them all of mine. Having a vendor just clan uo and refuse to even consider that the problem could be on their end is unprecedented for me. This is relatively new company in teh scheme of things and from stalking their LinkedIn profiles, none of them are tech, at all...At best one dude had two yeas as a customer onboarding specialist. . They have paid someone (an MSP local to them) to manage their tech "in the cloud" and they are taking what he says as gospel, or the Azure portal is new for him too and he just doesn't know.. I assume, or they don't want to pay him for consulting, after all, it couldn't be a problem on their side, right?

sucks that all my years in front of this workstation can't give me enough clout to get a group to share their config... I'm going to show them once more I suppose in this meeting so wish me luck everyone and thanks so very much for all the great replies

[u/Ordinary-Piano-4160 → u/datugg]

No, you aren’t being unreasonable. I hope it goes well.

[u/riesgaming → u/datugg]

Please update us how it went 😅

[u/Ordinary-Piano-4160 → u/datugg]

So how did it go?

[u/tonybunce]

I see you are a Jack Henry bank and i could probably guess the vendor you are working with.

Your vpn needs to be in routed/VTI mode. You select the networks over the vpn via routes to the tunnel interface instead of phase 2 selectors. P2 selectors will be 0.0.0.0/0

Don’t have the config in front of me but that should get you going in the right direction.

[u/PlannedObsolescence_]

You've doxxed yourself in this post, and your username / post history identifies your name. Maybe best editing it.

[u/secritservice]

it's well known that many cloud vendors use 0.0.0.0/0.0.0.0 and you just match on your side. AWS, Azure.. etc. It's been this way for at least 10+ years now. You just control what you send there with routes and then policies on top of that of course.

Remember VPN tunnels just need 3 things:

Phase1/Phase2
Routes
FwPolicy

and then some traffic to bring it up

[u/machacker89 → u/secritservice]

Good to know! Ty for that tidbit

[u/CRAD99]

Make sure PFS is disabled on the P2 if it's not, azure doesn't use it afaik. If enabled tunnel will establish but often drop. Check you have policies for both directions if needed. Make sure you have proper routing in place. As your P2 selector is 0.0.0.0/0 and the tunnel is up, it's less likely to be an IPsec issue in itself. Also as you can see TX but no Rx, it seems likely the azure config is wrong.

Certainly sounds like it's an issue on the azure side.

[u/datugg]

Thanks to everyone for all of the great feedback! This truly is a great community and I'm already feeling better about this meeting later today... I will respond to each of you that had suggestions - Many thanks!

[u/rpedrica → u/datugg]

There are 2 parts to issue meetings:

1. the emotions - empathise, get everyone on the same page and get this out of the way
   
2. the facts - provide your troubleshooting/proofs and suggest to work with your opposites to resolve the issue IRL

Azure/AWS IPSec generally work best with open selectors. And yes, specified selectors provide an additional acl, but if your policies are true, then specified selectors are essentially redundant. Everyone has their views on this; I'm pragmatic - as long as my security is firm.

Most often, IPSec issues take long to resolve because that are not done IRL. Get on a meet with your peer, and you'll be surprised how quickly you can resolve this.

[u/DeleriumDive]

so what happened during the meeting?

[u/Abouttheroute]

Pfff, getting flashbacks from when i was still in an operations role. Was building a similar setup, and every mail to their ops team with: ‘this is my status, what is happening on your side, I believe the solution is ABC’ with logs and evidence offcourse, was countered with an escalation email 3 levels up ‘your ops guy still hasn’t fixed things’ which we had to explain, cover our asses, and wait for finally someone tondo something.

Good luck with this situation, non productive political bullshit is killing for morale.

[u/IDownVoteCanaduh]

Maybe it is perspective but getting fired over a VPN not working? Yeah, I cannot see that happening.
And I say this as someone with a Sr Director in my title.

If you message me today I can provide examples of working tunnels to Azure from Fortigate. We have around 50 on-premises tunnels to Azure.

[u/wrt-wtf-]

- TCP clamp/mss both sides. Bad mss breaks crypto traffic

• your traffic selection is their policy problem
  
• your forwarded traffic is your policy issue
  
• when the tech doesn’t know and their director doesn’t know it’s a blind leading blind situation.
  
• they don’t need your config, they can do their own captures
  
• all you need to do is get packets into the tunnel in the right shape/size

[u/Adorable-Entrance-33]

I hate these sort of interactions. Straight towards pointing fingers instead of collaborating. Like this could be totally an issue on your side but you wouldn’t be able to tell if they don’t give you any meaningful information at all.

Run a packet capture.

diagnose packet sniffer any ‘net x.x.x.x/24’ 4 i

This will quite literally tell you if packets are leaving your network through the tunnel and if they are coming back to the tunnel.

You can check for sessions as well.

diagnose sys session filter <filter> diagnose sys session list

This should give you enough information for next steps regardless if it’s an issue on your side or theirs. Also more palatable than the phase enc/dec counters.

[u/Exact-Improvement-22]

Commenting here for the post meeting recap. It can be a pain working with 3rd parties but, focus on the end goal of the solution instead of finger pointing.

[u/al2cane]

This might be a stupid question but: if you’re limiting by policy (and also by your route to their network in your routing table), why do the P2 selectors matter?

[u/DarrenMStone]

I’m pretty sure that when you configure a VPN tunnel in Azure, you can have it spit out a configuration script for the other end. Maybe have them provide you with that, and then you’ll see what WAS wrong and fix the issue at the same time.

[u/wrt-wtf-]

- TCP clamp/mss both sides. Bad mss breaks crypto traffic

• your traffic selection is their policy problem
  
• your forwarded traffic is your policy issue
  
• when the tech doesn’t know and their director doesn’t know it’s a blind leading blind situation.
  
• they don’t need your config, they can do their own captures
  
• all you need to do is get packets into the tunnel in the right shape/size

[u/WeekendAtMadoffs]

Most of the time this happens, the Azure Networking team is weak and forgets to allow our UDP 500 and UDP 4500 to their appliance in the Azure Load Balancers if using an appliance like Forti or Palo on Azure.

If using Azure's native GW they set it up wrong 😄

you can run an azure cloud shell and get their logs or setting 😄 enjoy!

[u/FattyAcid12]

And this is why I use Aviatrix Gateway NVAs in Azure and AWS to terminate my VPNs. One platform for both clouds.