Weirdness with/without domain name
Posted: Wed Jul 29, 2015 4:29 pm
I have two hosts, issues.example.com and docs.example.com. Normally I connect to these sites as shown to the left with https. When I'm connected through VPN, I can refer to them as just issues and docs. I sometimes get links to these in gmail, and they can show up as https://issues/ or https://issues.example.com
In the ABE system rulesets, I have:
Site LOCAL ^https://.*\example\.com
Accept from LOCAL
Accept from ^https://.*\example\.com
Accept from https://talkgadget.google.com
Accept from https://mail.google.com
Accept from https://www.google.com
Deny
The last three represent the various sites ABE reports as blocked. Often, I'll have two sites comma separated after the <<< , one representing the google redirect.
When I click on a link I received through gmail to https://issues.example.com/blahblahblah, I get the following ABE warning:
Request { GET https://issues.example.com/blahblahblah <<< https://issues.example.com/partofthepreviousURL, https://mail.google.com/_/scs/sometrackinglink} filtered by ABE: <LOCAL ^https://.*\.example\.com> Deny
If I change the last three lines from Accept to Anonymize, I have to login each time, but the links go through. I don't understand why.
Is my approach right? Is there something I'm not understanding about handling both inside/outside the VPN? Does LOCAL sometimes match these and sometimes not if I'm inside the VPN? Should I enumerate these sites individually before a LOCAL rule? Sometimes I get email linking to an internal only site that's not available outside the VPN.
I'm assuming I'm a bit lax by combining LOCAL with the example.com rule.
I'm on version 2.6.9.32.
In the ABE system rulesets, I have:
Site LOCAL ^https://.*\example\.com
Accept from LOCAL
Accept from ^https://.*\example\.com
Accept from https://talkgadget.google.com
Accept from https://mail.google.com
Accept from https://www.google.com
Deny
The last three represent the various sites ABE reports as blocked. Often, I'll have two sites comma separated after the <<< , one representing the google redirect.
When I click on a link I received through gmail to https://issues.example.com/blahblahblah, I get the following ABE warning:
Request { GET https://issues.example.com/blahblahblah <<< https://issues.example.com/partofthepreviousURL, https://mail.google.com/_/scs/sometrackinglink} filtered by ABE: <LOCAL ^https://.*\.example\.com> Deny
If I change the last three lines from Accept to Anonymize, I have to login each time, but the links go through. I don't understand why.
Is my approach right? Is there something I'm not understanding about handling both inside/outside the VPN? Does LOCAL sometimes match these and sometimes not if I'm inside the VPN? Should I enumerate these sites individually before a LOCAL rule? Sometimes I get email linking to an internal only site that's not available outside the VPN.
I'm assuming I'm a bit lax by combining LOCAL with the example.com rule.
I'm on version 2.6.9.32.