Options
How to make exception for geolocation to not block one internal fqdn
Hello,
we have a HTTPS-proxy rule configured witth Static NAT to the proxy webserver. Geolocation is enabled. I added an exception for host.company.de (virtual host on webserver). But it is still blocked. Any sucsessions how to make it work?
Greetings Mike
0
Sign In to comment.
Answers
Please post a log message showing a Geo deny for this
2020-02-18 14:54:53 Deny 193.31.74.36 192.168.178.2 https/tcp 36786 443 7-allex-fo Firebox blocked sites (geolocation source) 60 53 (HTTPS-proxy-OWA-inbound-00) proc_id="firewall" rc="101" msg_id="3000-0173" tcp_info="offset 10 S 1387165038 win 29200" geo_src="SAU" geo="geo_src"
The geo block is for the source IP addr - which is from Saudi Arabia.
You can add an IP addr exception for 193.31.74.36
You can't whitelist an internal web server from having geo blocking being applied to traffic to it.
If you don't want to have geo blocking on the incoming policy HTTPS-proxy-OWA-inbound, then unselect geo blocking on it.
I understand.
This sentence in documentation is missleading:
Geolocation never blocks connections to or from sites on the exceptions list.
The goal is that only this one virtual host is open for all / some more countries. But the rule handles all traffic to the webserver.
Maybe I can make a rule only for this virtual host with SNAT to webserver wich comes before the other ones? Would it work when first rule with SNAT routes from external interface to fqdn of virtual host (on webserver) and the second (current one) from external to IP of webserver?
The 1st firewall policy which matches incoming packets will be used and no further policies will be checked.
To have no geo blocking for 1 internal web site and geo blocking for another internal web site, you would need a separate public IP addr for both.
I know, that's why I thougt a first rule just matches with fqdn but not for other hosts on webserver, the second one with IP for the rest because first is ignorded. That's what I mean. Is this possible?
If my succession is not possible i have to accept it like this, thank you anyway
Since the FQDN IP addr is the same as the IP addr for the other internal web site, there is no way for the firewall to identify a difference.
The dest IP addr is the same, and it is the dest IP addr which is checked for a match on an incoming policy.
For a HTTPS session, the FQDN is not known by the firewall until a HTTPS proxy with Inspect can see the FQDN in the incoming packet
Hello Bruce,
I'm sorry for the late reply. But can you answer me one more question: Do I need a second public IP under all circumstances or would it work with a second internal IP for the webserver?
Greetings Mike
You would still need a way to determine which traffic going to the public IP addr of the firewall should go to web site 1 and which should go to web site 2.
For HTTPS, Inspect would be needed.
I don't see how this would help with having different geolocation rules for the 2 internal web sites.