Exchange not working through VPN

I can't explain this at all am and really baffled.

I finally got a IPSec VPN tunnel setup to the Fortigate at the office. For some reason (I think I know why) the clients can connect to the remote network but not the sophos. Not a big deal, I setup my DHCP server to give the office DNS server to my laptop (my wife doesn't need it so keep it simple).

Everything works great, EXCEPT Exchange. Outlook can't connect, I can't connect to OWA or anything else. In IE I get an error 502 bad gateway. Nothing else.

If I go to the public IP of the Exchange server everything works. But using the internal IP nothing works.


IE gives me an 502 bad gateway, chrome and firefox just can't load the page.

I can ping the mail server, I can telnet to the mail server on port 443 and it "appears" to work. I can tcping the server on port 443, I can even use openssl and get the (correct) certificate from the mail server. But that is it. I can't get to OWA, Outlook can't connect nothing.


Does anybody have any idea/suggestions?

  • Nsumner,

    can you explain better your network? Where is the Sophos XG located?

    Behind the Fortigate?


  • In reply to lferrara:



    At my house is the Sophos XG, and the Office is the Fortigate. Home network office network Exchange 2013 (cluster).

  • In reply to nsumner:


    Did you create a LAN to VPN and VPN to LAN firewall rules? Make sure to untick https scanning.

    The other idea is to disable micro-app discovery:

    system application_classification microapp-discovery off. If it does not work, do you see something inside the log?


  • In reply to lferrara:

    I have the firewall rules in place obviously (otherwise nothing would work). I don't have https scanning or any other scanning taking place on those rules (including application scanning) hence the whole discussion about microapp discovery seems irrelevant.


    I can ping the server, I can even RDP to the server. It is just https traffic to the internal IP of the server.

  • In reply to nsumner:

    Thanks Nsumner.

    If you are accessing your email server by FQDN, verify if the Pharming proteciton is enabled under Web > Advanced.

    If it is enabled, disable it and check again.


  • In reply to lferrara:

    So the pharming protection was preventing you to reach the remote site because you tried to access it using hostname.

    is there any plan to improve pharming protection?

    For example, create a dns host entry on XG for situation like Sumner so we do not need to disable pharming protection at all?

    Also XG should log pharming protection blocked the user dns request somewhere.

    Hope to get more info regarding it from you.

    I have seen several threads where people had to disable the pharming protection feature (which is unsafe).


  • In reply to lferrara:

    Firstly Luk thanks for your help.


    Just to clarify for any other users looking here. The pharming protection is under.


    web-->Protection under malware scanning select advanced.


  • In reply to lferrara:

    From my reading of this thread, its not clear to me that this was a pharming protection issue.


    I know of no upcoming plans to change pharming protection.  AFAIK the feature is working the way it is intended to.  The only time there is a problem is when a client and SFOS resolve a domain to two different IP addresses.  The solution is to fix your DNS or resolution.

    Pharming protection is available for both XG and the UTM, and the UTM has a much larger user base.  AFAIK the implementation and behavior is similar.  I am less 'tuned in' to the UTM community right now, does anyone know if the UTM has pharming protection issues?  If the UTM does, then you should raise it as a problem with sophos making sure that it is clear that it affects both products - the greater the userbase the higher the priority.  In the reverse case, if you know this is a problem unique to XG, when you raise it make sure to mention that - because that suggests more that there is a bug or feature gap between the products.


  • In reply to Michael Dunn:

    Thanks Michael.

    In this case, users is using the XG as the DNS server. Because there is a VPN connection, XG returns the Public IP of the resource while the computers uses the IP returned by the DNS server via VPN.

    Around community are cases like this one. I think we need a way to override this behaviour (as I wrote) where XG checks first the dns entries that it has locally (created by users), otherwise it checks on internet.


  • In reply to lferrara:

    Exchange...requires active directory.  Why not configure the XG to use AD dns server as well?
    At least feasible for branche offices that have their own AD (or even RODC)

  • In reply to sixteen again:

    It is for me to connect to the office from my house. No AD server here.


    In terms of using the AD DNS server there are 2 issues.

    1: The Firewall itself isn't able to speak over the VPN (I could make changes but...).

    2: Even if it were easy to do, I need the corporate AD servers, but the rest of my family does not!


    The VPN is limited to my computers and nobody else in the family.