Alex's questions

For a potential project, we are tasked with developing a website (API/SPA principle) which has a paramount requirement of keeping personally identifiable information (PII) about its visitors anonymous, and the data they provide encrypted at rest. The latter requirement is quite easily addressed using available libraries and best practices.

What I'm concerned with, is that I can't find any clear information about which data Microsoft is storing about the hypothetical visitors to my website. This probably depends on the specific service we would use, which will likely be Azure Kubernetes Service (AKS).
Specifically the visitors IP addresses are considered sensitive and thus should not be stored anywhere.
As the owner/operator of the application I know that I have to actively enable additional services (e.g. log analytics) in order to see this information, but does Microsoft see about my visitors? I can't imagine they are keeping no logs whatsoever of who visits their infrastructure, if only for the purpose of e.g. blacklisting abusive IP addresses (DDoS attacks, ...).
Any documentation about this would be much appreciated.

Assuming Microsoft does keep track of visitor IP addresses, what would be alternatives that don't? I'm open to alternative cloud providers, or even a 3rd party service that acts as a gateway to the Azure infrastructure, making only its IP visible to Azure, and meanwhile not logging its visitors IP addresses.

I'm having some issues getting my AKS pods/containers connected to our on-prem network.

I have a virtual network in the 172.16.20.0/22 and 172.16.24.0/29 namespaces. They have 2 subnets, each has one of the above ranges as their subnet range.

The AKS cluster is bound to the 172.16.20.0/22 subnet, and each of the nodes as well as the pods are getting an IP address in that range. I Also added a regular VM to this subnet for temporary debugging.

In the 172.16.24.0/29 subnet, we have a Virtual Network Gateway (it has no IP in this subnet) which connects that subnet to our on-prem network. The VN Gateway has a matching local network gateway with address space 172.17.151.0/24. In our local network we have an SMTP server on 172.17.151.254, listening on port 25.

On the VM I spun up for debugging, I can connect to the SMTP server just fine. I can also ping the VM from the SMTP server without problems. From the pods however, I cannot connect to SMTP (tested with netcat -zv 172.17.151.254 25), neither can I ping a pod's IP address from the SMTP server.

Neither the subnets have an network security group (NSG) attached, so it can't be a misconfigured NSG rule. What else could be causing the connection to fail? The pods get the same basic network configuration from the DHCP serverin the subnet:

• A 172.16.20.0/22 ip address
• 172.16.20.1 as their default gateway

Out IT staff which maintains the on-prem device which is connecting to the Azure VNG helped me debug, they say that when initiating an SMTP connection to 172.17.151.254 they see the packet arriving, and a response package from the server going back into the VPN tunnel, so it seems the response packet is getting dropped somewhere in Azure.
Edit: During a further debug session with our IT staff, we noticed that the source IP of the packets coming from our misbehaving pod, is 172.17.20.5, instead of 172.16.20.21. 172.17.20.5 is the IP of the VMSS node the pod is running on, so that could make sense, but this would mean that the internal routing on that node isn't configured correctly.

Or is this something specific to kubernetes that is causing this to fail?

What I've tried so far:

• On VM: ping to 172.16.20.21 (pod): works fine
• On VM: ping to 172.17.151.254: works fine
• On VM: tracert 172.17.151.254 succeeds in 1 hop (shouldn' this be at least showing 2 hops as it passes through the default gateway?)
• On pod: ping to 172.16.20.4 (vm): works fine
• On pod: ping to 172.17.151.254: fails
• On pod: traceroute 172.17.151.254 fails with no hops showing
• On on-prem VPN device: ping to 172.16.20.4 (vm): works fine
• On on-prem VPN device: ping to 172.16.20.21 (pod): fails

Extra info:

ifconfig -a from pod:

eth0: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet 172.16.20.21  netmask 255.255.252.0  broadcast 0.0.0.0
        ether de:c7:74:e3:c5:24  txqueuelen 1000  (Ethernet)
        RX packets 386868  bytes 35746728 (34.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 511891  bytes 43865660 (41.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 5  bytes 504 (504.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 504 (504.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

route output from pod:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.20.1     0.0.0.0         UG    0      0        0 eth0
172.16.20.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0

ipconfig /all from debug VM:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : debug-vm
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 00-0D-3A-2D-DC-BA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::e9bb:fede:66cc:398c%6(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.20.4(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Lease Obtained. . . . . . . . . . : Friday, August 28, 2020 7:15:08 AM
   Lease Expires . . . . . . . . . . : Friday, October 8, 2156 1:20:49 PM
   Default Gateway . . . . . . . . . : 172.16.20.1
   DHCP Server . . . . . . . . . . . : 168.63.129.16
   DHCPv6 IAID . . . . . . . . . . . : 100666682
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-DA-67-54-00-0D-3A-2D-DC-BA
   DNS Servers . . . . . . . . . . . : 168.63.129.16
   NetBIOS over Tcpip. . . . . . . . : Enabled

route print from debug vm:

===========================================================================
Interface List
  6...00 0d 3a 2d dc ba ......Microsoft Hyper-V Network Adapter
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      172.16.20.1      172.16.20.4     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
    168.63.129.16  255.255.255.255      172.16.20.1      172.16.20.4     11
  169.254.169.254  255.255.255.255      172.16.20.1      172.16.20.4     11
      172.16.20.0    255.255.252.0         On-link       172.16.20.4    266
      172.16.20.4  255.255.255.255         On-link       172.16.20.4    266
    172.16.23.255  255.255.255.255         On-link       172.16.20.4    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       172.16.20.4    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       172.16.20.4    266
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    331 ::1/128                  On-link
  6    266 fe80::/64                On-link
  6    266 fe80::e9bb:fede:66cc:398c/128
                                    On-link
  1    331 ff00::/8                 On-link
  6    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

I am looking to create a pseudo-fallback WAN connection in my router which does not natively support this.

I have a network of 192.168.93.0/24, my 'main' router and default gateway is on 192.168.93.1, this is the DHCP server as well and it hands out it's own IP as default gateway for all clients.

Then I have a 2nd router which has a 4G connection on IP address 192.168.93.2, this router does not do DHCP.

Now I've been studying my 1st router, which connects to a WiFi hotspot for its WAN connection. Whenever this connection succeeds, it adds a route to its routing table (destination 0.0.0.0/0 - so whole internet) to whatever IP the WiFi hotspot gateway is with a metric of 0.

So I figured I add a manual entry to it's routing table, with the same destination network of 0.0.0.0/0 but a gateway of 192.168.93.2 (my 2nd 4G router).

This seems to work on some level, as that I can perfectly ping to anywhere on the internet, when my 1st router does not have it's Wifi hotspot connected. However, when I try to browse somewhere using e.g. chrome, all requests time out.

When I start a wireshark trace on the client, I see a lot of worrying logs, like:

• TCP Retransmission
• Spurious retransmisssion
• TCP Dup ACK

Now when I delete the 0.0.0.0/0 route to 192.168.93.1 (1st router) on my client, when reconfigure it to go directly to 192.168.93.2 (2nd router), everything works fine.

Now that I'm thinking about this I'm wondering whether this can work at all, but why is the ping then working fine? In any case would be great if someone could explain exactly why this is not working.

I would like to test the upload speed of my FTP/HTTP server against various international locations. I could imagine that a web-based tool (like a reverse speedtest.net) for this exists, but when it does I can't find it...

I have a 100mb download available via FTP which I would like to have tested from various locations.

In the meantime it would be great if you could download the file for me and report which speeds you're getting: ftp://ftpuser:[email protected]/100mb.test

This file is hosted on a virtual private server and I'm only reaching about 10Mbit/s (1MB/s) when downloading it to my office location. The server is supposed to have a 100Mbit uplink and the hosting provider claim they cannot find any errors at their side. Running speedtest-cli on the server indeed reports an uplink speed of near 100Mbit/s. I have a 120Mbit/s downlink connection (which I also achieve from various international locations), so why can't I get this near 100Mbit/s speed from my server??

We have 2 branch offices with local file servers synced to our central office and file server via DFS-R. Mostly data is copied from the central fileserver to both branch offices, but the sync is both ways since occasionally data is also generated in the branch offices and has to appear centrally as well as in the other branch office. Our central server and one branch office is Win2003R2 std and the other branch office is Win2008R2 std

Last night somehow we lost a lot of data (800GB) by accidental delete or some rogue script (still under investigation). We only have central backups, which is currently being recovered on our central server. However due to limited bandwidth, having DFS-R sync everything back to our branch offices is not a viable option.

So once our central server is restored again, I would like to prepare 2 USB disks with all central data mirrored onto, and send them off to our branch offices, so they can be locally filled again with the data.

The question is, how to do this in a supported way that won't break DFS-R. I wouldn't want DFS-R to see the remote data as 'new' data, and start copying everything over again, or worse, deleting everything centrally or something...

Some time ago we had to reinstall a file server in one branch office, back when I used 'robocopy /MIR /SEC /SECFIX' (to ensure the data is as close to 1:1 as possible, to prevent DFSR form seeing a difference and re-syncing anyway) to copy the central data onto the USB disk, and used the same command to copy it back to the local server from the USB disk. After that I added the server (which was reinstalled and thus not a member of the replication group anymore) back to the replication group, this worked fine.

But since now the server is still known and a member of the replication group, i don't know if the same approach will work.

I have 2 possible scenarios in mind which I think might work, however some confirmation (or better ideas even) might be welcome: Both ideas will use a disk prepared by copying everything of the central server using 'robocopy /mir /sec /secfix'

• First option (least effort): temporarily disable the connection between the central and branch office servers, after the branch office server is re-synced locally using robocopy, enabled the connections again and hope for the best
• Second option: Remove the branch office servers completly from the replication groups, and after they've been locally re-synced, add them back which will (i think) do an initial replication. This is essentially the same as I've done with the re-installed server so I'm quite confident this will work.

I have a small server running several virtual machines, some web servers and also a windows 2008 R2 Remote Desktop Gateway server. The intention is to have an Apache2 server running on Ubuntu 11.10 which will act as a reverse proxy server to forward requests to the corresponding server based on the hostname that is used.

I have this working for several other Ubuntu Apache2 servers and for the IIS7 server running on my 2008 R2 RD Gateway server.

With working, I mean that I can access all these web servers both via HTTP and HTTPS based on the hostname I'm visiting with a web browser.

What does not work however, is using the remote desktop gateway functionality, to connect from an external client to an internal RDP server.

I know that the RD gateway server is configured correctly because if I redirect external HTTPS traffic directly to it's IP (bypassing the apache2 proxy server) everything works fine. When I put the apache2 proxy in between, and try to establish an RDP connection from an external source, I get the following error in the apache proxy error.log:

[error] (70007)The timeout specified has expired: proxy: prefetch request body failed     to 192.168.2.172:443 (rdpgw.internal.domain.com) from xx.xx.xx.xx ()

Where xx.xx.xx.xx is my external client's IP.

The remote desktop client on the remote client will give a generic timeout error, and on the RD Gateway server everything seems fine. When connecting directly to the RD gateway server I can see this in the IIS logfile:

2012-01-26 11:54:13 192.168.2.172 RPC_IN_DATA /rpc/rpcproxy.dll localhost:3388 443 - xx.xx.xx.xx MSRPC 401 1 2148074254 15
2012-01-26 11:54:13 192.168.2.172 RPC_OUT_DATA /rpc/rpcproxy.dll localhost:3388 443 - xx.xx.xx.xx MSRPC 401 1 2148074254 15

And when connecting through the apache2 proxy I can see:

2012-01-26 11:54:53 192.168.2.172 RPC_IN_DATA /rpc/rpcproxy.dll localhost:3388 443 - 192.168.2.170 MSRPC 401 1 2148074254 46
2012-01-26 11:54:53 192.168.2.172 RPC_OUT_DATA /rpc/rpcproxy.dll localhost:3388 443 - 192.168.2.170 MSRPC 401 1 2148074254 31

So the connection in the 2nd case is coming from the apache2 proxy. otherwise the connections seem to be the same.

About one thing I'm not quite sure how it should be setup, are the certificates on both servers. I understand that HTTPS can by design not be 'intercepted' and forwarded by the proxy server, so if I'm correct there are actually 2 seperate SSL connections involved here: 1 from the remote client to the apache proxy, and one from the apache proxy to the RD gateway server. I figured it would be best if the remote client did not see the difference, so I used the same self-signed certificate and private key on both the apache proxy and the RD gateway server.

There are the contents of the corresponding vhsot apache2 config file:

<VirtualHost *:443>
   ServerName rdgw.externaldomainname.com

   ProxyRequests off
   ProxyPreserveHost on
   ProxyPass / https://rdgw.internal.domain.com/
   ProxyPassReverse / https://rdgw.internal.domain.com/

   SSLEngine on
   SSLProxyEngine on
   RequestHeader set Front-End-Https "On"

   SSLCertificateFile /etc/apache2/certs/rdgw.externaldomainname.com.crt
   SSLCertificateKeyFile /etc/apache2/certs/rdgw.externaldomainname.com.key
</VirtualHost>

Hopefully someone knows how this can be done? It should be possible as I found this MS article which describes how to setup exactly this configuration, only with MS ISA as a proxy server instead of Ubuntu/Apache2