OCS Access Edge Server Not Listening on Port 443

I have recently configured OCS 2007 R2 Standard.  This server is working all okay internally.  I am now trying to configure Edge to allow access externally.  I have configured 3 public IPs and applied NAT rules on my firewall to local IP and the specific ports.  From that standpoint, all traffic is being forwarded okay - except traffic to my Access Edge IP on port 443.  Traffic to this local IP is going through okay on port 5061.  I have also tested with this tool:  https://www.testocsconnectivity.com/.  I have posted a screenshot of testing with this tool on port 443 and port 5061.

Not sure why port 443 is not being allowed to hit this local ip.  I have turned off the Windows Firewall on this Server, so the traffic should not be blocked.  I am not sure what to do next.  The user I am testing with

Any help is very much appreciated.
test1.jpg
test2.jpg
obautistaAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
BusbarConnect With a Mentor Solutions ArchitectCommented:
please make sure that you configured the OCS edge access IP to listen on port 443, I think you made it listen on 5061
0
 
obautistaAuthor Commented:
I am still learning OCS set up.  I have attached a couple screenshot of my Edge Interface Properties.  Where should I make the changes?  Thanks for your help.
test.jpg
test2.jpg
0
 
BusbarSolutions ArchitectCommented:
change the remote access port to 443
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
obautistaAuthor Commented:
Thanks.  I am getting closer.  I am still getting the error shown in the screenshot when testing though.
test.jpg
0
 
BusbarSolutions ArchitectCommented:
can you login using this user internally
0
 
obautistaAuthor Commented:
Internally, I can login using Communicator and test connectivity.  By the way, I have also enabled user for remote user access and Configuring Federation, Remote User Access, and Public IM Connectivity for Individual Users. On Edge,  External User Access/Remote User Access is checked also.
0
 
BusbarSolutions ArchitectCommented:
sometimes if you configure the or modify the user settings starting the front End service applies the permissions.
restart the front end service and try again
0
 
obautistaAuthor Commented:
Restarted, but same results.
0
 
Jeff_SchertzCommented:
You cannot place both the internal and external roles in the same TCPIP network.  From your screen-shot you either have (A) a single network interface on the Edge server or (B) two interfaces connected to the same subnetwork.

Take a look at these articles for an explanation of why those scenario are not supported:
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/ViewPost.aspx?ID=15
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/ViewPost.aspx?ID=19
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/ViewPost.aspx?ID=33
0
 
obautistaAuthor Commented:
Thanks Jeff.  I am sorry, but I do not understand.  Are you referring to Access, Web/Conferencing, or A/V.  I have the following configuration:

Public IP                   Local IP               Port#
75.149.66.202 ==> 192.168.1.42 ==> 443
75.149.66.204 ==> 192.168.1.43 ==> 443
75.149.66.204 ==> 192.168.1.43 ==> 5061
75.149.66.205 ==> 192.168.1.41 ==> 443

192.168.1.41 is my internal interface.

Does that appear to be set up correctly?  I have a 4 port NIC dedicated to ony my Edge.

Thanks for your help -
0
 
Jeff_SchertzCommented:
I'm assuming you mean to say that ".40" is your internal interface. And if each NIC port is seen as a separate interface to Windows then you do have dedicated internal/external interfaces.

But the internal interface should not be on the sam TCPIP network as the external interfaces.  So either move the internal interface to another subnet (like 192.168.2.0/24) or move all of the external interfaces to a different network.  Also be aware that you cannot perform NAT on the internal interface between the Edge and the internal Front-End server, it must be routable.

Additionally look at that article to see if you have a gateway configuration issue preventing external traffic from routing correctly: http://blog.schertz.name/2010/09/understanding-strong-host-v2
0
 
BusbarSolutions ArchitectCommented:
eagle eye Jeff, Missed that.
from my firewall experience it will be much easier to move the External NIC to another segment like 2.0 and then change the NAT statement at the firewall side.
0
 
obautistaAuthor Commented:
Just wanted to post my finding before closing this post.

I had a couple problems.  First, I am setting this up in a test environment, therefore, I do not have public certs assigned to the external interface.  I generated the certs through my local CA.  Second, to get auto-signin working, after updating my remote access port to 443 I had not updated my SRV Record on my public DNS to point to 443 (it was pointing to 5061).  I also had protocol on my public DNS set to _tcp.  I changed it to _tls.  After making the change, I waited a couple hours for the changes to propogate.  I then was able to verify traffic was being forwarded as expected using NSLOOKUP in the command prompt window.

Things are working now.  I was able to test connectivity from the outside.  I just had to export the root .cer file and import it on the client machine to test.  

Internal and External interfaces do not have to be on different segments.  I didnt have to change anything there.  I do not know the requirements around when they have to be on different segments, but using my configuration things are up and running.

Thanks so much for your help....
0
 
obautistaAuthor Commented:
Thanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.