Azure多S2S连接配置咨询：为第三方计费系统新增IPSec隧道以实现SSO
Hey there, let's walk through this step by step to get that second S2S tunnel set up for your billing system's SSO requirement—totally doable with your existing Azure VPN gateway!
核心前提先明确
You absolutely can have multiple S2S connections attached to the same Azure VPN gateway—each connection just links to a different peer network (in this case, your third-party billing system's network). The key is to keep each connection's resources distinct to avoid conflicts.
Step 1: 创建新的本地网络网关（Local Network Gateway）
- Yes, you do need to create a new Local Network Gateway using the details the billing system team provides you. This resource acts as a "representative" of their network in Azure, so make sure to use:
- Their public VPN gateway IP address (the endpoint your Azure tunnel will connect to)
- The subnet ranges they want you to access (or the ranges they'll use to connect to your Azure resources—get this explicitly from them)
- Give it a unique name like
LocalGW-BillingSystemto avoid mixing it up with your existing on-prem DC gateway.
Step 2: 配置新的S2S连接
Head to your existing Azure VPN gateway in the portal, then:
- Go to the Connections blade and click
+ Add - Set the connection type to
S2S (IPsec) - Use a unique connection name (e.g.,
Conn-BillingSystem—this is probably where you hit the duplicate error before, so don't reuse your DC connection's name) - Select your existing Azure VPN gateway, then choose the new Local Network Gateway you just created
- Enter the pre-shared key that you've agreed upon with the billing system team—this must match exactly on both ends (case-sensitive!)
- If they specified IKE version, encryption algorithms, or other security parameters, use those; if not, Azure's default settings should work, but double-check with them to avoid compatibility issues.
Step 3: 解决"重复连接"错误
That error almost always happens for one of these reasons:
- You tried to reuse an existing connection name or Local Network Gateway (make sure both are unique for the billing system tunnel)
- You accidentally linked the new connection to your original on-prem DC gateway instead of the new billing system one
- There's a subnet overlap between your on-prem DC network, Azure VNet, and the billing system's network. Azure blocks this because it causes routing conflicts—if this is the case, work with the billing team to adjust one of the subnet ranges.
额外注意事项
- Route propagation: Azure should automatically add routes to the billing system's subnets to your VNet's route table, but double-check that route propagation is enabled for your VPN gateway. If you're using a custom route table, you may need to manually add the route to the billing system's subnets via the VPN gateway.
- Firewall rules: Ensure both your on-prem firewall and the billing system's firewall allow IPSec traffic: UDP ports 500 and 4500, plus the ESP protocol.
- Testing: Once the connection shows as "Connected" in Azure, have the billing team test their access to your required resources, or use an Azure VM to ping a test IP they provide (if allowed). If it's not connecting, verify all parameters (IPs, subnets, shared key, IKE settings) match exactly on both sides.
And just to confirm: since the billing system controls their own end of the tunnel, your job is only to define their network in Azure via the Local Network Gateway, and set up the connection to it—they'll handle configuring their side to point to your Azure VPN gateway's public IP and your relevant subnets.
备注：内容来源于stack exchange，提问作者EastCoast2234
