Wildcard exceptions in aliases not being honored
I have a T35 running 12.5.3.
I just tried to do a Web Restore from CrashPlan for Small Business web site and it hung the process at a "Contacting backup server..." message.
Watching my FSM traffic monitor, I saw that in spite of having an outbound exception to *.crashplan.com, it was blocking port 4285 going to 162.222.42.233, which nslookup shows as the aye-sea.crashplan.com FQDN. I added that explicit aye-sea.crashplan.com FQDN to my FQDN-TrustedSites alias, which is in the To field of my UnrestrictedAccess.Out packet filter. After saving the config, I was able to see the web restore work normally.
I have had this issue with many sites where *.domain.tld fails, but host.domain.tld works fine.
Why can't I get the wildcard domains to work?
Gregg Hill
Comments
From the docs:
"To resolve the subdomains implied by *.example.com, the Firebox analyzes DNS replies that match your domain name configuration. As DNS traffic passes through the Firebox, the Firebox stores the IP address mapping responses to relevant queries. Only A and CNAME records are used. Any other records are ignored."
Is CrashPlan actually accessing a FQDN that results in a DNS query to get the IP addr ?
If not, (they are just accessing a stored IP addr) then that is the reason that your wildcard doesn't work.
Bruce,
I am not sure if CrashPlan is accessing an FQDN that results in a DNS query to get the IP address. I'll reboot the T35 to clear all of its DNS, clear DNS on my workstation, enable DNS, then test.
If they are just accessing an IP address and not an FQDN, then why would adding the aye-sea.crashplan.com FQDN make it work?
Gregg
Gregg Hill
I also left *.crashplan.com in the alias, but removed the aye-sea.crashplan.com FQDN, then tested. It does one DNS lookup, then hits a server at crashplan.com on 443 TCP twice, then goes for the 4285 port server.
Right after I click the Restore button, I get this:
2020-04-01 23:42:43 Allow src_ip=192.168.16.11 dst_ip=185.228.168.10 pr=dns/udp src_port=49333 dst_port=53 src_intf=1-VLAN1-PrivateLAN dst_intf=0-External msg=Allowed pckt_len=77 ttl=127 policy=(DNS-filter.Out-00) proxy_action= proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="172.x.x.x" src_port_nat="62385" geo_dst="IRL" Traffic
2020-04-01 23:42:43 Allow src_ip=192.168.16.191 dst_ip=216.17.8.19 pr=https/tcp src_port=51489 dst_port=443 src_intf=1-VLAN1-PrivateLAN dst_intf=0-External msg=Allowed pckt_len=52 ttl=127 policy=(UnrestrictedAccess-TrustedLocations.Out-00) proxy_action= proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_dst_match="crashplan.com" src_ip_nat="172.x.x.x" tcp_info="offset 8 S 3170185238 win 64240" geo_dst="USA" Traffic
2020-04-01 23:42:43 Allow src_ip=192.168.16.191 dst_ip=216.17.8.19 pr=https/tcp src_port=51490 dst_port=443 src_intf=1-VLAN1-PrivateLAN dst_intf=0-External msg=Allowed pckt_len=52 ttl=127 policy=(UnrestrictedAccess-TrustedLocations.Out-00) proxy_action= proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_dst_match="crashplan.com" src_ip_nat="172.x.x.x" tcp_info="offset 8 S 465354678 win 64240" geo_dst="USA" Traffic
2020-04-01 23:42:43 Deny src_ip=192.168.16.191 dst_ip=162.222.42.233 pr=4285/tcp src_port=51491 dst_port=4285 src_intf=1-VLAN1-PrivateLAN dst_intf=0-External msg=Denied pckt_len=52 ttl=127 policy=(Unhandled Internal Packet-00) proxy_action= proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 S 378637958 win 64240" geo_dst="USA" Traffic
2020-04-01 23:42:44 Deny src_ip=192.168.16.191 dst_ip=162.222.42.233 pr=4285/tcp src_port=51492 dst_port=4285 src_intf=1-VLAN1-PrivateLAN dst_intf=0-External msg=Denied pckt_len=52 ttl=127 policy=(Unhandled Internal Packet-00) proxy_action= proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 S 162826853 win 64240" geo_dst="USA" Traffic
Gregg Hill
If you are not seeing a DNS packet between the allow and the deny, then probably 162.222.42.233 is not the result of a DNS lookup.
The only way to know for sure is to use a DNS proxy with Log selected on Query Names.
Note that DNS policies in a config are still ignored if you have DNSWatch enabled.