Fiddler capturing and decrypting traffic on a DIFFERENT network

Having recently worked through a number of Exchange ActiveSync issues it was necessary to setup a Fiddler proxy on a different network than the mobile device I was testing with. In my working scenario I wanted to setup a Windows client hosted as an Azure VM with Fiddler installed with an internet accessible IP address. On my mobile device I wanted to push my web traffic through that Fiddler session to capture the traffic and troubleshoot web requests/responses.

Firewall rules aside, this appears to be a little more complex than say installing Fiddler on the machine running Outlook to troubleshoot. In this situation we cannot install Fiddler on a mobile device (iOS/Android), so we need to give the mobile device a proxy server to send traffic through. There is also some additional configuration in Fiddler beyond what I was able to find documented, so I wanted to make note of it here. Partly so this is discoverable for anyone, part so that when I forget the steps I have somewhere to go look it up again.

Pre-requisites:

1. You need a Windows client machine with a public IP address.
2. You need to have installed Fiddler

Standard configuration to capture / decrypt HTTPS traffic:

1. If you are reading this then you are probably already familiar with making sure both 'Capture HTTPS CONNECTs' and 'Decrypt HTTPS traffic' are selected in the Tools, Options, HTTPS tab.
2. In addition you should go to the Connections tab, change the port Fiddler listens on to something less standard than 8080 or 8888, then check the 'Allow remote computers to connect' option.

The Fiddler secret sauce:

This part had my mind running in circles for a couple of days. Eventually I spoke to my colleague Jason for some guidance. He's a big fan of Fiddler, even he does not think this method has been documented before now.

1. Per the above you should by now have Fiddler capturing and decrypting traffic on the local computer.
2. Make sure Fiddler is capturing traffic. You should see 'Capturing' in the bottom left hand corner of the tool.
3. Clear all sessions to make this easier.
4. On your Fiddler computer open a web browser and go to http://localhost:48888 or what ever port number you set in set 2 of capturing / decrypting HTTPS traffic.
5. You are expecting to see the 'Fiddler Echo Service' web page.
6. Download the FiddlerRoot certificate, save it, it does not matter where.
7. Stop capturing.
8. Back in fiddler select all frames on the left hand side, then CTRL click the two frames shown below in Fig 1 to deselect those frames. Everything else is just noise, including the favicon. Remove the selected sessions.
9. We want to only see the two frames shown below in Fig 1.
10. You now want to click on the AutoResponder tab shown below in Fig 1.
11. Drag and drop the two frames from the left panel to the right panel.
12. This creates two rules for the AutoResponder.
13. Ensure you check both 'Enable rules' and 'Unmatched requests passthrough'.
14. Look towards the bottom of the rule list and you will see rule editor.
15. Your rules will currently say 'EXACT:http://localhost:9988/' for example.
16. You need to edit these so they resemble the rules in Fig 1 below.
17. Make sure to click Save on the bottom right as you edit each rule.
18. Optional/Additional: On my remote client machine (actually another Windows computer) with or without proxy settings setup to direct web traffic to my Fiddler proxy, I can now load the Fiddler Echo Service page. However I found I could not download the certificate. This was fixed by 'Promoting' the FiddlerRoot.cer frame above the :9988/ frame. Right click on the Fiddler.cer rule and click Promote.

Fig. 1

End state notes:

1. I have a Fiddler Echo Service page which loads for any client on the internet, regardless of whether the machine / device is sending web traffic to the proxy already or not.
2. Clients need to download the certificate from this service page, install it and trust it, so the Fiddler proxy can decrypt the traffic without web services throwing certificate warnings.
3. I can have mobile devices (iOS/Android), Windows or any other device for that matter route traffic through this proxy, so the requests/responses can be captured and reviewed for troubleshooting.
4. Typically this setup is going to be used for in-house repro's of customer issues.
5. Why did we remove the EXACT:http://localhost from the rules? We need to allow any host using whatever host name they like to connect to the service. The rule with localhost would only allow the computer running Fiddler to connect.
6. A note on security: Should you leave Fiddler running on your internet connected Windows VM? No you should not. We only want this service online when we need it to troubleshoot. Simply make sure the Fiddler application is closed. Port no longer available from the internet. Job done.