About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.

2017/03/16

Skype Edge Server and 2:1 NAT

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:

test 02 Feb

this is a test it’s only a test this should be a picture