- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- Re: Enabling Anti-Phishing on R81.20 VSX without I...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Enabling Anti-Phishing on R81.20 VSX without Internet interface
VSX R81.20 T24
I'm looking for the best way to et-up Anti-Phishing on VS's doing HTTPS Inspection but don't have a public interface, this is done by an upstream system.
Zero Phishing In-Browser protection is not working for HTTP sites (checkpoint.com) mentions that it's best practice to use a public IP for the FQDN, even if it's a dummy one and assign it to a disconnected interface.
Now the issue with VSX is that assigning an IP to a discrete disconnected interface will cause this IP to be monitored and the VS will go from Active/Standby to Active/Down.
Is it then recommended to still enable the interface and create a connectivity between the VSX cluster members for that IP.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We had a similar use case in the past, need of a dummy interface. We solved this with a new VLAN interface on an existing BOND. To get the interface up you have to configure the connected switchports with the same VLAN-ID, because they are monitored as you wrote. Normally only first and last VLAN on a trunk are monitored, you could use one in between without to be monitored . But for troubleshooting and some other interaction it's better to configure this like a normal, including the switch.
If you can't use a VLAN you can use a new physical interface but you have to connect these to a switch to get the link up or if only two gateways are used via a direct attached cable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would strongly suggest to contact TAC !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We had a similar use case in the past, need of a dummy interface. We solved this with a new VLAN interface on an existing BOND. To get the interface up you have to configure the connected switchports with the same VLAN-ID, because they are monitored as you wrote. Normally only first and last VLAN on a trunk are monitored, you could use one in between without to be monitored . But for troubleshooting and some other interaction it's better to configure this like a normal, including the switch.
If you can't use a VLAN you can use a new physical interface but you have to connect these to a switch to get the link up or if only two gateways are used via a direct attached cable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's very correct, I used this method in the past for so-called loopbacks. The issue here is that dummy public IP is required. Since it will be up if either connected with a port or bond VLAN, it will be redistributed in dynamic routing and will then require specific routemaps where we used a generic redistribute to announce connected networks. Also, I understand in the case of multiple VS we'll need on top of that to configure a dummy public IP and FQDN for each one. Not sure the customers will find this elegant.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don‘t know your specific requirements. But as an idea….. you can create a new virtual firewall with the dummy public IP and a very simple policy (your AntiPhishing). Your outgoing traffic can be routed through these new system from the other VSs ?
