Firewall rule does not work as expected

Hi,

have you installed the certificate if you are performing scanning?

ian

Try to open the same domain in the policy tester. 

Could be a issue with the DNS lookup and therefore not be able to categorized. 

Can you check the firewall log for the same packet? Simply check for the Destination IP in the advanced log and find the firewall entry. Which rule was used there? 

Yes. I use two certificates. One for the SSL scanning itself and the "web admin certificate" for the user portal because i use the DPI engine and application control.
In the past i could reproduce an error during the EAP phase for v18. When the connection got intermitted for scanning, i got an certificate error until i defined a web admin certificate with alternate name and then rolled it out on the client. Since then it works flawless.
But i guess this a antoher story. 

Now that's interesting. The policy tester shows the expected triggering:

But in the advanced logs you can see that the rule ID6 got triggered and not ID: 2 like it was supposed to:

This is the usual behavior if you're relying on FQDN for Firewall rules. (It's a bit unreliable)

One other thing, using a full domain is much more reliable than wildcards on XG for FQDN's. (This is from personal experience while dealing with SD-WAN.)

If you want to bypass Origin traffic from being scanned or decrypted then it's much better to use the Web Exceptions than creating a Firewall Rule with FQDN's.

Also, what issues you're currently having with Origin and Battlelog? I'm doing TLS Inspection (Decryption) and still managed to (login) play BF4 and BF5 as expected. (Even with Proton on Steam)

Hi,

first of all thank you for the informations. I'm working with a FQDN-hostgroup for netflix and this is working fine most the time. For some strange cases I added an addtional "IP-range" exception to cover some connetion issues related with netflix.

Now my current Origin problem: My first try was to implement some web exceptions. Unfortunately this doesn't work. I also created some TSL inspection exceptions as you can see in the logs above. For test purposes i disabled my already established web exceptions for the web filter related to Origin. That's the reason they are not in the logs right now.

Because with BF4 everything worked fine, just with web filter exceptions. When i try to log on a cumminty server, I just needed to add the IP-address occurred in the logs to my TLS-exceptions list. Unfortunately this doesen't work with BF5 so i decided to create a firewall rule. 

The problem is, some apps like games are very poorly designed. There are couple of them, which uses a IP to connect to. And i am not talking about a DNS record, instead, they connect to https://IP , which is very bad. SFOS does not categorize a IP, as it is nearly impossible to tell, what this IP actually is (Could be CDN, could be a Host etc.). 

Therefore, sometimes, (especially in Home segments) you have to collect such IPs for exceptions. IoT / Games are the worst scenario for HTTPs Decryption, as those development departments basically do not expect anybody in between the communication. Therefore they simply implement a solution (poorly implemented). 

If you look left/right, you will find dozen of such examples. World of Warcraft for example connects to a IP as well as Authentication service. Rocket leagues server are always IPs, so the Match making is giving you a plain IP, which you have to connect to. 

Web exceptions only work for SNI related traffic. Likely they do not even give a SNI in such requests. You can see the SNI in Logviewer. 

"Therefore, sometimes, (especially in Home segments) you have to collect such IPs for exceptions."

Yes, that's the reason i created a FQDN-hostgroup with several FQDN-hosts in it, to collect the associated IPs and subdomains. But like Prism said, this is apperently unrelaiable for using in firewall rules. When i look in the policy test tool the correct rule got triggered. But for real traffic this "Test" rule will not be used... Mysterious. 

Lucar is right, some games are really poorly designed, and you only notice this when you start using enterprise software/hardware.

TheBalmasque said:

When i try to log on a cumminty server, I just needed to add the IP-address occurred in the logs to my TLS-exceptions list.

Be sure to check the TLS Inspection Logs, if the connection to the community server doesn't have a domain on the sni (showing as IPv4), then It's also self-signed which could be the reason on why It's causing so many issues.

Even then, if you can, check your DNS server logs, but I'm sure community servers connect directly to the IP which is the reason on why FQDN's doesn't work.

When i'm at home i try to produce some new logs for the connections.

For BF4 there are some IP addresses in the logs while connecting to a community server. But for BF4 i can easily start a match after simply putting the related IP address to the TLS exection list. (In most cases there is no need to do this, because i already put them on the list)

For BF5 the situation is a bit different. There are no IP addresses from the connected servers itself appering in the logs. But there are several "river.ea.com" and "battlelog.com" connections.