We'd love to hear about it! Click here to go to the product suggestion community
I hope this is the correct forum. It took me some time before I found out how to even post a question.
I have this FileMaker database server which is sitting in the private network. Using NAT, I have configured all traffic over port 5003 to go to the internal IP of that server.
Because it is using SSL encryption, I have set up a reverse proxy entry for https, and linked my domain it's wild card certificate to it, and I am passing host headers.
That worked fine until some months ago, don't know exactly, probably after some upgrade or update.
Now, when I connect from the outside to the server, it is telling me that the certificate is invalid. There is a button to look at the certificate from that dialog, and it shows that all parts of the certificate ( cert, intermediate, CA ) are all OK.
This does not happen when I connect from the inside, using the same DNS name.
I realise this is not exactly main stream http / https proxying, but just maybe someone has experience here with this particular setup.
I am confused. If you use a reverse proxy (WAF), you do not use NAT.
Are you accessing FileMaker with a browser or a custom application?
UTM WAF has an unwanted "feature" that causes it to include the root certificate in the certificate chain. This is technically incorrect, because the root certificate is useless it is pre-installed on the client device, and as a self-signed certificate in the certificate chain should be untrusted by the receiving system. Browsers will ignore the unwanted certificate, but some custom software might not. Check to see if you need to configure a certificate-checking override.
In reply to DouglasFoster:
DouglasFosterI am confused. If you use a reverse proxy (WAF), you do not use NAT.
The WAF is for the https part, the NAT is for the database connection over TCP 5003. Both are needed. The WAF part takes part of the initial connection and authentication, and later on for blob/container streaming.
DouglasFosterAre you accessing FileMaker with a browser or a custom application?
I can use both the web browser and the regular FileMaker client. The web browser doesn't give any problems, it's the FileMaker client that is being difficult about the certificate. I have an additional SSL web site running using the web application firewall, using the same wildcard certificate, and it is running fine.
DouglasFosterUTM WAF has an unwanted "feature" that causes it to include the root certificate in the certificate chain. This is technically incorrect, because the root certificate is useless it is pre-installed on the client device, and as a self-signed certificate in the certificate chain should be untrusted by the receiving system. Browsers will ignore the unwanted certificate, but some custom software might not.
Let me try to rephrase that, so you can check if I understand it. The Sophos UTM is relaying ALL the certificate information, the certificate itself, the intermediate one, AND the root certificate, and this last one should not be sent. The FileMaker client ( custom software ) is not accepting that, the check button is just using the WebKit or IIS browser frameworks to verify the certificate and sees no problem at all. This seems to fit what I am experiencing.
DouglasFosterCheck to see if you need to configure a certificate-checking override.
I do not know how to configure an override, I would like to test with some other certificate that does not include the CA. Is it possible to upload that using the Sophos web console? Or do I have to connect using SSH and configure this from the terminal?
Thanks for your help so far.
In reply to clarifix:
The problem may be related to the dual sessions. The WAF accepts a connection from you and creates a connection, on your behalf, to the web site. The remote system is probably having difficulty matching the two sessions. There is an X-Forwarded-For header that UTM and other WAF devices add to the relay session so that the receiving webserver has the option of seeing the source address instead of the UTM address as the client.
I think your next inquire should be to your FileMaker support channels to see how / whether it works when a WAF device is involved.
DouglasFosterI think your next inquire should be to your FileMaker support channels to see how / whether it works when a WAF device is involved.
I fear that is not a good option.
FileMaker support is not knowledgeable enough to answer questions like these. Maybe after a lot of explaining they will understand the question, but when/if they would, I am 99% sure they would respond that this is not not supported. Or something like that. Setups like this are impossible for them to reproduce, they would need a networking lab, so I think FileMaker support will not provide answers.
I wil have more luck I guess with the US FileMaker forums. I will ask my question there.
You may be able to figure it out on your own. The first step is to see if anything is being blocked. I am comparing your question to this situation:
Some remote access methods use two sessions on two different ports. I will use Citrix as an example:
For Citrix to work with UTM, the web session can go through the WAF, but the second session has to be allowed through the firewall rules.
For your situation:
If you are the only user, or one of a very small group of users, then Remote Access over SSL VPN should solve all these problems and provide equivalent or greater security, without WAF.
Always use 2-factor authentication with remote access. It is required by PCI DSS standards, might be needed for GDPR compliance, and is just good practice. There are a lot of bad guys doing password guessing attacks on a lot of Internet-facing resources.
Hi,I'm currently trialling FileMaker and hit this problem (for some reason I'm now struggling with the 5003 NAT even that 443 with WAF is fine).Anyway, as has already been mentioned in other posts, the reverse proxy adds in extra headers (x-forwarded-****).This appears to mess with the URL Rewrite rules in IIS that FileMaker uses to point public addresses to local services.The fix for me was for add in my own rewrite rule in the site web.config file (at C:\Program Files\FileMaker\FileMaker Server\HTTPServer\conf in my installation).
I put it as the first rule, to remove the offending headers before FileMaker deals with the request.<rule name="X-forward" patternSyntax="Wildcard"> <match url="*" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false" /> <serverVariables> <set name="HTTP_X_FORWARDED_FOR" value="" /> <set name="HTTP_X_FORWARDED_SERVER" value="" /> <set name="HTTP_X_FORWARDED_HOST" value="" /> </serverVariables> <action type="None" /></rule>
I had to add in HTTP_X_FORWARDED_FOR and HTTP_X_FORWARDED_SERVER as additional Server Variables in IIS Manager (HTTP_X_FORWARDED_HOST was already allowed by default).