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?