Mitel Forums - The Unofficial Source
Mitel Forums => Mitel Software Applications => Topic started by: davidcpt71 on May 13, 2016, 05:03:13 PM
-
Attempting to setup my MBG's to act as a proxy to the Micollab/AWC server. The MBG is configured on the network edge.
Proxy works great for Micollab and the client, however when attempting to set the proxy up for AWC I get notified , MSL must have a second WAN interface configured in this mode for AWC to function.
The AWC server does have 2 IP addresses, and 2 fqdn's.
Is this stating that the MGB needs 2 WAN interfaces? If this is the case are the 2 WAN interfaces bridged, or separate IP addresses?
Thanks,
Dave
-
Yes, the MBG would need two WAN interfaces with seperate external IP's.
-
Does this effect anything with the way the MGB is currently licensed? Would I need to get a license or record modified?
-
The second interface is aliased. You need one physical interface and two IP addresses on the WAN network. There is no additional licensing.
-
Perfect, I thought that was the case but wanted to verify first. After adding the second IP address to the MGB it now let me add the proxy for the AWC. I also setup the 2 DNS records on the public side pointing to these 2 IP's on the WAN interface.
Only thing I seem to have an issue with is I am not able to ping that second IP address from outside its network. IE, from a device on the same layer 2 network I can, but from another subnet I can't. But I can ping the first IP of the WAN interface. I would assume that the second IP would use the same gateway? Not sure if there is something that has to be defined for ARP proxy??
So internally micollab.abc.com and micollab2.abc.com point to the same LAN address, where on the external DNS micollab.abc.com points to WANIP1 and micollab2.abc.com goes to WANIP2
-
A second wan interface on MBG is used to bridge other external addresses to customer's firewall from what I've read.
-
I think it's and ISP problem with the address I selected. I changed the second IP to the next available in my subnet and it works fine now.
-
Yes, the MBG would need two WAN interfaces with seperate external IP's.
The second interface is aliased. You need one physical interface and two IP addresses on the WAN network. There is no additional licensing.
A second wan interface on MBG is used to bridge other external addresses to customer's firewall from what I've read.
These three lines just explained something to me I have never understood for years... I have tried to use this a dozen times for various purposes and always failed, tried it this morning with a seconds IP address on a second NIC and it worked perfectly. I always thought I was doing something wrong but it was never important enough to figure out and we always found another way to accomplish the same thing.
Thanks for this thread, and the information.
-
A second wan interface on MBG is used to bridge other external addresses to customer's firewall from what I've read.
With AWC (AWV) the issue is that both HTTPS incoming and the ConnectionPoint conference traffic are terminated on TCP port 443. To be able to receive two different connections on the same port, two interfaces are used. This is only true if remote proxy is on the network edge, handling all traffic.
If instead, remote proxy is behind the customer firewall, then the customer firewall must have two IPs on the WAN and port forward traffic on TCP port 443 to the remote proxy, the first IP to port 443 and the second to the configured ConnectionPoint port, typically 4443. This allows the remote proxy in MBG to handle both traffic types on different ports with a single interface.
It's messy, and it's a result of AWC (AWV) overloading destination port 443.
-
If instead, remote proxy is behind the customer firewall, then the customer firewall must have two IPs on the WAN and port forward traffic on TCP port 443 to the remote proxy, the first IP to port 443 and the second to the configured ConnectionPoint port, typically 4443. This allows the remote proxy in MBG to handle both traffic types on different ports with a single interface.
It's messy, and it's a result of AWC (AWV) overloading destination port 443.
I think they also need a rule doing the return conversion
-
A decent firewall will keep track of the state of the DNAT'd traffic and automatically SNAT it on the way out, so it depends on your firewall.