This morning, we resolved an issue that I have never seen before, and hope that I never do.
The Background
I tell customers during design sessions that if there are existing network issues, Skype (or Lync) is going to find them. If there is something a bit wonky, we are going to discover the wonkiness. And here we go.
Skype edge with 1:1 Nat. Public IP is 71.16.x.x. Edge server is doing the classic 3 IP thing. Remote logins are fine. Everything seems to be ducky. Except we cannot talk outbound.
Go check all the network again. Looks good. Check the topology, servers, IP assignments, paths. All good. Certificates, the common culprit behind one-way federation and presence look good. We are now scratching our heads. We know now we are looking at something wonky, but what?
The Fix
I was under the impression that 1:1 NAT is 1:1. But it turns out that a Watchguard Firebox is capable to doing 2:1 NAT. Inbound to the Edge server worked because the firewall had 1:1 NAT from public to DMZ VLAN. Edge trace logs showed subscriptions and connections timing out on the far side. The connections were being made, just no return traffic. No SYN. Telnet client testing outbound from the edge server on 5061 ad 443 worked. Clearly inbound connections were working or there would be no remote logins.
As long as the traffic originated from outside the organization, things worked fine and the Edge server, via the 1:1 NAT was responding as expected to the source IP. But traffic originating from INSIDE the organization was failing. One way presence, presence unknown, cannot send to user, etc. Apparently…
…according to www.ipchicken, the Watchguard was sending all traffic from the DMZ external VLAN out via a completely separate set of addresses! HUH? Whaaaaat? So inbound would work, but outbound went out on a separate address?
So their firewall guy fixed that, we are back to 1:1 NAT and all is good. Something to be aware of, eh? Go figure.
YMMV
No comments:
Post a Comment