This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sigh, now UTM blocks Windows Activation...

9.312-8 UTM

I am trying to activate a Windows 2012 Standard server in a VM on my 2008 server.  The operation times out and cannot connect to activate, yet I can browse my internal network and use the web browser for external sites.  So, I know that network connectivity is working just fine.

Watching the Web Filter log, it shows no block attempts for microsoft.com domains, and I am seeing access there.

I am not getting anything at all in IPS or ATP live logs as I watch them.  However, I am seeing in the Firewall live log, the TCP 443 port being blocked for the activation IP address for sls.microsoft.com, the domain that machines connect to in order to activate their Windows versions.

19:08:40 	Default DROP 	TCP 	  	

65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:08:40  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:08:40  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:08:41  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:08:43  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:08:46  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:08:52  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84
19:09:06  Default DROP  TCP    
65.52.98.231  :  443
→ 
172.18.0.15  :  49254
  
[ACK PSH FIN]  len=40  ttl=64  tos=0x00  srcmac=00:30:18:c4:f8:84


I created a specific HTTPS rule to allow all traffic for that port, I even went as far as Any Any Any on one setting.  I disabled IPS/ATP/Web Filtering.  it is still being blocked, and I cannot activate.

UTM has turned into a dog with a bone on this.  Doesn't seem to matter what I do to get around this, UTM is just going to tell me to f-off.

My only thing left to do is connect my server directly to the ISP modem to get anywhere with this.  Not at all what I want or should have to do with this.


This thread was automatically locked due to age.
Parents
  • Hi Ian,
    You are correct, that it is inbound traffic being dropped by the Firewall log results I posted for HTTPS traffic, which is allowed.  /boggle.

    - Nothing at all in IPS/ATP logs at all for this.

    This is the only line I see in the Web Filtering log:

    2015:06:18-12:41:09 amodin httpproxy[14213]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="CONNECT" srcip="172.18.0.15" dstip="65.52.98.231" user="" ad_domain="" statuscode="200" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="10281" request="0xe5f45000" url="activation.sls.microsoft.com/" referer="" error="" authtime="0" dnstime="1" cattime="137" avscantime="0" fullreqtime="60244617" device="0" auth="0" ua="" exceptions="av,ssl,fileextension,size" category="105" reputation="trusted" categoryname="Business"
    


    Here is the exceprt from the Firewall log:

    2015:06:18-12:51:39 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49187" tcpflags="ACK PSH FIN" 
    
    2015:06:18-12:51:56 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49188" tcpflags="ACK FIN" 
    2015:06:18-12:51:56 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49188" tcpflags="ACK PSH FIN" 
    2015:06:18-12:51:56 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49188" tcpflags="ACK PSH FIN" 
    2015:06:18-12:51:58 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49188" tcpflags="ACK PSH FIN" 
    2015:06:18-12:52:00 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49188" tcpflags="ACK PSH FIN" 
    2015:06:18-12:52:03 amodin ulogd[14025]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="00:30:18:c4:f8:84" srcip="65.52.98.231" dstip="172.18.0.15" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="49188" tcpflags="ACK PSH FIN"
  • Hi,
    sorry for the delay, work gets in the road.

    PF rules have no affect on webproxy traffic. 
    What are your https setting for the webproxy, you might need to add bypass https as well to the webproxy rule exception.

    Ian M
Reply
  • Hi,
    sorry for the delay, work gets in the road.

    PF rules have no affect on webproxy traffic. 
    What are your https setting for the webproxy, you might need to add bypass https as well to the webproxy rule exception.

    Ian M
Children
No Data