WirelessPhreak.com

Use Cases:

Since the COVID-19 pandemic, many companies have leveraged VDI Horizon infrastructure to accommodate their remote workers. Today remote users connect to VDI Horizon infrastructure over many different means home ISP connections, company-issued cellular devices/hotspots on multiple carriers, as well as personal devices. We have identified an issue with cellular devices traversing the ATT Wireless network connecting to VDI Horizon infrastructure.

The Architecture:

I wanted to simplify the VDI Horizons infrastructure discussion to just the pieces that are crucial to the issue. The relevant parts that come into play for user access to the Horizons environment is the VMWare Horizon client, hardware load balancers, and the UAG or User Access Gateway servers. 

The Protocols:

VDI Horizons traffic is split between primary and secondary protocols. The primary protocol used for authentication is over HTTPS or port 443. Within the ATT wireless network, this traffic is sourced from the primary enterprise PAT address. After the VMware Horizon client has authenticated and established secure communication to one of the UAG appliances, one or more secondary connections are made from the Horizon client. These secondary connections can include:

• Blast Extreme display protocol (TCP 443 and UDP 8443). Note that UDP is optional with Blast.

• PCoIP display protocol (TCP 4172 and UDP 4172).

The secondary Horizon protocols must be routed to the same UAG appliance and from the same client IP address that the primary Horizon protocol was authenticated from. The UAG authorizes the secondary protocols based on the authenticated user session. The UAG will only forward traffic into the corporate data center on behalf of an authenticated user.

The Symptoms:

On the ATT Wireless network when a user's Horizon client connects to a virtual IP address it is load balanced to a UAG server and the session is authenticated. The IP address of the traffic is sourced and authenticated using the device’s IP address, this is true for all networks. When the Horizon client attempts to connect to the secondary protocol the traffic destined to the secondary protocol port, UDP 8443, or TCP or UDP 4172, is routed through a proxy within the ATT network. When the traffic is routed through the ATT proxy the source IP address of that traffic is different than the original device IP that was used to authenticate the user session and the VMware UAG server rejects the traffic. In some situations, the load-balanced traffic may even be sent to a different UAG server. This seems to be true for all users on the ATT Wireless network.

Moving toward a solution:

The first part of solving the problem is identifying the cause, and we believe that is done. Since the IP address of the primary and secondary protocols are different, the Horizons server rejects the traffic or perhaps never sees the traffic based on load balancing and persistence settings of the load balancer. ATT network engineers have been very helpful with troubleshooting and validating that our assumptions are accurate and are currently looking at solutions to solve the issue. 

**Update** the ATT sales people that where interfacing with the ATT technical staff have informed us it is not possible to fix the issue.  They are trying to sell us a cellular router that they say can be routed over an APN to solve the issue, instead of letting the technical folks fix the issue for us and potentially everyone else on the ATT wireless network.

What would we like to see:

We would like to see the secondary protocols included in the enterprise PAT and not routed through the proxy. If this was implemented, it could fix VDI Horizons across the entire ATT Wireless environment for everyone.

During the pandemic, I have been binging more and more Star Wars shows on Disney+. While I have been taking in all that Star Wars it hit me I wasn't sure when these individual shows or movies took place in the canon timeline. Shows like the Mandalorian throw in some deep-cut references that I didn't get until I understood when it took place.

So I wanted to put up a list in chronological order to help myself and hopefully, everyone else enjoy Star Wars a little bit more.

• Episode I Phantom Menace
• Episode II Attack of the Clones
• Clone Wars (movie)
• Clone Wars (tv show S1-7)
• Episode III Revenge of the Sith
• Solo: A Star Wars Story
• Star Wars: Rebels (S1-4)
• Rouge One: A Star Wars Story
• Star Wars: A New Hope
• Battlefront (video game)
• The Empire Strikes Back
• Return of the Jedi
• Battlefront II (video game)
• The Mandalorian
• Star Wars: Resistance S1 (tv show)
  
• The Force Awakens
• Star Wars: Resistance S2 (tv show)
• The Last Jedi
• Rise of Skywalker

Also if you want more in depth info I found this interactive site that lists alot more then just TV and movies. https://starwarscanontimeline.com/

Enjoy!

Dig (Domain Information Groper) is a powerful command-line tool for querying DNS name servers.

The dig command, like nslookup, allows you to query information about various DNS records, including host addresses, mail exchanges, and name servers. It is the most commonly used tool among system administrators for troubleshooting DNS problems because of its flexibility and ease of use.

This tutorial explains how to use the dig utility through practical examples and detailed explanations of the most common dig options.

To check if the dig command is available on your system type:

dig -v

The output should look something like this:

DiG 9.10.6

If dig is not present on your system, the command above will print “dig: command not found”. The dig tool can be installed using the distro’s package manager.

Quick command Cheat Sheet:

More in depth, understanding the dig Output:
In its simplest form, when used to query a single host (domain) without any additional options, the dig command is pretty verbose.

In the following example, we’re performing on the wirelessphreak.com domain:

dig wirelessphreak.com

The output should look something like this:

    ; <<>> DiG 9.10.6 <<>> wirelessphreak.com
     ;; global options: +cmd
     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19643
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
     ;wirelessphreak.com.        IN    A

     ;; ANSWER SECTION:
     wirelessphreak.com.    300    IN    A    104.24.119.62
     wirelessphreak.com.    300    IN    A    172.67.210.173
     wirelessphreak.com.    300    IN    A    104.24.118.62

    ;; Query time: 37 msec
    ;; SERVER: 208.67.220.220#53(208.67.220.220)
    ;; WHEN: Mon Nov 16 12:16:45 PST 2020
    ;; MSG SIZE  rcvd: 95

Let’s go section by section and explain the output of the dig command: 

The first line of the output prints the installed dig version, and the queried domain name. The second line shows the global options (by default, only cmd).

    ; <<>>DiG 9.10.6 <<>> wirelessphreak.com
    ;; global options: +cmd

 If you don’t want those lines to be included in the output, use the +nocmd option. This option must be the very first one after the dig command.

 The next section includes technical details about the answer received from the requested authority (DNS server). The header shows the opcode (the action performed by dig) and the status of the action. In this example, the status is NOERROR, which means that the requested authority served the query without any issue.

    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19643
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

This section can be removed using the +nocomments option, which also disables some other section’s headers.

The “OPT” pseudo section is shown only in the newer versions of the dig utility. You can read more about the Extension mechanisms for DNS (EDNS) here .

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096

To exclude this section from the output, use the +noedns option.
 

In the “QUESTION” section dig shows the query (question). By default, dig requests the A record.

    ;; QUESTION SECTION:
    ;wirelessphreak.com.            IN    A

You can disable this section using the +noquestion option.

The “ANSWER” section provides us with an answer to our question. As we already mentioned, by default dig will request the A record. Here, we can see that the domain wirelessphreak.com points to the three IP address.

    ;; ANSWER SECTION:
    wirelessphreak.com.    300    IN    A    104.24.119.62
    wirelessphreak.com.    300    IN    A    172.67.210.173
    wirelessphreak.com.    300    IN    A    104.24.118.62

Usually, you do not want to turn off the answer, but you can remove this section from the output using the +noanswer option.

The “AUTHORITY” section tells us what server(s) are the authority for answering DNS queries about the queried domain. In this example it did not provide and authoritative server answer.

    ;; AUTHORITY SECTION:

You can disable this section of the output using the +noauthority option.

The “ADDITIONAL” section gives us information about the IP addresses of the authoritative DNS servers shown in the authority section.

    ;; ADDITIONAL SECTION:

The +noadditional option disables the additional section of a reply.

The last section of the dig output includes statistics about the query.

    ;; Query time: 37 msec
    ;; SERVER: 208.67.220.220#53(208.67.220.220)
    ;; WHEN: Mon Nov 16 12:16:45 PST 2020
    ;; MSG SIZE  rcvd: 95

You can disable this part with the +nostats option.

Printing Only the Answer
Generally, you would want to get only a short answer to your dig query.
1. Get a Short Answer

To get a short answer to your query, use the +short option:

dig wirelessphreak.com +short

     104.24.119.62
     172.67.210.173
     104.24.118.62

The output will include only the IP addresses of the A record.
2. Get a Detailed Answer

For more a detailed answer, turn off all the results using the +noall options and then turn on only the answer section with the +answer option.

dig wirelessphreak.com +noall +answer

     ; <<>> DiG 9.10.6 <<>> wirelessphreak.com +noall +answer
     ;; global options: +cmd
     wirelessphreak.com.    300    IN    A    104.24.119.62
     wirelessphreak.com.    300    IN    A    172.67.210.173
     wirelessphreak.com.    300    IN    A    104.24.118.62

Query Specific Name Server
By default, if no name server is specified, dig uses the servers listed in /etc/resolv.conf file.

To specify a name server against which the query will be executed, use the @ (at) symbol followed by the name server IP address or hostname.

For example, to query the Google name server (8.8.8.8) for information about the wirelessphreak.com domain you would use:

dig wirelessphreak.com @8.8.8.8

     ; <<>> DiG 9.10.6 <<>> wirelessphreak.com @8.8.8.8
     ;; global options: +cmd
     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23065
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

     ;; OPT PSEUDOSECTION:
     ; EDNS: version: 0, flags:; udp: 512
     ;; QUESTION SECTION:
    ;wirelessphreak.com.        IN    A

    ;; ANSWER SECTION:
    wirelessphreak.com.    299    IN    A    104.24.118.62
    wirelessphreak.com.    299    IN    A    104.24.119.62
    wirelessphreak.com.    299    IN    A    172.67.210.173

    ;; Query time: 31 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Mon Nov 16 12:27:32 PST 2020
    ;; MSG SIZE  rcvd: 95

Query a Record Type
Dig allows you to perform any valid DNS query by appending the record type to the end of the query. In the following section, we will show you examples of how to search for the most common records, such as A (the IP address), CNAME (canonical name), TXT (text record), MX (mail exchanger), and NS (name servers).
1. Querying A records

To get a list of all the address(es) for a domain name, use the a option:

dig +nocmd google.com a +noall +answer

    google.com.        128    IN    A    216.58.206.206

As you already know, if no DNS record type is specified, dig will request the A record. You can also query the A record without specifying the a option.
2. Querying CNAME records

To find the alias domain name use the cname option:

dig +nocmd mail.google.com cname +noall +answer

    mail.google.com.    553482    IN    CNAME    googlemail.l.google.com.

3. Querying TXT records

Use the txt option to retrieve all the TXT records for a specific domain:

dig +nocmd google.com txt +noall +answer

    google.com.        300    IN    TXT    "facebook-domain-       verification=22rm551cu4k0ab0bxsw536tlds4h95"
    google.com.        300    IN    TXT    "v=spf1 include:_spf.google.com ~all"
    google.com.        300    IN    TXT    "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"

4. Querying MX records

To get a list of all the mail servers for a specific domain use the mx option:

dig +nocmd google.com mx +noall +answer

    google.com.        494    IN    MX    30 alt2.aspmx.l.google.com.
    google.com.        494    IN    MX    10 aspmx.l.google.com.
    google.com.        494    IN    MX    40 alt3.aspmx.l.google.com.
    google.com.        494    IN    MX    50 alt4.aspmx.l.google.com.
    google.com.        494    IN    MX    20 alt1.aspmx.l.google.com.

5. Querying NS records

To find the authoritative name servers for our specific domain use the ns option:

dig +nocmd google.com ns +noall +answer

    google.com.        84527    IN    NS    ns1.google.com.
    google.com.        84527    IN    NS    ns2.google.com.
    google.com.        84527    IN    NS    ns4.google.com.
    google.com.        84527    IN    NS    ns3.google.com.

6. Querying All Records

Use the any option to get a list of all DNS records for a specific domain:

dig +nocmd google.com any +noall +answer

    google.com.        299    IN    A    216.58.212.14
    google.com.        299    IN    AAAA    2a00:1450:4017:804::200e
    google.com.        21599    IN    NS    ns2.google.com.
    google.com.        21599    IN    NS    ns1.google.com.
    google.com.        599    IN    MX    30 alt2.aspmx.l.google.com.
    google.com.        21599    IN    NS    ns4.google.com.
    google.com.        599    IN    MX    50 alt4.aspmx.l.google.com.
    google.com.        599    IN    MX    20 alt1.aspmx.l.google.com.
    google.com.        299    IN    TXT    "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
    google.com.        21599    IN    CAA    0 issue "pki.goog"
   google.com.        599    IN    MX    40 alt3.aspmx.l.google.com.
   google.com.        3599    IN    TXT    "facebook-domain-    verification=22rm551cu4k0ab0bxsw536tlds4h95"
    google.com.        21599    IN    NS    ns3.google.com.
    google.com.        599    IN    MX    10 aspmx.l.google.com.
    google.com.        3599    IN    TXT    "v=spf1 include:_spf.google.com ~all"
    google.com.        59    IN    SOA    ns1.google.com. dns-admin.google.com. 216967258 900 900 1800 60

Reverse DNS Lookup
To query the hostname associated with a specific IP address use the -x option.

For example, to perform a reverse lookup on 208.118.235.148 you would type:

dig -x 208.118.235.148 +noall +answer

As you can see from the output below the IP address 208.118.235.148 is associated with the hostname wildebeest.gnu.org.

    ; <<>>DiG 9.10.6 <<>> -x 208.118.235.148 +noall +answer
    ;; global options: +cmd
    148.235.118.208.in-addr.arpa. 245 IN    PTR    wildebeest.gnu.org.

Bulk Queries
If you want to query a large number of domains, you can add them in a file (one domain per line) and use the -f option followed by the file name.

In the following example, we are querying the domains listed in the domains.txt file.
domains.txt

lxer.com
linuxtoday.com
tuxmachines.org

dig -f domains.txt +short

    108.166.170.171
    70.42.23.121
    204.68.122.43

The .digrc File

The dig command’s behavior can be controlled by setting up per-user options in the ${HOME}/.digrc file.

If the .digrc file is present in the user’s home directory, the options specified in it are applied before the command line arguments.

For example, if you want to display only the answer section, open your text editor and create the following ~/.digrc file:
~/.digrc

+nocmd +noall +answer

Conclusion
dig like nslookup is a command-line tool for querying DNS information and troubleshooting DNS related issues. My personal opinion dig is a much more powerful tool since it gives more of the raw DNS output. In the hands of an individual who understands DNS both dig and nslookup are powerful tools.

 

Who would have thought that 7 month later and for most of us there are no plans to go back to the office. For remote workers audio/video conference and collaboration software has become a tool we use sometimes all day. For me personally quality of audio and video has become an important part of work. for me personally its very distracting when someone is garbled, or there video is horrible. I wanted to put up some of my favorite tools I have found to help provide quality remote working experience.

Audio:

Microphones are an important tool for quality audio. If your a teacher providing distance learning or office worker meeting with clients or colleagues good audio is important. I wanted to list USB based audio that would work with most if not all computers and remote access software.Most of them I have tried.

• Audio-Technica ATR2100x-USB Cardioid Dynamic Microphone: 
• This thing has been a work horse I have used it for podcasting as well as meetings. Its only downfall you have to be pretty close to the mic for it to pic you up.
  
• Rode VideoMic NTG:
• I just picked this one up. It's really designed as a shotgun mic to go on top of your DSLR for better video audio, but Rode has also added a USB port that lets it work as a shotgun mic connected directly to your PC. So far I like that I can position the Mic further away but still have rally good sound quality.  
• Apple Airpods:
• Many people use these as have I, and for me I have not been impressed. I have not used the Airpod Pros, but I found the original Airpods to be very fickle. Many times the mic would cut out or garble what I was saying.  I do like how easy they are to pair with different devices and for listing to music they are great, I am just not a fan of using them as a mic. 
• Built in Apple Mic and Speakers
• I have found the built in mic and speakers on my macbook pro to be very capable. Right now I have my macbook docked so the mic is not usable but when I am traveling and working I have never got any complaints about the audio. It nice that it is built in for sure.
• Head Phones or no Head Phones:
• Luckily the video conference software has gotten much better with sound rejection. For example if you are using the speakers and mic on your laptop  the software is smart enough to cancel what is coming out of your speakers and only broadcast your voice. That being said it isn't perfect but its pretty close. For me it really depends on the environment. If your working in an airport or Starbucks of course headphones are crucial, at home i kind of bounce between headphones and laptop speakers. I really don't want to wear headphones for 8 hours strait .
  

 Video:

Video for me is not as important as audio quality since most of my meetings are audio,  but for distance teachers or just audio video geeks like myself having a nice camera is pretty important.

• Logitech C930E:
• The Logitech C930 series cameras have been the de facto for good quality reliable HD video. I have had mine for 4 years and still haven't been on a call with someone who has better video. There is nothing you can say bad about these cameras accept they are hard to find right now.
• DSLR with HDMI to USB adapter:
• If you are an aspiring YouTuber then this might be the solution for you. There are a lot of older DSLR cameras out there that have really good video features and are pretty cheap. The only issue is the HDMI to USB adapters range in quality and price.  Its really hard to tell what is quality and what is junk.  If you go down this route it is important you do your research.
• Apple built in FaceTime or iSight Cameras:
• Ahhh... They work but they aren't great.  If your on the road running light they work in a pinch. If you have a newer iPhone you may be better using that, they usually have better cameras then the laptops.
• EPOC cam Webcam for MAc and PC:
• Lastly I wanted to leave you with a software alternative. EPOC software is an app that can be installed on your iPhone. Once the iPhone app is installed you install the companion software on your computer. It allows you to use the epic camera on your iPhone as a HD webcam.  It also adds the ability to connect to the iPhone camera over wireless or wired. Definitely worth checking out https://apps.apple.com/us/app/epoccam-webcam-for-mac-and-pc/id449133483

Lights:

If your not a professional YouTuber or Video Podcaster it might not be super important but if you have a darker office like me and you attend early or off hour meeting a cheap studio light or good room lighting can dial back the creep factor.

• SUPON L122T Ultra-Thin LED Video Light Pane:
• This light is really chap and worked really well.  It pretty bright and you can change the tone from warmer to cooler as well as brighter and softer.  It doesn't come with  power supply so you will need to order it separately. You can even power it with battery packs so it can be completely mobile, I have been really happy with it.

 

Hope these ideas can help with your video conference gear ideas.

So the F5 is a tricky beast often refereed to as the swiss army knife of network appliances. The appliances primary role in many networks is to load balance and is a beast negotiating SSL. That being said its not always easy to determine how to configure the clients SSL profiles to be secure and still service the public. F5s documentation is helpful but designed to be vague because cipher suites and browser support is always changing. https://support.f5.com/csp/article/K8802

SSL Labs has become the de-facto to use tool that helps the public understand the nuances of SSL by giving an easy to understand letter grade, https://www.ssllabs.com . The website runs a multitude of tests from insuring your certificate is chained correctly to end device OS and browser simulations, to commonly found vulnerability testing. The down fall of having such a sophisticated tool issuing a simple letter score, is not every environment can be configured for an A or B plus.

So I wanted to through an F5 Client SSL Profile out there that at the time of testing got a solid A- and still supported a ton of OS and browser combinations. You will mostly want to keep the defaults but I will highlight what changes you will want to make to get an A. You will need to select Advanced to see some of these settings.

• The first step is to add your public certificate and the intermediate certificates if applicable as well as the key.
•  this is what create the certificates chain

• Next you will want to customize the Ciphers that will be used by the F5 to negotiate SSL with the client. This is where 99% of the magic will happen.
• DEFAULT:HIGH: (are pre canned cipher settings created by F5, the additional settings are additional customization.
  
• !RSA: Do not use RSA ciphers
  
• !SSLV3: Do not use SSL version 3
  
• !RC4: Do not use RC4 ciphers
  
• !EXP: Do not use Cipher length of 40 or 56 bits export strength
• !DES: Do not use Des or triple Des ciphers
  
• !TLSv1_1: Do not use TLS version 1.1
  
• !TLSv1: Do not use TlS version 1.0
  
• !ADH: Do not use ADH ciphers
• !EXPORT: Do not use EXPORT grade (weak) ciphers
• !SHA: Do not use Message Authentication Code SHA 128
  

• The complete string looks like this:
• DEFAULT:HIGH:!RSA:!SSLV3:!RC4:!EXP:!DES:!TLSv1_1:!TLSv1:!ADH:!EXPORT:!SHA

• Lastly you will want to set up strict SSL renegotiation:
• Check the  Renegotiation box
• Next set Secure Renegotiation to "Require Strict"

From here save your SSL client profile, apply it to a public accessible virtual server, and run SSL labs against your server. Its kind of fun testing and playing around to see what modifying the cipher settings.

Enjoy.